Sleeper Service wrote:Really, that slows it down so much? But I guess that makes sense... CE adds about, I dont know, 300 new blueprints? In the end we will might deal with about 10.000 weapons maybe... maybe the player just has to deal with that loading time. Did it run in the end? Could you start an actual game?
It adds 114 different player weapons.
To sum it up, I believe the way the weapons are loaded 'resource' wise is in powers of two- so 10000 weapons would be the equivalent of loading 16384 weapons.
Sleeper Service wrote:Really, that slows it down so much? But I guess that makes sense... CE adds about, I dont know, 300 new blueprints? In the end we will might deal with about 10.000 weapons maybe... maybe the player just has to deal with that loading time. Did it run in the end? Could you start an actual game?
It adds 114 different player weapons.
To sum it up, I believe the way the weapons are loaded 'resource' wise is in powers of two- so 10000 weapons would be the equivalent of loading 16384 weapons.
I forgot to add: Yes, the game does load... but the starting the game also takes a while.
Sleeper Service wrote:Yeah, I kind of have to agree with that...
I actually checked with people smarter than I am about this, and apparently, it is possible to write a script to generate the weapons as needed- and they only exist as long as needed. I'm currently trying to see how to make that work in FTL.
Sleeper Service wrote:i seriously doubt that this is possible if you have to mod in the files with the mod manager anyway. This pretty much sounds like .exe modding.
Heh... I guess it does. Don't worry, I'll keep within the rules.
I'm guessing the game loads a static file during start up - which means an existing bank of weapon blueprints, in an xml file format, is loaded into the application (game) memory during runtime (the starting loading screen).
This explains the increase in the loading time during the start of the game.
I don't think the weapons are loaded into the game memory during the game runtime, since this would result in poor performence.
Keeping this in mind, here's a possible, application based solution:
Using a simple script, a modification application is run BEFORE running the game.
The application will randomize a smaller subset of weapon modifications for each game session (instead of ~10000, ~1000 weapons or so).
The continue.sav file should also be scanned, if it exists, in order to load modified weapons that are found in the current save.
This solution will also keep the spirit of randomness, which FTL is based on.
Naturally, this is relevent only for a fast running moding application, but it seems doable to me.
The downside is adding the application + dependent environments to a mod release, but keep in mind - this sort of thing can open up a lot of doors in future mods....
