View Full Version : Loading C++ code in UDK
Castle
11-10-2009, 03:58 AM
Hi,
I'm new to UDK I'm currently evaluating this engine for a project and I'd like to load some simulation code I have in C++.
Looking at the documentation I found some old document explaining how to load external C++ as DLL and calling it as Native Function.
http://udn.epicgames.com/Two/NativeFunctions.html
Is this possible on UDK or was only available of old version of Unreal Engine with public source code?
Thanks a lot for your help
jeffro11
11-10-2009, 04:21 AM
Not possible. That feature is what separates the licensee's from the UDK license.
Makaze
11-10-2009, 09:54 AM
There is a hack you can do to partially get around the problem. By setting up a second executable on the local machine that is listening you can send it requests via TCPLink. It then executes your code and returns the results. It's slow, inefficient, and not suited to a lot of tasks but might work for you.
I myself am very disappointed that we cannot run our own independent or 3rd party code as it makes several game types and non-entertainment applications virtually impossible to write effectively or poses an impractical level of porting from existing, tested, and optimized code into unrealscript.
spooky_paul
11-10-2009, 10:01 AM
It would be nice if we got a pre-built sdk (like havok and physx do) that we could use with c++ and extend via plugins.
Brexer
11-10-2009, 10:02 AM
Would have been nice if there where a lib and some header files for making external dll's (even limited, but executed by the game) like if dll exists "mymod.dll", then execute it and have like 4 functions in there like maybe
on_load()
on_unload()
on_update()
on_render()
And where you have access the basic stuff like materials, network, scripting and such from this lib/header stuff.
But i guess, even in a limited way, it would be giving away too much :)
Or maybe perhaps, if even possible, they could find a way to speed up unreal script execution time, that would be awesome too (or change it to something faster).
pacerx
11-10-2009, 10:12 AM
Not possible. That feature is what separates the licensee's from the UDK license.
I don't know exactly why native functions are not available for the UDK but I hope, ultimately, the main difference between a full licence and a UDK licence is the commitment of tech support you get from Epic. I hope that Epic decides they can expose native methods in the UDK without it costing them a great deal of time or money.
spooky_paul
11-10-2009, 11:24 AM
it would be nice if unreal script had a feature like python's ctypes, where you can access dlls directly from python, and writing wrappers is really fast
LennardF1989
11-10-2009, 12:01 PM
It would be cool if Epic released the header files, so we can compile our own DLL's like we could with UT Classic, which opens native possibilities without having to temper with the real source.
Castle
11-10-2009, 11:56 PM
Ok I understand the situation.
Sure it would be great if Unreal Script could interface to DLL or Lib. I'm really not expecting to see anything of unreal source code for free. That is fair enough but just giving the power to Unreal Script to load external DLL would really allow great freedom for the creation of different games. As is UDK is more for mod building. Oh well still nice that is free for everyone to play with. I guess I'll just have to look at something else for my current needs.
Thanks everyone for the help!
head77x
11-11-2009, 07:58 AM
Native(PackageName)
Indicates that "this class uses behind-the-scenes C++ support". Unreal expects native classes to contain a C++ implementation in the .EXE. Only native classes are allowed to declare native functions or implement native interfaces. Native classes must always derive from another native class. Native classes create an auto-generated C++ header file with the necessary glue to interact with the script variables and specified functions. By default, the PackageName is the package that the script class resides in. For example, if the class were in the Engine package, the resulting auto-generated header would be called EngineClasses.h.
http://udn.epicgames.com/Three/UnrealScriptReference.html#Classes
----------------------------------------------------
and Here...........
----------------------------------------------------
Advanced function specifiers
Native
You can declare UnrealScript functions as native, which means that the function is callable from UnrealScript, but is actually implemented (elsewhere) in C++. For example, the Actor class contains a lot of native function definitions, such as:
native(266) final function bool Move( vector Delta );
The number inside the parenthesis after the native keyword corresponds to the number of the function as it was declared in C++ (using the AUTOREGISTER_NATIVE macro), and is only required for operator functions. The native function is expected to reside in the DLL named identically to the package of the class containing the UnrealScript definition.
http://udn.epicgames.com/Three/UnrealScriptReference.html#AdvancedFunctionSpecifi ers
----------------------------------------------------
Where can I find that UDK not include these features???
^^; I wannt try to get information more...
immortius
11-11-2009, 08:32 AM
Those references are there because the documentation we have access to is a subset of the full licensee documentation set. Notably the pages on how to actually create native classes are not accessible.
elmuerte
11-11-2009, 10:50 AM
There is no support for C++ code (or any other language than UnrealScript) so stop asking about it.
If Epic ever decides to include support for native code in the UDK you will be notified.
spooky_paul
11-11-2009, 11:11 AM
why not discuss about it?
feature requesting counts as valuable feedback. how would the developers know what is needed if the people using it don't talk about what their needs are?
it is odd when feature requests are dealt by some members of the community like this. i believe that this type of comment should have been made by the admins or some other official voice.
Wormbo
11-11-2009, 11:25 AM
There are valid requests and pointless requests. Requestzing a feature for free that only licensees are allowed to use belongs to the latter category.
spooky_paul
11-11-2009, 11:39 AM
yes, but shouldn't this be decided by the staff?
this talk is not about getting the unreal source code, it's about interfacing the engine with exterior components via c++. an sdk if you want. like you get with physx, havok, fmod, and other middle-ware that has a free pre-compiled sdk.
licensing terms tend to change, making some of the licensees only features available for the rest of us(ie havok physics)
pacerx
11-11-2009, 11:40 AM
There is no support for C++ code (or any other language than UnrealScript) so stop asking about it.
If Epic ever decides to include support for native code in the UDK you will be notified.
No, keep asking so Epic knows how important that feature is to people.
saymoo
11-11-2009, 11:42 AM
yes, but shouldn't this be decided by the staff?
this talk is not about getting the unreal source code, it's about interfacing the engine with exterior components via c++. an sdk if you want. like you get with physx, havok, fmod, and other middle-ware that has a free pre-compiled sdk.
licensing terms tend to change, making some of the licensees only features available for the rest of us(ie havok physics)
Correction, Havok Physics, animation and behavior sdk(binary only version) is free for noncommercial usage. (check their license)
http://www.havok.com/index.php?page=noncommercial
and indeed an api to the udk code is appreciated. (no need for engine sourcecodes, just hooks to functions (with example code and api's)
pacerx
11-11-2009, 11:43 AM
There are valid requests and pointless requests. Requestzing a feature for free that only licensees are allowed to use belongs to the latter category.
We don't know why Epic has decided to exclude native code execution and we don't know whether it is a possibility for a future release.
spooky_paul
11-11-2009, 11:49 AM
Correction, Havok Physics is free for noncommercial usage. (check their license)
The same with FMOD, but both offer SDKs (libs and header files) for non-commercial use.
LE:Actually Havok is free for games priced up to 10$ (the last lines from here (http://www.havok.com/index.php?page=pro)). The ideea was that they both offer a fully-functional SDK.
Wormbo
11-11-2009, 11:52 AM
AFAIK UE3 executables are statically linked. Earlier engine versions could dynamically load DLLs based on package names. That feature was removed from UE3, mainly for security reasons. A game engine that allows you to load arbitary DLLs just invites abuse. As such, it's a good thing you can't load external code. Doing so would also cause several inconsistencies in the engine concepts: Only Unreal packages are downloadable (DLLs, etc. are no packages) and UnrealScript runs in a sandbox that does not have full access to the system.
head77x
11-11-2009, 11:55 AM
Sorry, elmuerte. I have more questions... :)
I just wanna know about this feature more correctly.
Because, If someone want to get license ( include my company ), he must know about this more correctly.
If UDK does not include this feature, How I can get this feature? Will Epic send to me the other version's UDK after contract?
I hope if someone know about this, please notice.....
pacerx
11-11-2009, 12:08 PM
Maybe there could be separate security domains for UScript execution so that only "blessed" scripts can execute certain native methods.
spooky_paul
11-11-2009, 12:12 PM
AFAIK UE3 executables are statically linked. Earlier engine versions could dynamically load DLLs based on package names.
The static linking is the only way you can go on consoles. And having only one code base is justifiable.
That feature was removed from UE3, mainly for security reasons. A game engine that allows you to load arbitary DLLs just invites abuse.
How?
elmuerte
11-11-2009, 04:30 PM
why not discuss about it?
Of course you are free to discuss anything you like. But there is no point in putting forth feature request Epic knows about that various people want, but has already decided not to act upon.
yes, but shouldn't this be decided by the staff?
They already decided. Otherwise the UDK would have shipped with headers. Also given the fact that UE3 is statically linked and does not have any standard functionality for loadable modules. In that case Epic would need to implement a loadable module support specific for UDK, which will take quite some effort and thus will probably have a very low priority.
No, keep asking so Epic knows how important that feature is to people.
Epic knows about it. It has been asked for in the past 7 years. If they ever decide to grant native code possibilities (like they have previously done with the UE2Runtime in certain license constructions) you will read about it in an update from Epic.
We don't know why Epic has decided to exclude native code execution and we don't know whether it is a possibility for a future release.
See above.
Sorry, elmuerte. I have more questions... :)
I just wanna know about this feature more correctly.
Because, If someone want to get license ( include my company ), he must know about this more correctly.
If UDK does not include this feature, How I can get this feature? Will Epic send to me the other version's UDK after contract?
Right now, the only way to get this functionality is by getting a full license. And as far as I know Epic is dedicated to keep releasing updated version of the UDK for some while.
If Epic ever decides to to create an additional UDK license (besides the 3 they have now) you will probably read about it in nice big friendly letters on udk.com and this forum.
Makaze
11-11-2009, 06:48 PM
The only reason Epic will decide to reconsider their stance on the subject of native code is if it's in their financial interests. That being said the more people that want this feature, will use this feature, and most importantly will make additional revenue off of this feature tips the balance in favor of implementation. Making them aware of our existence and why and how it will help both parties is a worthwhile goal.
Clearly someone ran the numbers and decided to change their long standing policy on not being able to sell mods without a full priced license. Things change, this can be one of them.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.