Flintlock
Emperor
- Joined
- Sep 25, 2004
- Messages
- 1,181
Thank you all for your kind words.
I don't have any problems with space or writing assembler. I've built the mod infrastructure up to the point where I can easily program in C code referring to structs and functions in the base EXE then compile and inject it into the EXE. The injector writes the new code into a new PE section so there's no problem with space. It's all open source, I encourage you to have a look at how it works if you're interested in this sort of thing.
I'll look into changing the rules for city placement at some point, maybe even for version 4. Changing railroad movement might be difficult but I can't say for sure without investigating it deeply. What worries me is that there might be some part of the AI logic or pathfinding that assume railroads have infinite movement.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).
I don't have any problems with space or writing assembler. I've built the mod infrastructure up to the point where I can easily program in C code referring to structs and functions in the base EXE then compile and inject it into the EXE. The injector writes the new code into a new PE section so there's no problem with space. It's all open source, I encourage you to have a look at how it works if you're interested in this sort of thing.
Thanks for posting this. I went ahead and integrated the fix for the pink line in the civilopedia background. Also it's interesting to see that Antal's fix for the science age bug is quite different from mine.Oh, and I have a list of all changes in EXE for Antal/Scryer patches if anyone needed, attaching a file.
Well, unfortunately it didn't work. I was hoping that I could get the top unit on a tile simply by iterating over the tile's units the normal way and picking out the first one but sadly it doesn't work that way. So instead I implemented a more basic fix for this issue, just patching a check for "> 1" into ">= 1". This way you get the stealth attack choice popup even when there's only one option. It's not ideal IMO but it's good enough for now. I did some testing and the AI doesn't seem to have any problems with this.Your work around of the stealth attack problem is sounding very interesting.
I don't see any reason why stack worker actions would be impossible, it's just a matter of the time necessary to program it. Thinking a bit about how this would work, something like stack-railroad-to could be implemented the same way as stack bombard since it's also a mode action. For the normal worker actions, you'd CTRL+click the button to have all the workers in a stack do it, that's definitely easier than adding a bunch of extra buttons and avoids cluttering the UI. Removing the redundant confirmation popups should be easy and I've added it to the list for the next release after the one tomorrow (and hopefully I won't forget).Is there any possibility of a similar fix for smart-stacking Worker-actions?