Vit20141012
Chieftain
How to change the unique unit "Cossack (Cavalry)" to "Cossack (Cuirassier)"?
Current v1.13 Development Discussion
- Thread starter Leoreth
- Start date
- Status
Please consider the inertia rule.
Shadow Warlord
Warlord
- Joined
- Oct 24, 2014
- Messages
- 272
Are you saying that we need those wars to keep civs from getting too powerful or that civs will just declare war again anyway?
need my speed
Rex Omnium Imperarium
Change the unitclass of the Cossack from Cavalry to Cuirassier, in CIV4UnitInfos.xml.
Vit20141012
Chieftain
The situation: Poland and Germany are at war, Russia - no, Germany seized the city of Lviv, but also captured the territory of Russia.
From Russian core?
WARNING: This revision breaks savegame compatibility.
- Complete rewrite of the Victory module for improved performance, consistency and extendability
- Changed multiple UHV goals from IN to BY (Canadian 1st and 2nd, Brazilian 3rd, Thai 1st, Italian 3rd, Polish 1st, English 2nd)
- Moved deadlines for the first and second American UHV goals to 1900 and 1950 AD respectively
- Changed the second Canadian UHV goal to: control all cities and 90% of the territory in Canada by 1950 AD
- Added UHV goal names for Polynesia
This rewrite took a lot of time, and even though most of it won't be noticeable from a player perspective (since the goal was to recreate the old behavior) it was definitely necessary in my opinion.
The old version had lots of dead code, a lot of it was still Rhye's clunky implementation (don't want to talk badly about him but his Python is hardly idiomatic or even elegant) and many things were implemented many times over in an inconsistent way. While I admit that I mostly redid it because I like to work with clean and elegant code, this will also make future additions a lot easier and provide some other benefits.
First of all, I have standardized how the goals are checked and how they expire. This means that now for all BY goals the last check will be made in the year mentioned in the goal description and if it still isn't won, it will fail. So situations in previous turns where the goal would only fail the next turn without any further chance of winning it, or where it would fail on the turn mentioned without a chance of winning won't happen anymore.
I also refactored nearly all checks into separate methods, which greatly reduced duplicate code. That means that the information in the victory display will always be up to date with how the victory check itself operates.
I have also rewritten some clunky implementations of a couple of checks and gotten rid of superfluous constants and saved variables. That should save a little memory and computation time, but don't expect anything significant.
I did my best to test all the new code, but there's a lot of it and some victory checks only apply during actual gameplay which I obviously couldn't do for all civilizations. So please understand if a UHV goal doesn't work and report it in the bug reports thread, I will take care of it immediately.
- Complete rewrite of the Victory module for improved performance, consistency and extendability
- Changed multiple UHV goals from IN to BY (Canadian 1st and 2nd, Brazilian 3rd, Thai 1st, Italian 3rd, Polish 1st, English 2nd)
- Moved deadlines for the first and second American UHV goals to 1900 and 1950 AD respectively
- Changed the second Canadian UHV goal to: control all cities and 90% of the territory in Canada by 1950 AD
- Added UHV goal names for Polynesia
This rewrite took a lot of time, and even though most of it won't be noticeable from a player perspective (since the goal was to recreate the old behavior) it was definitely necessary in my opinion.
The old version had lots of dead code, a lot of it was still Rhye's clunky implementation (don't want to talk badly about him but his Python is hardly idiomatic or even elegant) and many things were implemented many times over in an inconsistent way. While I admit that I mostly redid it because I like to work with clean and elegant code, this will also make future additions a lot easier and provide some other benefits.
First of all, I have standardized how the goals are checked and how they expire. This means that now for all BY goals the last check will be made in the year mentioned in the goal description and if it still isn't won, it will fail. So situations in previous turns where the goal would only fail the next turn without any further chance of winning it, or where it would fail on the turn mentioned without a chance of winning won't happen anymore.
I also refactored nearly all checks into separate methods, which greatly reduced duplicate code. That means that the information in the victory display will always be up to date with how the victory check itself operates.
I have also rewritten some clunky implementations of a couple of checks and gotten rid of superfluous constants and saved variables. That should save a little memory and computation time, but don't expect anything significant.
I did my best to test all the new code, but there's a lot of it and some victory checks only apply during actual gameplay which I obviously couldn't do for all civilizations. So please understand if a UHV goal doesn't work and report it in the bug reports thread, I will take care of it immediately.
agentxorange
Warlord
I know what you mean, it's not great reading over code (even if you wrote it) and just having no idea what's going on. I know where Rhye is coming from, since he probably figured that as long as he understood it, that was good enough. Unfortunately that means he didn't really write any efficient/consistent methods, or he just duplicated code, which isn't very useful when other people look over the code.
Edit: I totally meant to say cool update! Always appreciate cleanup and optimization.
Vit20141012
Chieftain
Leoreth, thank you very much for the work! I appreciate your work and I think this mod is one of the best!
Had missed this earlier for some reason. What I was saying is that the ingame event "Congress leads to war" can be an abstract representation of processes that take longer in real life, for instance unfavorable diplomatic outcomes leading to tensions in the future leading to wars etc. We cannot wait for this to unfold in realistic timeframes because the inertia rules would mean that then nothing would happen at all.
It's obvious that Rhye never really learned Python (I didn't know it either when I started modding) and basically treated it as C with different syntax, which kind of ignores its strengths (there are snippets of code where he creates an iterator variable that goes from 0 to the length of a list to access all elements of the list ...). Also considering his background in robotics (as I understand it), he's probably more predisposed towards hacky "just make it work" solutions anyway.
I'm on the other hand mildly OCD about nice code
Thank you!
merijn_v1
Black Belt
I'm on the other hand mildly OCD about nice code
I don't think that's always a bad thing. Although I have to rewrite some parts of my camp mechanic because of this.
I'm on the other hand mildly OCD about nice code
^ Nice code are nice to see and read. I like that too. Here what I did with my CNM when I have free time. Tell me what you think:
Spoiler :
This way I can see if there's redundancy or no longer appropriate names (such as if you send Mughal to settle a city in the middle of Arabian desert, the name will be Arabaya from Ancient Persia). It isn't really important tho, just like Civilopedia it can be done later haha.
merijn_v1
Black Belt
Not specifically the victory module itself, but some files that changed with it, like StoredData.py and RFCEventHandler.py. I also copied the method to check if any old-world civ has a colony in America. You changed that method, so I had to apply that change to my code as well.
But by now, I already have updated all my files with the new methods.
Given how much time I already sunk into rewriting the CNM module I'd rather not touch it again for a while. And I'd still like to come up with a better way to handle the rename method that is better than multiple dict entries.^ Nice code are nice to see and read. I like that too. Here what I did with my CNM when I have free time. Tell me what you think:
Spoiler :
This way I can see if there's redundancy or no longer appropriate names (such as if you send Mughal to settle a city in the middle of Arabian desert, the name will be Arabaya from Ancient Persia). It isn't really important tho, just like Civilopedia it can be done later haha.
Ah, okay.
- Status
Similar threads
