Now I'm not here to try and refactor everything into some super organised system that will take forever, never be finished and cause more problems than it solves.
I'm suggesting simple C include type behaviour simply to separate different parts of the mod.
Put districts in its own file(s), put unit limit code in its own file, tradex, stack actions, visibility rules, ai fixes, etc, utility functions, and so on and so forth.
As for common functions like config parsing, I think it would be fair to just call a likewise named function from each file. Avoiding anything complicated or too structured. The simple int/float config option lists might be tricky.
For patches where multiple parts are touching the same thing, it would be a case of putting it in the more relevant file and leaving a note in the other, or where applicable defining the patch in the main file and sub-functions in each relevant feature's file.
Simply put the idea to cut the 37000 lines into something more readable, and also more easily version tracked. Having a billion edits to the same file hardly helps finding when something's changed - particularly if we aren't squashing on merges.
Curious on if there's support for such a change, and any other considerations that may be had.
Now I'm not here to try and refactor everything into some super organised system that will take forever, never be finished and cause more problems than it solves.
I'm suggesting simple C include type behaviour simply to separate different parts of the mod.
Put districts in its own file(s), put unit limit code in its own file, tradex, stack actions, visibility rules, ai fixes, etc, utility functions, and so on and so forth.
As for common functions like config parsing, I think it would be fair to just call a likewise named function from each file. Avoiding anything complicated or too structured. The simple int/float config option lists might be tricky.
For patches where multiple parts are touching the same thing, it would be a case of putting it in the more relevant file and leaving a note in the other, or where applicable defining the patch in the main file and sub-functions in each relevant feature's file.
Simply put the idea to cut the 37000 lines into something more readable, and also more easily version tracked. Having a billion edits to the same file hardly helps finding when something's changed - particularly if we aren't squashing on merges.
Curious on if there's support for such a change, and any other considerations that may be had.