- Joined
- May 5, 2005
- Messages
- 8,884
Resource icon
- Thread starter Flintlock
- Start date
MeteorPunch
#WINNING
I simultaneously feel like a dunce, but am also really glad to know that now.
Jorsalfare
Prince
Flintlock...I've been watching this thread (and of course, the progress you've made) with great interest, and I'm eagerly awaiting any reports of finds / possible improvements and/or bug fix to the code. The fact that someone with programming skills are taking the time to dig around in the exe, is great news indeed. Thank you!
Regards.
Sigurd.
Regards.
Sigurd.
C3X Release 2
New in this version:
- UI button for stack bombard
- Smarter rules for stack bombard
For the next version I plan to add some mechanism to bake the changes into the executable, so the mod can be used as a replacement EXE instead of run through the script. I'm also planning to look into implementing a disorder warning like I mentioned in the OP and the stealth attack issue mentioned by Civinator.
Lastly check out this little teaser GIF I made for stack bombard:
New in this version:
- UI button for stack bombard
- Smarter rules for stack bombard
- Considers improvements when attacking a city
- Many other cases handled, e.g. knows not to attack aircraft in airbase, aircraft with land artillery, airbase with aircraft on it, ...
- Fix for science age bug- Many other cases handled, e.g. knows not to attack aircraft in airbase, aircraft with land artillery, airbase with aircraft on it, ...
For the next version I plan to add some mechanism to bake the changes into the executable, so the mod can be used as a replacement EXE instead of run through the script. I'm also planning to look into implementing a disorder warning like I mentioned in the OP and the stealth attack issue mentioned by Civinator.
Lastly check out this little teaser GIF I made for stack bombard:
- Joined
- May 5, 2005
- Messages
- 8,884
This is great news! 
Flintlock thank you very much for all of your work! 
Another little (but important) fix, that is implanted in the Antal1987 4 and Tsubasanut exes, is the fix of the magenta beams in the C3C civilopedia images due to (in this case) sloppy programming by Firaxis:
A good thing to implant would also be the fix of the MUA (maximum units allowed on the map) of 8192 units in C3C. It seems this can be done more easily than the NCL patch (no city limits) as a working version with the fix of the MUA is included in the Tsubasanut exe.
And here are some thoughts about the No-Raze patch: The No-Raze patch is a must for all C3C scenarios with fixed cities on a map. For the standard epic game on random maps it is sometimes better for the AI that it is allowed to raze cities. So it could be a good idea to have a version of the 'Flintlock patch'
with the No-Raze component for scenarios and a version without the No-Raze component for the standard C3C epic game on random maps.
Flintlock thank you very much for all of your work! Another little (but important) fix, that is implanted in the Antal1987 4 and Tsubasanut exes, is the fix of the magenta beams in the C3C civilopedia images due to (in this case) sloppy programming by Firaxis:
A good thing to implant would also be the fix of the MUA (maximum units allowed on the map) of 8192 units in C3C. It seems this can be done more easily than the NCL patch (no city limits) as a working version with the fix of the MUA is included in the Tsubasanut exe.
And here are some thoughts about the No-Raze patch: The No-Raze patch is a must for all C3C scenarios with fixed cities on a map. For the standard epic game on random maps it is sometimes better for the AI that it is allowed to raze cities. So it could be a good idea to have a version of the 'Flintlock patch'
with the No-Raze component for scenarios and a version without the No-Raze component for the standard C3C epic game on random maps.
Last edited:
I'll add the pink line thing to the list as well. My priority is gameplay bugs but I'll get around to that one eventually. Removing the unit limit is something I've had in the back of my mind since the beginning. I've been reluctant to implement it since I can't easily and properly test that it's working, but if it's something people want I'll look into it sooner rather than later.
Rather than have multiple executables, my plan is to have one EXE that changes its behavior based on text configuration files. The mod already sort of works this way, NoRaze is not applied unless you edit config.txt to enable it. I've been holding off on doing a final implementation until I have a way of baking my changes into the EXE because it's easy to have a patcher just apply or not apply a patch depending on some config value but it's somewhat trickier to create a self-patching EXE.And here are some thoughts about the No-Raze patch: The No-Raze patch is a must for all C3C scenarios with fixed cities on a map. For the standard epic game on random maps it is sometimes better for the AI that it is allowed to raze cities. So it could be a good idea to have a version of the 'Flintlock patch'
Another advantage to having config files is that they can be layered on top of each other. In other words, my plan is that there will be a base config that players can set how they please for the epic game and then there will be scenario-specific configs that can override some settings necessary for the scenario e.g. enabling autoraze.
Progress report: Last week I implemented disorder warnings. That was pretty straight forward and only took a few hours. But more importantly, I also implemented a mechanism to bake the mod into the Civ executable. This was going straight fowardly too until I ran into a major road block, which I will now describe in detail. It doesn't really matter since I solved the problem, but still I want to talk about it after spending most of my Sunday working on it.
The root of the problem was a conflict between two restrictions, (1) all the contents of an EXE file must occupy a contiguous area of memory and (2) TCC can only output code to its final address in memory. In other words, in order to do code injection, the patcher program must first allocate memory at the same location that the code will eventually occupy in the Civ program, instruct TCC to compile code to that location, then copy it over, but this is difficult to do when injecting code into an EXE because in that case the code must be located along side the existing contents of the EXE where you can't easily allocate memory from within the patcher (I'm guessing that's because those are low addresses crowded by other allocations). When patching the Civ program after it's been launched this isn't a problem because you can just allocate memory at the same location high in the address space of both the patcher and the Civ programs, where there is plenty of space, and it doesn't matter that those memory blocks are discontiguous with all the others.
Working all day at this I came up with many workarounds. Such as (1) insert a bunch of padding into the Civ EXE so a contiguous area can be created high in the address space, but to make this work a lot of padding would be necessary, like at least 100 MB worth, and all that padding is wasted memory, or at least wasted address space. Or (2) have TCC compile to one location then modify the code it produces to work at a different location, but that would be a hassle to implement and probably error prone as well. Or (3) inject the code at the wrong location then include a tiny mechanism inside the Civ EXE that copies the injected code into the right location when the program is launched, but again that would be a hassle to write. Or (4) change the image base of the Civ EXE so the entire things gets loaded to a higher address, but then I'd have to adjust all the offsets used by the mod to compensate. Or (5) modify TCC to generate code suitable for a different location than where it's actually being written, but I had a look at the TCC source, and that looked like a hard change to make. Finally I came up with a good solution, (6) make the patcher itself an EXE file that occupies memory around the needed address and then use that memory as the compile target. That just means that the installer instead of being a C script is a C program that gets compiled then immediately run, but for a user of the mod there's no difference.
So anyway, I'm thinking the next release will be this weekend. The mod is in a state that I could just put it out right now but first I'd like to implement the dynamic loading of settings from config files like I described earlier. I'll also look into some of the remaining bugs so maybe I can include their fixes in the next release.
The root of the problem was a conflict between two restrictions, (1) all the contents of an EXE file must occupy a contiguous area of memory and (2) TCC can only output code to its final address in memory. In other words, in order to do code injection, the patcher program must first allocate memory at the same location that the code will eventually occupy in the Civ program, instruct TCC to compile code to that location, then copy it over, but this is difficult to do when injecting code into an EXE because in that case the code must be located along side the existing contents of the EXE where you can't easily allocate memory from within the patcher (I'm guessing that's because those are low addresses crowded by other allocations). When patching the Civ program after it's been launched this isn't a problem because you can just allocate memory at the same location high in the address space of both the patcher and the Civ programs, where there is plenty of space, and it doesn't matter that those memory blocks are discontiguous with all the others.
Working all day at this I came up with many workarounds. Such as (1) insert a bunch of padding into the Civ EXE so a contiguous area can be created high in the address space, but to make this work a lot of padding would be necessary, like at least 100 MB worth, and all that padding is wasted memory, or at least wasted address space. Or (2) have TCC compile to one location then modify the code it produces to work at a different location, but that would be a hassle to implement and probably error prone as well. Or (3) inject the code at the wrong location then include a tiny mechanism inside the Civ EXE that copies the injected code into the right location when the program is launched, but again that would be a hassle to write. Or (4) change the image base of the Civ EXE so the entire things gets loaded to a higher address, but then I'd have to adjust all the offsets used by the mod to compensate. Or (5) modify TCC to generate code suitable for a different location than where it's actually being written, but I had a look at the TCC source, and that looked like a hard change to make. Finally I came up with a good solution, (6) make the patcher itself an EXE file that occupies memory around the needed address and then use that memory as the compile target. That just means that the installer instead of being a C script is a C program that gets compiled then immediately run, but for a user of the mod there's no difference.
So anyway, I'm thinking the next release will be this weekend. The mod is in a state that I could just put it out right now but first I'd like to implement the dynamic loading of settings from config files like I described earlier. I'll also look into some of the remaining bugs so maybe I can include their fixes in the next release.
Node60
Prince
A slightly crazy idea.
It would be nice to add the "can't capture cities" attribute for units.
In the later stages of the game, an avalanche of attack helicopters and armored vehicles is used for blitzkrieg, while infantry units created during the game are almost useless. If you leave the possibility of capturing cities only for infantry units (strike units destroy all the defenders of the city, but only infantry can occupy it), on the one hand, it will give them value, on the other hand, it will complicate the tactical pattern of the campaign. Something like IRL - try to capture the metropolis with attack helicopters? And to introduce tank columns there without infantry cover is a very bad idea. To capture and control the settlements still need the good old infantry.
Something similar, I remember, was already in Civ4 - some units there could not capture cities.
However, within the existing program code, it will be very difficult to implement this (in my opinion), it will require reworking the editors, and, most importantly, it is unlikely that such a change will be able to comprehend the game AI.
It would be nice to add the "can't capture cities" attribute for units.
In the later stages of the game, an avalanche of attack helicopters and armored vehicles is used for blitzkrieg, while infantry units created during the game are almost useless. If you leave the possibility of capturing cities only for infantry units (strike units destroy all the defenders of the city, but only infantry can occupy it), on the one hand, it will give them value, on the other hand, it will complicate the tactical pattern of the campaign. Something like IRL - try to capture the metropolis with attack helicopters? And to introduce tank columns there without infantry cover is a very bad idea. To capture and control the settlements still need the good old infantry.
Something similar, I remember, was already in Civ4 - some units there could not capture cities.
However, within the existing program code, it will be very difficult to implement this (in my opinion), it will require reworking the editors, and, most importantly, it is unlikely that such a change will be able to comprehend the game AI.
Last edited:
I had a brief look at the code, this took me back to some parts I haven't looked at since I was working on the sub bug, and I don't think it would be all that difficult to implement this restriction for the human player. Basically, there's a function that moves a unit into a neighboring tile and it depends on another function that checks if the unit in question is allowed to perform the move, and they're already set up to reject moves in some circumstances like if you try to capture a city with a worker. So I imagine it wouldn't be too hard to intercept those functions and adapt them to disallow units of a certain type to move into a city. The problem, like you guessed, would be the AI. The thing that made the submarine bug so difficult (I don't know if I said this before but it took me about two weeks to solve) is that the AI uses a very different code path to move its units from the human player, and even worse, that code is complex and hard to analyze.
Regarding the editors, my plan is that you would instead make those kind of changes in the text config file. For example, if I were to modify the EXE to disallow certain land units from entering cities, it would know which ones to disallow by reading their names from a list in a specially named config file. Then you wouldn't need a special editor, though the disadvantage would be that your mod would be two files instead of one. Maybe packing the config file into the BIQ would be a better idea, but I don't know about that since I haven't looked into the BIQ format at all.
That leads nicely into a little update: in the last few days I implemented loading of settings from a config file. For now just from one file with a hardcoded name, but still it's nice to be able to change the settings without having to reinstall the mod. Also I looked into that stealth attack issue and think I have a workaround. My idea is that the top unit on a tile will always count as a stealth attack target so that way you get to choose even if there's only one conventional target in a stack, but this has the added bonus that you can choose the top unit, ie, choose not to do a stealth attack. A word of warning though, I haven't implemented this yet and I'm not 100% sure it will work how I hope.
Node60
Prince
I think this is very good news.
Even if this restriction only applies to human players, it will already lead to interesting results. And for AI, this will serve as some compensation for the problem with ground bombardment and the inability to use other features, for example, the inability to use ground transporters for infantry, used in some mods.
Jorsalfare
Prince
Regarding making certain units unable to capture cities: A unit with hidden nationality cannot capture cities when the owner civ is played by a human player, but if played by AI, it can (and will) capture cities. This indicates (to me, at least) that the inability to capture cities isn't only directly linked to the unit itself, but also to what the player is allowed to - or disallowed to do (with certain units). Does this make any sense?
Last edited:
If it's something people want I can implement that, but I'm holding off on that sort of thing until all the mod infrastructure is in place. Also it's interesting to note that the AI does know how to use land artillery in the field but it's only willing to do so with artillery that it's captured, not built. I've been thinking about changing that but I'm not sure whether it's actually a bug.
That's good to know about hidden nationality units. I doubt that was a deliberate design choice by Firaxis, it's more likely IMO to be another case where they added a restriction to the interface then forgot to hold the AI to it as well. Other cases being the AI seeing resources it doesn't have the tech for when considering city locations, the fact that the AI can upgrade and move units on the same turn, and (so I've heard) that the AI can use scientific great leaders to rush production.
Tsubasanut
Chieftain
Flintlock, thank you for your hard work. Glad someone with programming skills finally tackling Civ 3 issues.
I was recently mulling around CIV 3 somewhat restored C code (by Antal I believe) and debugging exe with IDA, but I just do not have enough knowledge or time to be successful.
The problems I was trying to tackle:
1. Forbid to place a city near enemy city, a request from Civinator, makes total sense.
2. Option to limit railroad speed to at least 16 tiles/turn, preferably 12. This is my personal pet peeve. But I remember a lot of people were opting for that as well.
There is just not enough space in the code to replace zeroing of movement points for railroad movement for a quick fix, and going Antal way to implement a workaround through clean space is the only option, but I suck with assembler coding).
If you can look into this problems, it will be great.
Oh, and I have a list of all changes in EXE for Antal/Scryer patches if anyone needed, attaching a file.
I was recently mulling around CIV 3 somewhat restored C code (by Antal I believe) and debugging exe with IDA, but I just do not have enough knowledge or time to be successful.
The problems I was trying to tackle:
1. Forbid to place a city near enemy city, a request from Civinator, makes total sense.
2. Option to limit railroad speed to at least 16 tiles/turn, preferably 12. This is my personal pet peeve. But I remember a lot of people were opting for that as well.
There is just not enough space in the code to replace zeroing of movement points for railroad movement for a quick fix, and going Antal way to implement a workaround through clean space is the only option, but I suck with assembler coding).
If you can look into this problems, it will be great.
Oh, and I have a list of all changes in EXE for Antal/Scryer patches if anyone needed, attaching a file.
Last edited:
- Joined
- May 5, 2005
- Messages
- 8,884
Tsubasanut, thank you very much for the No Raze - No Unit Limit - fix of the SGL- and graphical civilopedia issues biq you have created. 
In the current testgames of the next version of SOE, running with the next version of the CCM2.50 expansion, your biq seems to work very well. In the next version of SOE there is a small town of honour for you on the SOE map (of course at no strategic place in WW 2, so other gamers will not be irritated).
Flintlock, the other big thank you very much of course is for you:
You are doing a brilliant work !
Your work around of the stealth attack problem is sounding very interesting.
Two notes about C3C settings, that were posted in this thread:
1. Capturing of cities by HN land units of the human player:
It is correct, that HN land units of AI civs even can capture cities without declaring war. This is true for cities hold by the human player and for cities that are hold by AI civs. Of course when in war AI HN units can capture cities, too.
The human player cannot capture cities with HN units, when not being in war with the civ that holds this city. But when being at war with that civ, even the human player can capture cities of the AI by HN units. The decisive difference for HN units played by AI civs and played by the human player is, that the human player additionally needs to be at war with that civ.
2. No distance between cities: This is a special setting in the Antal1987 biqs. The AI isn´t using that feature. So this option is nice for creating canals on the map, it allows the human player the exploit, to create a town with barracks in it, directly bordering to an AI town.
This is no problem, that must be fixed in the normal C3C biq, as here a new town can only be created with at least a two tiles distance.
In the current testgames of the next version of SOE, running with the next version of the CCM2.50 expansion, your biq seems to work very well. In the next version of SOE there is a small town of honour for you on the SOE map (of course at no strategic place in WW 2, so other gamers will not be irritated).
Spoiler :
Flintlock, the other big thank you very much of course is for you:
You are doing a brilliant work !
Your work around of the stealth attack problem is sounding very interesting.Two notes about C3C settings, that were posted in this thread:
1. Capturing of cities by HN land units of the human player:
It is correct, that HN land units of AI civs even can capture cities without declaring war. This is true for cities hold by the human player and for cities that are hold by AI civs. Of course when in war AI HN units can capture cities, too.
The human player cannot capture cities with HN units, when not being in war with the civ that holds this city. But when being at war with that civ, even the human player can capture cities of the AI by HN units. The decisive difference for HN units played by AI civs and played by the human player is, that the human player additionally needs to be at war with that civ.
2. No distance between cities: This is a special setting in the Antal1987 biqs. The AI isn´t using that feature. So this option is nice for creating canals on the map, it allows the human player the exploit, to create a town with barracks in it, directly bordering to an AI town.
This is no problem, that must be fixed in the normal C3C biq, as here a new town can only be created with at least a two tiles distance.
Last edited:
tjs282
Stone \ Cold / Fish
@Flintlock:
Awesome work on smart stack-bombardment!
Is there any possibility of a similar fix for smart-stacking Worker-actions?
Specifically, I'm thinking about clearing pollution in the late Industrial/early Modern eras (after Industrialisation+Sanitation, but before Ecology+Recycling).
Even post-Rep-Parts it's still a pain, because if you want it done in one turn, just on flatland it needs 12 Slaves (6 Workers) for non-Industrious civs, 8 Slaves (4 Workers) for Industrious civs; multiply those unit-numbers 2x for Hills/Forests/Marshes, 3x for Jungles/Montains/Volcanoes. All that clicking wears out mouse-buttons like nobody's business! Sure, automating Pollution-clearance is possible, but it only carries over from one turn to the next if the automated Workers aren't done-in-one. Otherwise, once their current tile is clear, if there's no other pollution left, they just go to sleep, and (irritatingly) don't wake up when more pollution appears later.
I'm already in the habit of keeping my Workers stacked in useful numbers -- but being able to select just one Worker to send the whole stack off to work, would be a great improvement.
Likewise, Foresting requires confirming for each Worker that you want to replace any existing irrigation/mine. Just having to confirm once per Worker-stack would be sooo much less tedious...
Awesome work on smart stack-bombardment!
Is there any possibility of a similar fix for smart-stacking Worker-actions?
Specifically, I'm thinking about clearing pollution in the late Industrial/early Modern eras (after Industrialisation+Sanitation, but before Ecology+Recycling).
Even post-Rep-Parts it's still a pain, because if you want it done in one turn, just on flatland it needs 12 Slaves (6 Workers) for non-Industrious civs, 8 Slaves (4 Workers) for Industrious civs; multiply those unit-numbers 2x for Hills/Forests/Marshes, 3x for Jungles/Montains/Volcanoes. All that clicking wears out mouse-buttons like nobody's business! Sure, automating Pollution-clearance is possible, but it only carries over from one turn to the next if the automated Workers aren't done-in-one. Otherwise, once their current tile is clear, if there's no other pollution left, they just go to sleep, and (irritatingly) don't wake up when more pollution appears later.
I'm already in the habit of keeping my Workers stacked in useful numbers -- but being able to select just one Worker to send the whole stack off to work, would be a great improvement.
Likewise, Foresting requires confirming for each Worker that you want to replace any existing irrigation/mine. Just having to confirm once per Worker-stack would be sooo much less tedious...
Similar threads
