Is it possible and could probably be done using my existing scripts, but would likely require some work.
Wow, thank you very much, Civinator. I had no idea! And thank you general-jcl as well, for the excellent idea. I admit I'm quite interested in trying it. If we could get spring-summer-fall-winter (12 folders) transitions to work, I could also almost certainly hook it into my existing scripts such that we could have any hour + any month of the year.
I believe the most obvious disadvantage of the night cycle would be to restrict vision: Even if you stand on a mountain, you can just see 1 tile ahead. And at sea you also see just 1 tile, unless you have radar, etc.
This is an equally interesting idea.
It looks like a great addition to the game. How long did it take you to convert the entire terrain, including scripting and manual work? I’m wondering how quickly Ares’s terrain pack could be converted using your method, if Ares doesn’t mind, of course.Is it possible and could probably be done using my existing scripts, but would likely require some work.
Adjusting brightness, hue, saturation and so on is done with one script. A second script then creates the various light effects. It does this by using "light annotation" files I made by hand, essentially using special reserved colors which are ignored by script one. This was a labor of love but took a while. One would likely need to do a similar annotation to create snow, fall leaves, etc. With the right colors it could probably be made to look like seasonal effects, but we'd have to probably discuss more before jumping into it, and I would want community help with the annotation work.
I may be able to think of some ways to automate part of this work; let me meditate a bit on that
Movement restrictions could probably be implemented via Lua script, but again here I defer to Flintlock.
Great, thank you. I'd guess about 10 hours to understand C3X code + 10 hours to draft and tune the scripts (w/ huge help from ChatGPT) + ~8 hours of annotation over 3-4 weeks. Obviously if I had to start again it would be much faster now.
Probably, but it depends on what the specific issue is. Can you give more details? Ideally you could give me a save file and/or instructions on how to reproduce the bug.
Sure. There are two points in the game code where it enforces the city limit, and then there's the technical limitation, the reason that there is a limit. The enforced limits can easily be set lower than the technical limit. If you're curious, one of those is in the code to create a city, it's why the game stops you from founding and displays "Too many cities" once you reach the limit, and the other is in the AI logic to make the AI stop trying to found cities once the limit has been reached.
The mod relies on a base game function to find units to disband on bankruptcy. So it's not trivial to make it skip units that don't require support, I'd have to modify that function. The original developers must have forgotten to check for that. I can see that the function skips over units with the "king" and "flag unit" abilities at least. And yes, modifying the AI not to bankrupt itself with unit costs would probably be difficult. There's a simple solution, which is to negatively perfume units for AIs as they go beyond their free unit support limit. That will cause them to build improvements instead and, in the extreme case, choose to build wealth instead of more units. That's a pretty blunt solution, though, so it might not work well.
Is it just me, or is this actually a big mistake? Requiring support is an independent property of being a king or a flag unit. The editor allows you to create king units and flag units that may or may NOT require support. It is therefore illogical to check any property other than whether support is required for a given unit. The game simply lacks an OPTIONAL unit property of being disbanded due to bankruptcy, which could also be easily selected for each unit. In addition, many mods use king units as regular units, which means that they cannot be disbanded even in situations where they should be due to bankruptcy. So this bug also works in the opposite direction, and units are incorrectly protected while others that should be protected are not.
It's not a mistake from the point of view of the original developers - having a king or flag unit disband due to lack of funds would be a game-breaking bug in a game where those features were being used as originally intended. (E.g. a civ disappears suddenly because the king was accidentally disbanded).
This would not be a game-breaking bug if these king or flag units did not have the requiring support box checked and if the disband function correctly determined who to disband. The basic prerequisite for disbanding due to lack of funds should be whether the unit requires support. Or is it not? I consider the disbanding of units that do not require support to be counterintuitive. If the user wanted units that did not require support to be disbanded as well, this should be an option and NOT a default enforced setting.
On the Steam version, custom music simply doesn't work for play-by-email. The base game music is loaded instead.
I need to look into it.
