Announcement

Collapse

Infinity Blade

See more
See less

Communicating with other software without TCP or UDP

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Communicating with other software without TCP or UDP

    Can UDK-based games communicate with other local software without TCP or UDP? Through stdout maybe? One-way communication is okay for my purposes.

  • #2
    It is possible to create a watcher application which watches for files being written. The obvious one is to watch the Launch.log but that gets a lot of things written to it from a lot of sources. There is also a FileWriter class in Engine.u which you can use to write to files on the disk which your watcher application can use.

    Comment


    • #3
      That's it? Files and network?

      Comment


      • #4
        I'm not sure what you're trying to achieve exactly, so it's a stab in the dark.

        Comment


        • #5
          I was hoping to communicate with an external video player (barebones, custom made) to replace Bink for cinematics. I suppose for this purpose TCPLink is fine, but if there's a way to feed uncompressed YV12 video to the Bink renderer (which is a better solution, in theory), TCPLink would probably be too resource intensive.

          The idea is to add H.264 and Vorbis support, since Bink is lacking in quality.

          Now that I think about it, it would probably be okay to just use command-line arguments to give the the player the info it needs, but the process probably won't be as hurdle-free and more communication would be required.

          What I really want to know is: can you accept input from a pipe (stdin) somehow?

          Comment


          • #6
            Hmm, now that is something I don't think you could do. Unless you did weird things like minimize / close UDK played the video, and then went back into UDK.

            Comment


            • #7
              It would most likely be possible to do it without imposing additional waiting, or even use a renderer which can render on top of D3D. And if that doesn't work out, hook onto it and do it that way (though that would be pretty hacky).

              I should be able to get past any other hurdles - the missing piece is an efficient communication method.

              Comment


              • #8
                Well you'd need to start doing things like memory injecting, etc etc ... for the sake of using a different video format?

                Comment


                • #9
                  I just did a quick grep of the files in UTGame/Classes of the UT3 script source files (the full game, not the demo). 336 of 907 files contain the term 'native'. When a third of your classes need native code execution, how far can UScript alone really take you?

                  I'm not feeling the TCPLink or file watching hax either. The mechanism is there. Maybe the feet paddling the duck are too frantic for public consumption. Is it really a money thing? I thought 25% was on par with full licencee's projections.

                  Comment


                  • #10
                    Originally posted by Solid Snake View Post
                    Well you'd need to start doing things like memory injecting, etc etc ... for the sake of using a different video format?
                    No, that was just in theory. I wouldn't go that far, it's too hacky. The most I would do is use an external decoder and renderer.

                    Originally posted by pacerx View Post
                    Is it really a money thing? I thought 25% was on par with full licencee's projections.
                    I suppose they expect that 25% from a full licensee's sales is going to be much bigger than 25% from an indie developer's sales.

                    Comment


                    • #11
                      Originally posted by pacerx View Post
                      I just did a quick grep of the files in UTGame/Classes of the UT3 script source files (the full game, not the demo). 336 of 907 files contain the term 'native'. When a third of your classes need native code execution, how far can UScript alone really take you?
                      A lot of the native code in UT3 was for performance reasons, converting to native only at the end as we profiled the game.

                      There are numerous UT3 total conversions as well as Whizzle that demonstrate the power of the language.

                      We appreciate any feedback you may have about what you can/cannot do in Unrealscript, but I think you'll find that you can be very successful with Unrealscript alone. As UDK takes off we're certainly on the lookout for this type of feedback.

                      Comment


                      • #12
                        I understand completely why we're not allowed access to the engine source itself. However the restriction of not being able to execute our own completely independent code from unrealscript seems an arbitrary and unnecessary restriction.

                        From a security perspective it doesn't make sense as any game created via the UDK meant to be sold commercially will have an executable installer, if you don't trust the the author to run native code you probably shouldn't run their installer... And to top it all off native code execution is still technically possible. We can do it, just through a terribly hacky and inefficient method.

                        I agree that unrealscript can take you a long ways but as you point out was the case for UT3 there are some things that simply need to be executed in native code for performance reasons. Simulations (especially for systems that already have an existing and highly optimized dll for such simulations) and complex AI are two that come to mind immediately. Not to mention the rather broad flaw of custom saves.

                        If the only reason not to include it is as an incentive to license the full version then it's somewhat the equivalent of arbitrarily putting a sleep(1) in the render loop of the UDK just so it's slower than the licensed version. And really not that effective to boot, the cross section of your potential customers that are on the edge of it making financial sense to license or go the UDK route is fairly small and easier captured via modifying one of license agreements rather than arbitrarily crippling the UDK. It also has the potential to discourage many projects that begin in the UDK from upgrading to a full license once more mature (either through the securing of funding or if the UDK is used for rapid prototyping) as the refactor effort is increased. Additionally any features that would have relied on native code would have necessarily already been dropped from the design thus providing even less of an incentive to upgrade.

                        I think currently your community of potential users views this restriction as arbitrary rather than technical in nature, myself included. Now if I am completely off base here and there is a fundamental technical reason that it is not possible currently, or more importantly ever, then please let us know.

                        Comment


                        • #13
                          The fundamental reason is: You're not a licensee.

                          No really, if you want to create AI or simulation stuff that is too complex to be implemented in UnrealScript and a TcpLink to an external application doing the work is not an option, then you need to get an engine license. UnrealScript, if used properly, should be powerful enough to get most jobs done in acceptable time.

                          Remember, rule #1 of optimization is "Don't do it!", while rule #2 for the advanced guys is "Don't do it yet!" As mentioned, the native UT3 stuff was originally implemented in UnrealScript and only got moved to native code for the final performance optimization stage. UT3 may have been playable on the PC with most of that staying in UnrealScript, but the game is also targeted at consoles, which have limited and fixed resources available.

                          Comment


                          • #14
                            Nor will I likely ever be a licensee.

                            But that is not a technical reason, it is a marketing one and not a good one in my opinion. Arbitrarily crippling the UDK gains them nothing while potentially earning them less revenue in royalties as I have to cut features, raise the min spec, or force the user to endure poor performance in some aspects thus leading to less potential sales.

                            Again I understand why we're not allowed access to the engine source itself. With the UDK freely distributable and no realistic way to apply or enforce an NDA it is in no way realistic to expect that level of access. Allowing me to run my own or 3rd party code on the other hand costs them nothing while providing at least a potential upside in the form of higher royalty payments.

                            I guess what I'm looking for barring the actual ability to run my own code is an explanation as to why they've made that decision and think it's the right one. From someone with an Epic tag, I know you and Ambershee can give me the pat answer of that's the way it's always been and always will be. Before last week you couldn't sell mods, that's the way it always was and always would be.

                            Comment


                            • #15
                              Maybe it's a legal thing... Epic earning dough from an app that directly links to an unlicensed or restrictive 3rd party lib might land them in court?

                              Linking to 3rd party libs is what I'd most likely do.

                              Comment

                              Working...
                              X