In-game modding

[Fanger]

Relinquished.. there is no way in hell you can committ to memory the indivdual metal costs, energy costs, and buildtimes of nearly 300+ units.. and if you can you need to go do something else with your life cause clearly you have none..

[KDR_11k]

What do you think Spring is doing at load time?

[Tobi]

Modifying the values in game wouldn't even be that much of a problem (for certain values at least). Just like .nocost sets unitDef->metalCost and unitDef->energyCost to 0 or 1 one could implement other commands like that. Changing moveType / type of the unit / type of it's weapons would be a lot harder tho.

But probably you want to save your modifications too and that means a whole new chunk of code should be added to the filesystem layer (so it knows it can't save to .sdz/,sd7 but it can save to .sdd or real non-VFS files). Also you'd obviously want comments and layout of the fbi/tdf to be preserved meaning a new TdfParser that can save and preservers comments/layout must be coded.

In other words, it's not going to happen

[KDR_11k]

I think it would be sufficient if you got a list of all changes you made when you exit the game so you can merge them into your base set of files. I think I'm not the only one who has his work folder separate from the TA Spring folder.

[rattle]

Someone ELSE write a patch and save the devs some time. Any volounteers?

[jcnossen]

lol, knock yourself out writing that patch...

[rattle]

Was worth a try...

[KDR_11k]

I don't think it needs to allow more than tweaking, changing unit and weapon types can be omitted, ingame you'd only do tweaks since those would be small and done very often.

[Relinquished]

Modifying the values in game wouldn't even be that much of a problem (for certain values at least). Just like .nocost sets unitDef->metalCost and unitDef->energyCost to 0 or 1 one could implement other commands like that. Changing moveType / type of the unit / type of it's weapons would be a lot harder tho.

But probably you want to save your modifications too and that means a whole new chunk of code should be added to the filesystem layer (so it knows it can't save to .sdz/,sd7 but it can save to .sdd or real non-VFS files). Also you'd obviously want comments and layout of the fbi/tdf to be preserved meaning a new TdfParser that can save and preservers comments/layout must be coded.

In other words, it's not going to happen

Fine, I have an idea. Make it so it doesn't change the mod file at all, just temporarily in game until you next load it. When the game is over, like what has been said, it could give you a document (notepad or something) of the changes you made in game, allowing for you to easily test your ideas, then implement them if you'd like

[Tobi]

KDR_11k had that idea too.

It's still pretty complex because you probably don't want all unchanged stuff being dumped to infolog/file too (at least I don't see how it can be usefull if everything is dumped).

Also what jc said still applies. While some things may be easy to tune, others may have been passed through to other code after loading so tuning those wouldn't have a single effect.

For basically the same reason it would be near impossible to guarantee the behaviour of spring with the runtime edited mod is the same a the behaviour of spring if the mod with those modifications was loaded from file. (because of the logic just after loading...)

Anyway, if someone makes a *good* patch, sure, but don't expect it from us

[Relinquished]

KDR_11k had that idea too.
Also what jc said still applies. While some things may be easy to tune, others may have been passed through to other code after loading so tuning those wouldn't have a single effect.

For basically the same reason it would be near impossible to guarantee the behaviour of spring with the runtime edited mod is the same a the behaviour of spring if the mod with those modifications was loaded from file. (because of the logic just after loading...)

That's why you make it pause for a bit and reload the files that are affected by the changes.