It appears that you have not registered with Aurora 4x. To register, please click here...
Other Games > Modding
Modding
Agm-114:
Well I figure it's probably worth having a dedicated modding thread.
I'll append any mods people make to this post.
Agm-114:
So kyle, from past experience modding aurora, one of the main issues is that the game's database structure will make updating mods a bit difficult.
Let's take a hypothetical mod "Agm's trade good adjustment mod"
Which changes the req to produce to civ infrastructure to 25 million to make setting up a colony a bit tougher.
The issue is that installing this mod requires a DB swap so it can't be used with existing saves and can't be updated very easily to new DB versions.
My suggestion would be to move read only data tables like Installations, materials, name themes, ranks, trade goods, etc to a separate DB.
I'm not sure if that's viable but it'd def be super helpful.
MasonMac:
Why not run a script that transfers the old saves to the new db?
Agm-114:
Yeah if it comes, and kyle's ok with it I'll probably release a script. However that's a bit of a hacky solution that I'd like to avoid if possible.
Kyle:
Two databases is a good idea but there a few read-only-but-not-really tables that muddy up the waters on the idea of multiple db's. Pretty relevant tables too, such as TechSystem: (this may also be a reason against it happening on C# by the way)
Any new research project you create gets added here but this also contains vanilla stuff like fuel tanks.
I strongly advise not to write a script that migrates an existing game into a new db. That's a lot of work and would be incredibly easy to mess up and would cause all kinds of very-very-nasty bugs. I also don't recommend providing a drop-in db, because the database gets updated fairly regularly as I add more helper columns and tables. Instead, put a database modification script in your on_program_load file. It would be pretty simple. Say you wanted to remove the Trans-Newtonian Tech requirement on Flag Bridge. You could have the following in your on_program_load function:
update TechSystem set Prerequisite2 = 0 where TechSystemID = 225 and Prerequisite2 = 27434
The "Prerequisite2 = 27434" section nicely skips the update if some other mod has already messed with that field or a future database version has fiddled with it. Doing it this way ensures that your mod is still active even after future database updates. If, for arguments sake, the entire Prerequisite2 column got deleted (it wont) making your mod no longer compatible, then the SQL would harmlessly fail. Bad SQL fails silently, it doesn't crash.
You would just have to give the user a caveat that your mod is permanent and if they want to revert the change they'll have to redownload the database file. (Which is the same amount of work that would be required for the database-dropin approach anyway.)
Navigation
[0] Message Index
[#] Next page
Go to full version