Fallout 2 SourceCode Petition

Mulligun

Still Mildly Glowing
Hello

I (and everyone else) surely know how HARD is to make a mod for F2
when dealing only with disassembled code in asm.
Mayby we, modders colud make a petition to BlackIsle to public F2 source ???
It would be MUCH MUCH easier to code in C++ or similar high-level language

Any chace to get F2 soucecode? (What do you think?)

The game is SO old now!
 
Disclaimer: I'm totally biased in this case as I'm part of FIFE but I hope I would have the same opinion if I wouldn't participate in the project.

I seriously think that it wouldn't be of much use to open source the Fallout sourcecode. It could help to find out some details that couldn't have been reverse engineered yet but I wouldn't use it as a basis to continue the development of the Fallout engine.

They used the Watcom C (or was it C++?) compiler for compiling Fallout and that does mean you won't be able to easily get the code running on non Win32-systems. Even if you port it to work with gcc you would need to clean up a lot of win32-specific code. The code should be heavily outdated by todays standards, the used scripting language could be replaced with a modern one (lua, python, squirrel, chose the one you like); but that would involve quite some work.

So I guess if anyone is able to clean up the Fallout sourcecode he could have achieved more by spending this time on helping FIFE progress but that's prolly just my biased opinion.

I'll support such a petition nevertheless as there are quite some holes in the file format documentation though TeamX did a really great job with reverse engineering. If the code ever gets released it would be an advantage for FIFE too :-)
 
Mulligun said:
Hello

I (and everyone else) surely know how HARD is to make a mod for F2
when dealing only with disassembled code in asm.
Mayby we, modders colud make a petition to BlackIsle to public F2 source ???
It would be MUCH MUCH easier to code in C++ or similar high-level language

Any chace to get F2 soucecode? (What do you think?)

The game is SO old now!

I don't think they would be able to release the code, or at least they won't be willing because of copyright issues. A lawyer would have to go through a pile of papers and Interplay isn't really in a situation when it could afford to pay.

mvBaraccuda said:
Disclaimer: I'm totally biased in this case as I'm part of FIFE but I hope I would have the same opinion if I wouldn't participate in the project.

I seriously think that it wouldn't be of much use to open source the Fallout sourcecode. It could help to find out some details that couldn't have been reverse engineered yet but I wouldn't use it as a basis to continue the development of the Fallout engine.

They used the Watcom C (or was it C++?) compiler for compiling Fallout and that does mean you won't be able to easily get the code running on non Win32-systems. Even if you port it to work with gcc you would need to clean up a lot of win32-specific code. The code should be heavily outdated by todays standards, the used scripting language could be replaced with a modern one (lua, python, squirrel, chose the one you like); but that would involve quite some work.

So I guess if anyone is able to clean up the Fallout sourcecode he could have achieved more by spending this time on helping FIFE progress but that's prolly just my biased opinion.

I'll support such a petition nevertheless as there are quite some holes in the file format documentation though TeamX did a really great job with reverse engineering. If the code ever gets released it would be an advantage for FIFE too Smile

Fallout doesn't have so much Windows specific code. Fallout 1 engine run under DOS (one version), and engine in the sequel is not so different. I think the basic part of the engine would be quite platform-independent, only loading files and sound will pose a problem (judging by experience + debug messages from wine). Digging in the source wouldn't be hard either, at least in comparison with FIFE (both lack "middle" documentation - begginers know how to doubleclick on the file, programmers know their comments in the source, but but the compiling instructions are totally outdated and the interface... Well, its Lua, but you could have simplified it and documented).
 
Karel said:
Fallout doesn't have so much Windows specific code. Fallout 1 engine run under DOS (one version), and engine in the sequel is not so different. I think the basic part of the engine would be quite platform-independent, only loading files and sound will pose a problem (judging by experience + debug messages from wine).
Hmm you're right here: "win32-specific" is definately the wrong term. I wanted to state that I don't believe that the code is really platform independent. I guess the gfx code would be another problem as well as porting it from watcom to gcc. It's not not impossible (the released quake 3 sourcecode and the port done by Ryan C. Gordon is a good example that this can work out if an experienced coder takes care of it) but it will take quite some time.

Karel said:
Digging in the source wouldn't be hard either, at least in comparison with FIFE (both lack "middle" documentation - begginers know how to doubleclick on the file, programmers know their comments in the source, but but the compiling instructions are totally outdated and the interface... Well, its Lua, but you could have simplified it and documented).
Outdated compiling instructions for FIFE? Really?

Last time I checked them they worked fine for me but feel free to report problems and we'll fix them :-)

About the whole documentation issue: we offer a doxygen documentation of our code. See here:
http://docs.fifengine.de

Additional documentation at the wiki would be surely appreciated but this depends on the time budget of our coders. If you think you can support us with these things please let me know :-)
 
mvBarracuda said:
Karel said:
Fallout doesn't have so much Windows specific code. Fallout 1 engine run under DOS (one version), and engine in the sequel is not so different. I think the basic part of the engine would be quite platform-independent, only loading files and sound will pose a problem (judging by experience + debug messages from wine).
Hmm you're right here: "win32-specific" is definately the wrong term. I wanted to state that I don't believe that the code is really platform independent. I guess the gfx code would be another problem as well as porting it from watcom to gcc. It's not not impossible (the released quake 3 sourcecode and the port done by Ryan C. Gordon is a good example that this can work out if an experienced coder takes care of it) but it will take quite some time.

Karel said:
Digging in the source wouldn't be hard either, at least in comparison with FIFE (both lack "middle" documentation - begginers know how to doubleclick on the file, programmers know their comments in the source, but but the compiling instructions are totally outdated and the interface... Well, its Lua, but you could have simplified it and documented).
Outdated compiling instructions for FIFE? Really?

Last time I checked them they worked fine for me but feel free to report problems and we'll fix them :-)

About the whole documentation issue: we offer a doxygen documentation of our code. See here:
http://docs.fifengine.de

Additional documentation at the wiki would be surely appreciated but this depends on the time budget of our coders. If you think you can support us with these things please let me know :-)

I can't really say I had problems compiling the source from cvs, but I just didn't find any simple guide to use the engine - I mean, yes, there is doxygen but... I was thinking of FIFE as a platform for testing maps for our team - but I didn't find a simple way to change a map through the interface or through issuing a simple command (like load_map "name") in console. Technically is FIFE OK, although the user experience suffers.

To the Fallout source:
I recently fiddled with another old game, Buzz Aldrin's Race Into Space, because the original programmer released the source (after 12 years!). Gcc (or rather mingw) had no problems with the game files, however, it uses 3rd party libraries (for graphics and sound) which weren't released and original distributors of them don't exist and the author doesn't want to (can't) give the libraries out (come on, 12 years old GFX library...).

I think BlackIsle used their own code from scratch (considering number of bugs in the engine), but it's just a guess. No offence - rewriting the Fallout engine may be easier than finishing FIFE (because of ready game files, scripting engine with large community and actually a working game - but the source may help you in interpreting Fallout scripts - if the code is well written, you might just port the whole thing into FIFE).
 
Karel said:
I can't really say I had problems compiling the source from cvs
I guess you mean SVN? We did never use CVS for FIFE.

Karel said:
but I just didn't find any simple guide to use the engine - I mean, yes, there is doxygen but... I was thinking of FIFE as a platform for testing maps for our team - but I didn't find a simple way to change a map through the interface or through issuing a simple command (like load_map "name") in console. Technically is FIFE OK, although the user experience suffers.
You're right with this one. There is a way by using the map selection lua script in combination guimap_test.exe but this is prolly a bit complicated if you're not used to this. I'll try to make sure that there is an easy way to load maps from console in the next release :-)

Karel said:
No offence - rewriting the Fallout engine may be easier than finishing FIFE (because of ready game files, scripting engine with large community and actually a working game - but the source may help you in interpreting Fallout scripts - if the code is well written, you might just port the whole thing into FIFE).
If it's "easier" fully depends on the features you want to integrate. For fixing simple bugs you can bet that using the Fallout sourcecode is the easiest option.

Though there are cases were you could want to add more features, a modern scripting language, cross platform support (byte order problems can arise with RISC CPUs e.g.). In this case working on FIFE is the better long term solution because we think that our code offers the more flexible design compared to the original Fallout code base. This is just a guess though: commercial teams don't have the time to design a flexible engine. Deadlines force them to write engines that just work for the initial purpose and hack additional features into it later.

In the end I don't really think that Interplay will release the sourcecode. And helping FIFE to progress is prolly better than waiting for years that Herve gives away the code to the Fallout fans.
 
mvBarracuda said:
Karel said:
I can't really say I had problems compiling the source from cvs
I guess you mean SVN? We did never use CVS for FIFE.

Karel said:
but I just didn't find any simple guide to use the engine - I mean, yes, there is doxygen but... I was thinking of FIFE as a platform for testing maps for our team - but I didn't find a simple way to change a map through the interface or through issuing a simple command (like load_map "name") in console. Technically is FIFE OK, although the user experience suffers.
You're right with this one. There is a way by using the map selection lua script in combination guimap_test.exe but this is prolly a bit complicated if you're not used to this. I'll try to make sure that there is an easy way to load maps from console in the next release :-)

Karel said:
No offence - rewriting the Fallout engine may be easier than finishing FIFE (because of ready game files, scripting engine with large community and actually a working game - but the source may help you in interpreting Fallout scripts - if the code is well written, you might just port the whole thing into FIFE).
If it's "easier" fully depends on the features you want to integrate. For fixing simple bugs you can bet that using the Fallout sourcecode is the easiest option.

Though there are cases were you could want to add more features, a modern scripting language, cross platform support (byte order problems can arise with RISC CPUs e.g.). In this case working on FIFE is the better long term solution because we think that our code offers the more flexible design compared to the original Fallout code base. This is just a guess though: commercial teams don't have the time to design a flexible engine. Deadlines force them to write engines that just work for the initial purpose and hack additional features into it later.

In the end I don't really think that Interplay will release the sourcecode. And helping FIFE to progress is prolly better than waiting for years that Herve gives away the code to the Fallout fans.

From svn, of course - but there is no real difference for me as a user.

To the map selection: I think you would attract a lot more people if you made the engine "useful" - technically it's good, but there won't be playable game for at least a year or more... The modding community would use a map loader-viewer because of high resolution FIFE can achieve (compared to Fallout 640x480) if it had a reasonable interface.
 
Karel said:
From svn, of course - but there is no real difference for me as a user.
For the devs it does make one :-) I really started to hate CVS with all the locked repository problems we had :-/

Karel said:
To the map selection: I think you would attract a lot more people if you made the engine "useful" - technically it's good, but there won't be playable game for at least a year or more... The modding community would use a map loader-viewer because of high resolution FIFE can achieve (compared to Fallout 640x480) if it had a reasonable interface.
Our aim is not to attract modders ATM but to attract programmers. We don't need more people who tell us to hurry but we'll need more guys who really invest some time to help us progress.

But you're right about the map selection interface. We'll take care to have an easy one in the 2007.0 release :-)
 
2mvBarracuda:
Some words about OS, platform and byte order dependences of the original Fallout. If you remember well there is Mac port of the game. And internal DAT file structures of the Fallout, unlike the Fallout 2, still use Motorola byte order. Everything mentioned above will not make any major problem if we get the code. But I don't believe much that Interplay will agree to release it. Moreover, it's possible that they don't have the code already. If you remeber what happend to the original script sources of the Fallout 2 v1.02d. :roll:
 
Mr.Wolna said:
that sucks.

We need a new engine? I heard Timeslip works on an new one, is that right?
Not anymore. He had started to work on it but decided to continue working on sfall instead.

A shameless plug :-) (not that it solves the question if a Fallout-like game based on a new engine that features the SPECIAL ruleset would get shut down via a cease and desist letter)
 
i am glad to see you still arround here barra :D

and thanks for the info, ahm sry for ot but fife loads fallout maps?
 
Mr.Wolna said:
i am glad to see you still arround here barra :D

and thanks for the info, ahm sry for ot but fife loads fallout maps?
Support for that is broken but I don't think that it would be too complicated to reimplement it IF there is interest in it. In the end FIFE looks like the most promising platform for a Fallout engine emulator and I hope that I'm not blinded by my former personal involvement in the project.

There is more missing than just support for loading Fallout maps: FRM support wasn't tested in ages, and Fallout scripts never worked with FIFE. But readding FRM support can't be that hard, and writing a converter for decompiled Fallout scripts to Python sounds doable to me as well. In the end it comes down if there are enough interested people to make it happen. The zen-master says: we'll see :-)
 
Back
Top