Quote:So for example, if you take a small map that crashes the ued when opening, edit its header, it will still crash? Because if it doesnt, the log should tell you what packages are missing. (Assuming the only problem the map has is the linking between files)

It's actualy a bit more complex than that.


Part 1 of the problem:

If you check both the ut2004 and Spellborn installations, you'll notice that you have quite a few DLL files. Some of Spellborn DLLs don't exist in the UT system folder. Inside of all the DLL's are paths coded in that don't match the UT folder structure. Also for each or most DLLs there is a corresponding .U file. These files contain unreal script code that is compiled with a equivalent but modifyed version of the UCC.exe program. what this program does is compile .UC into .U files. To load such U files, you need to edit the UT2004.ini file to add the references to it's name. Once this is done and try to load up the Unreal Editor, you'll notice that it can't load the entry points of the modifyed DLL's of Spellborn. De reason is that the Spellborn DEVs had access to the source code of the DLLs of unreal as well as C++ code from the launcher. Having that means that the DEVs could establish direct links between the EXE file and the DLLs. The U files are also linked to the DLLs as they contain code needed for the core and engine to understand what customisations to bring into the game.


Part 2 of the problem:

While we can reuse the texture, mesh and sound files, as they do not realy link to the DLL's, as JW explained JW made a delphi program with witch we can change the header of the files so that we can use them together with the Unreal Editor.

But when it comes to maps, character data and animations, those files require data that is stored in a database, therefore they crash as they lack information. Analysing the contents of the spellborn DLLs, some hints point to a Postgre SQL ODBC driver and queries passed via wwwquery. Also some DLLs seem to hint that a proxy was used on the server side. How the all the pieces fit together is our current aproach. For that we need to be able to understand the C++ code available from the public source code available from older Unreal versions, and the code we found from a guy that reversed some of spellborn's data. That person will not do any more work for spellborn as he considers it to have a too low player base. So we are left with only one solution: learn to program (in general), brush up on maths, learn C++, learn physx, learn Directx, learn networking programing, create a network with database, web server, unreal server with modifyed code. And if we want to use the Spellborn clients (post beta) disassemble to bypass gameguard.


I hope hope this gives an insight in the tasks at hand.


As JW previously mentioned, we only have so little time that we can spend on Spellborn, so things take longuer than you would hope. Of course with more people with knowledge on any of the previously mentioned task, and willing to take on a huge chalenge with no financial reward at any time, things could go a bit faster.


The Dream:

If only the owners saw the potential of spellborn and still not wish to lose such a gem, i dream of them making the source available to us (the community) so that it may not go down into oblivium...