Advanced Civ

[f1rpo]

@crullerdonut: Thanks for investigating. I haven't really gotten to the bottom of that problem. Unfortunately, it never occurs for me when I attach a debugger; due to some race condition apparently. So my best idea has also been to go back to earlier versions. I've found that it occurs even earlier than v0.97, at least as far back as January 2020, if I disable the compiler option for global optimizations. Well, eventually I've just blindly tried switching the call to the EXE that repositions the camera after drafting with the call that makes the drafted unit the selected unit, and this fixes the problem on my end; will have to see if it also works for you.

@krasny:

[...] Several turns pass with Bismarck having a stack next to my unoccupied city and not taking it. Weird behaviour or a deeper plan?

I don't think that should happen in any situation. It would be nice if the AI were able to tell when an empty city is a trap or distraction, but no such behavior is implemented. A savegame would be helpful.

[...] Bismarck then attacks, takes the city, then moves out, the Ethiopians then move into the city, then move out deeper into my territory, so I move into the open city with my main force.

If that means the city was left completely empty, then that also sounds like a bug/ oversight to me.

@eXalted: Maybe the bombardment of undefended cities is somehow related to what krasny describes. As for the AI Catapult approaching the city in your savegame, I'm not sure why it decided to do that. It has the "reserve" AI role. Maybe it was trying to attack the worker near the city – though it seems that the worker was already guarded by a Chariot when the AI moved next to the city. Hm, come to think of it, perhaps it had meant to attack that Chariot. Moving several tiles in order to attack some stray unit with non-lethal damage is a bad play. I'll try to check in the AI code if that can really happen. Fwiw, when I ended the turn, the AI changed to a defensive strategy and therefore decided to withdraw the Catapult. Another turn later, it changed its strategy again (I think because another AI unit had been completed), and the Catapult moved toward the now undefended worker – along a path that didn't go near the city. That's a bit erratic, but perhaps not a common problem ...

Disrupted production: I think I've managed to fix this; thanks. It's a result of my efforts to make human players immediately choose a new production order after losing access to a required strategic resource. (BtS lets the production continue for one turn, which gives rise to this exploit.)

I'll try to upload an update with recent bugfixes in the next couple of days. Thanks, all, and merry Christmas
(if applicable).

 

[eXalted]

@f1rpo thank you for all the effort you are constantly putting into this!

Marry Christmas to you too!

 

[crullerdonut]

I've found that it occurs even earlier than v0.97, at least as far back as January 2020

Good to know it's not just my hard drive at least!

Well, eventually I've just blindly tried switching the call to the EXE that repositions the camera after drafting with the call that makes the drafted unit the selected unit, and this fixes the problem on my end; will have to see if it also works for you.

Maybe you could send, in a DM or somewhere else, a version of 0.98b with everything identical, except for the change you're thinking about. If that one change alone fixes the issue for me, then that would indicate that it's the cause, right? (Although I suppose that there could be other conditions which cause it. )

(Since I'm not going to develop the mod for too much longer

That definitely would be very sad, but I guess nothing lasts forever. It would be the end of an era, that's for sure. But developing these things takes a lot of work, so it's not fair of us to expect you to do it forever if it's not something you are interested in. That said.... although Civ4 is getting up in age, there still are many things to do with it, many things to spark the imagination. After all, you still have your big list of more sweeping changes you've been mulling over, such as bigger changes to the tech tree, overhauling the Slavery mechanic, etc. Your work is fantastic so I think that everyone here can agree that we'd like to see more of what you can dream up.

Thanks, all, and merry Christmas

And a Happy New Year!

 

[eXalted]

@f1rpo Thank you for the great update and mention!

Downloading it right now!

 

[f1rpo]

Maybe you could send, in a DM or somewhere else, a version of 0.98b with everything identical, except for the change you're thinking about. If that one change alone fixes the issue for me, then that would indicate that it's the cause, right? (Although I suppose that there could be other conditions which cause it. )

The K-Mod function call that I've moved is:

lookAt(getPlot().getPoint(), CAMERALOOKAT_NORMAL)​

Even if thats (by itself) fixes the problem – since K-Mod has no problem with drafting, some AdvCiv change must be responsible. Presumably it's something in this Git commit because I can't reproduce the issue with the preceding one. Maybe there's really some error there that I'm not seeing, or I've stumbled upon a hidden problem with the timing of the K-Mod code (and with the lookAt function in the EXE – surely that function shouldn't just cause the main map to disappear).

I've gone ahead and uploaded v0.98c. If it doesn't work for you, then I'll have to try (?) something else, get back to you again etc.; I didn't want to delay the update for that much longer.

[...] I guess nothing lasts forever.

I've been meaning to end this project for three years:

[...] Since K-Mod getting stuck in v1.45 your Advanced Civ is the way into Civ4 future

I don't think either mod will go much further; but I hope I'll get to something I can call v1.0.

For v0.99, I still want to add some BUG options, maybe a couple of balance changes, other than that, it's done. v1.0: Probably best to stick to misc. tweaks. Then obviously there'll have to be some small v1.0x updates with bugfixes. Maybe it'll peter out like that over the next year.

That said.... although Civ4 is getting up in age, there still are many things to do with it, many things to spark the imagination. After all, you still have your big list of more sweeping changes you've been mulling over, such as bigger changes to the tech tree, overhauling the Slavery mechanic, etc. Your work is fantastic so I think that everyone here can agree that we'd like to see more of what you can dream up.

That balance/ historicity overhaul was always more of a mental exercise for me. Well, and I wanted to see if some other modder might be interested in collaborating on some part of it. That could still happen – but would probably be a mod of its own. (Thanks for your kind words, also.)

And a Happy New Year!

I've come across a Bach cantata today titled "praise god! the year is ending" (BWV 28; it follows "who knows how near to me is my end" in Bach's catalog).

 

[Lanstro]

Thanks for the update - and happy new year!

Another idea/request please - I've always found the various random events that spawn a stack of barbs at your border are ridiculously unfair. Can you either disable them, or tone them right down? Eg just one spearman/horse archer instead of 3-4.

 

[Imperator Knoedel]

Well, and I wanted to see if some other modder might be interested in collaborating on some part of it. That could still happen – but would probably be a mod of its own.

Boy, would I!

 

[crullerdonut]

Even if thats (by itself) fixes the problem

Whatever you did, the problem has been fixed! To be very sure of this, I moved between versions and tried Drafting in the same gamesave in each version of AdvCiv:
0.97c: works normally
0.98-pre3: black screen
0.98: black screen
0.98b: black screen
0.98c: works normally
So apparently there was some change between 0.97c and 0.98-pre3 which caused the issue. I've included the gamesave I used, just for the sake of completion, but it appears that you've solved the problem so it's probably unnecessary. It's certainly impressive that you could think "oh, maybe this is what caused it" without being able to test it yourself, and then actually be correct on your first try.

Boy, would I!

There is a lot of material to think about. Just for example, there was discussion in another thread about the placement/timing of Triremes in the tech tree, and how they fit with the historicity of bronze-working technology in real life.

Another minor balance change that this game brought to mind is to make Triremes available a little earlier.

In the next post, you can see my mention of how there are unused assets in the game, such as the alternative Farm (?) Improvement icon, and I speculated on some other uses for it.

Perhaps they were thinking of doing so: check out this unused icon

And then you add in f1rpo's list of pie-in-the-sky changes.
And of course there's my idea for having 2 Spy slots for Courthouses instead of 1. (Please! )
What I'm trying to say is that there is an incredible amount of creative potential for this game, even if you stick to relatively moderate changes.

For v0.99, I still want to add some BUG options, maybe a couple of balance changes, other than that, it's done. v1.0: Probably best to stick to misc. tweaks.

Maybe it'll peter out like that over the next year.

You could always move from 0.99 to 0.100, and 0.101, 0.102 etc. Or you could go 0.99a through 0.99z and then 0.99α through 0.99ω. There's no reason to go to 1.0 right away and then stop, right?

 

[Imperator Knoedel]

There is a lot of material to think about. Just for example, there was discussion in another thread about the placement/timing of Triremes in the tech tree, and how they fit with the historicity of bronze-working technology in real life.

I'm... a bit more radical than that.

 

[TheOtherOne]

Hello, just wanted to post and thank you for all the hard work in making this mod. I've lost more often than I've won (typically in the late Ancient period) often due to being attacked by an aggressive leader like Shaka or Stalin whom I manage to defend against but then having two or three others attack once they notice weakness. Being "lucky" enough to start in a resource-rich area is a curse as much as a boon.
Conversely other leaders are much less violent so I like having the diversity of experiences and not just that every AI is out to wipe me out. Starting alongside Cleopatra, Elizabeth,or Lincoln were much more pleasant experiences.

Not every story has to be dog-eat-dog. I think AdvCiv does a decent job of providing that balance while making the game pretty tough. At this point who I start next to defines my civilization as much as where I start or who I start as.

 

[devolution]

That balance/ historicity overhaul was always more of a mental exercise for me. Well, and I wanted to see if some other modder might be interested in collaborating on some part of it. That could still happen – but would probably be a mod of its own. (Thanks for your kind words, also.)

Seeing as I was pondering something very similar a couple of years ago (before WTP started consuming all my modding time), I'll probably be happy to join in

 

[Leoreth]

As someone who joined in on these musings, I fully support the idea of making those changes in a separate modmod, if at all. I think it's better for the identity of AdvCiv to be an AI and playing experience only mod.

 

[crullerdonut]

That sounds like a cool option, so I'll have to give it a shot playing with that option. Does the pre-contact score show up, once you gain enough to see all demographics?

Yes, it should. Otherwise, to be consistent, I'd have to leave a gap in the graphs whenever the player falls behind the view-demographics threshold for a few turns; wouldn't want that. I agree with what you wrote in July – that scores shouldn't be treated as secret once they've been on public display. I've disabled part of the change by default only because I don't want players to get confused by incomplete score graphs.

I've tried playing with the Partial Scores option in BUG options > Advisors. I thought it was really neat, and it worked perfectly!
In my game, I started to see the score history (but not other demographics) for the leaders on the other continent. Of those leaders, I only got enough to see Sitting Bull's demographics, and, sure enough, his was the only score graph that extended back to the beginning of the game.

 

[Leoreth]

Sorry if I am asking something that is already in BULL, but all its small improvements are hard to find in the documentation. I have three QOL requests that I think are universally useful if you move units around in large groups (which you should if you don't want things to be tedious). Personally I have groups of the same type (workers, siege units, city attackers, etc.). The following default behaviours would be great to have:

1. When a group of workers finishes building an improvement and only some of the workers' moves were required, workers that still have a move should be split off into a new group and selected next. Otherwise their turn will be wasted, and avoiding this causes micromanagement and disincentivises worker groups.
2. When a group of military units is ordered to attack the last defender of a city, they all move into the city to capture it. This is not always desirable: damaged units will be left on the attacking tile and may be defenseless. Instead, the attacker should be split off from the group and move into the city on its own, so that the player can decide if the remaining units in the group should also move into the city or stay where they are (or any split). Otherwise it requires micromanagement to select an individual attacker after checking that only one defender is left, or disincentivises using groups when attacking cities (although they make it easy to use the attacker with the highest chances).
3. When a group containing siege units is ordered to bombard a city, but not all siege units are required to reduce its defenses to 0, the game seems to choose the units that bombard arbitrarily, but it seems to be their index in the group, or maybe the consecutive global unit ID (which means, oldest units go first). This is often not desirable, because oldest units often have the most experience and promotions. If those are city attack promotions, the best units to attack have been wasted on bombardment. It would be preferable if the game picks the units with the best bombard modifiers first, then the units with the worst combat odds (e.g. old or damaged units) so the siege units with the best combat odds remain able to attack. Also, after performing the bombard action, units that have used their turn should split off into a separate group and the remaining group should be selected to attack, if wanted.

 

[crullerdonut]

The following default behaviours would be great to have:

Wow these are all great quality-of-life improvements! I think that we've all wanted these for a long time.

I was just thinking about the Bombard thing the other day. It's pretty tedious to carefully comb through your stack of Cannons, just looking for the few scattered ones with the Bombard promotion. They don't even get grouped together! Why can't the game use those first?

#2. is the exact reason why I don't use stack attack, even though I'd like to (especially when it gets laggy at the end of a game). You can't just leave your wounded guys hanging there! So I attack one-by-one, to ensure that I capture the city with just one attacker, and then I can choose who goes in after that.

#1 is something that I think about but, in the end, I don't usually worry about it too much. At the stage of the game where I have groups of Workers, I usually am not too worried about extreme worker micromanagement, even though I know that it would benefit me slightly. I just can't be bothered. But I welcome the change because, I think, one of AdvCiv's strengths is that it gets rid of silly microoptimization strategies and loopholes which make the game tedious.

Along these lines, there's another thing that I was thinking about, but that maybe would be a little harder to implement. I wish that there was a way to put a marker down somehow and make it so that Workers never improve that tile ever. This would:
a. allow the player to selectively save certain tiles, while turning their Workers on various forms of Automation
b. allow the player to cut off access to Coal, Oil, etc. for Unhealthiness and Global Warming purposes, with the knowledge that some trade-route Worker isn't going to plop down a Fort
c. make sure that Workers don't build a Road/Railroad over a spot where you are trying to have a Forest grow, for National Park purposes
I was thinking maybe re-using the Alt-S sign mode, except making it Alt-P (for protect) or something. Then a little sign with PRESERVED or something like that would be shown (or maybe a Cancel symbol) there, and Workers would have a little code added so that they ignore those tiles when they are Automated. This might be difficult to implement, though, so it's another pie-in-the-sky idea for me.

 

[Leoreth]

Yeah, your comments are exactly my thoughts. Using stacks would be great but are not worth the risk, so we are stuck not using them despite their benefits.

 

[MarkM]

First, let me tell you that I'm a brand new user of AdvCiv; just discovered it in November. My main objective in posting is to thank you, this mod has almost made this old game new again to me, in the balance tweaks and AI overhaul.

My secondary objective is to let you know that there are still people discovering this!
My tertiary objective is to make a couple suggestions, both minor and uncontroversial hopefully?

First, one strange aspect of civ is the lack of ability to destroy ("pillage") roads within your cultural borders. The mechanism to do so obviously is in place (since you can do it everywhere else) so it must be just a matter of removing whatever block is there against tile culture? I can't think of any rational or game-play reason why it should be blocked, except that it prevents you from doubling the odds of forest/jungle spread. But I also see that you have written some "thinking out loud" thoughts in the manual (forget the term you use for the section) that the late game needs perhaps some player tools to combat global warming? This by itself isn't enough, but it's at least a step in the right direction?

K-Mod mostly lacks BULL, and I've only rectified that on a case-by-case basis, merging some BULL code and sometimes implementing my own solutions. There's still some semi-important stuff missing. I have a list, but it's always helpful to read what features are actually missed by players.

In that spirit, here's a BUFFY feature I miss: when incomplete objects in the build queue are within 5 turns of decay unless they are resumed, a warning message is shown after the object name in the build queue, to the effect of "will lose X in Y turns", I think in parens? (sorry, gooing from memeory & haven't played in a long time). Unless I missed it there is no way to turn that interface option on, nor to even know it's happening unless you happen to remember the hammer count from the previous turn? A message in the turn notifications might also/alternatively be useful ...

Thank you again! I see you now have a 0.98c version, just downloaded it to give a new game a spin!

 

[TheOtherOne]

But I also see that you have written some "thinking out loud" thoughts in the manual (forget the term you use for the section) that the late game needs perhaps some player tools to combat global warming? This by itself isn't enough, but it's at least a step in the right direction?!

I don't play much in the modern era (I tend to end up in the equivalent of WW1 or WW2 and after several years of grinding conflict i retire and start a new game - or i just get bored from the repetetive city management) so global warming hasn't affected me much. I did have a couple games where I tried building preserves and destroyed improvements to try to encourage the spread and that was a large dissapointment (IE - nothing happened). What I ended up doing was I would move a worker onto a tile, open up the world builder, remove the worker and add a couple forests in its place.

 

[f1rpo]

Finally trying to get on top of this thread again. I'll have to put off responding to anything concerning future directions for yet another day (or two...) though. I also haven't gotten to the two most recent posts (already 10 days old) yet.
@Lanstro:

Another idea/request please - I've always found the various random events that spawn a stack of barbs at your border are ridiculously unfair. Can you either disable them, or tone them right down? Eg just one spearman/horse archer instead of 3-4.

BtS places 4 units on Standard-size maps and adjusts that number by 1 for each size category by which the map size differs from Standard. The current formula in AdvCiv (numUnitsUprising in EntryPoints\CvRandomEventInterface.py) is instead based on the tech era of the player for whom the event triggers:

Ancient    2
Classical  3
Medieval   5

(I don't think they can occur later than that; it's a kind of quadratic progression.)
If that's still too many, then it would be helpful to see an example.

Whatever you did, the problem has been fixed! To be very sure of this, I moved between versions and tried Drafting in the same gamesave in each version of AdvCiv: [...] It's certainly impressive that you could think "oh, maybe this is what caused it" without being able to test it yourself, and then actually be correct on your first try.

Great, thanks. For the record, I was able to reproduce it myself and to test my bugfix/ workaround; I just wasn't sure that it would always work (and on all platforms) – because I don't understand what exactly was going wrong.

You could always move from 0.99 to 0.100, and 0.101, 0.102 etc. Or you could go 0.99a through 0.99z and then 0.99α through 0.99ω. There's no reason to go to 1.0 right away and then stop, right?

Right; I guess I've been steering the version numbering a bit toward this conclusion.

I've tried playing with the Partial Scores option in BUG options > Advisors. I thought it was really neat, and it worked perfectly! [...]

Thanks for the screenshots. Good to see that it works on the BUG Graphs tab too – as it very much should, but I don't think I had tested that.

@TheOtherOne: Thanks for the feedback.

I've lost more often than I've won (typically in the late Ancient period) often due to being attacked by an aggressive leader like Shaka or Stalin whom I manage to defend against but then having two or three others attack once they notice weakness. [...] At this point who I start next to defines my civilization as much as where I start or who I start as.

The AI is supposed to hold back when it comes to dogpile wars in the early game. Perhaps what you describe is rather that separate wars throughout the late Ancient + Classical era gradually wear you down. Well, if you run into a situation where AI civs gang up on you "early on" when you're already on the ropes, then I'd like to look at a savegame to check if the fair-play code needs to be adjusted.

Ideally, starting next to Shaka shouldn't be strictly harder than starting next to Ashoka, but I guess that goal can't really be accomplished within this mod. One potential advantage of Shaka as a neighbor is that he could attack a third party, allowing the human player to share in the loot. Maybe on the highest difficulty levels, when early wars of conquest aren't otherwise feasible for the human player – but a high difficulty level will also make it extra difficult to deter a Shaka-on-human attack, so ...

Edit: Link to numUnitsUprising function added.

 

[f1rpo]

@Leoreth

[...] The following default behaviours would be great to have:
1. When a group of workers finishes building an improvement and only some of the workers' moves were required, workers that still have a move should be split off into a new group and selected next. [...]
2. When a group of military units is ordered to attack the last defender of a city, [...] the attacker should be split off from the group and move into the city on its own [...].
3. When a group containing siege units is ordered to bombard a city, [...], it would be preferable if the game picks the units with the best bombard modifiers first, then the units with the worst combat odds (e.g. old or damaged units) [...].
Also, after performing the bombard action, units that have used their turn should split off into a separate group and the remaining group should be selected to attack, if wanted.

Sorry if I am asking something that is already in BULL, but all its small improvements are hard to find in the documentation.

I don't think BULL makes any under-the-hood changes in that realm. K-Mod has added code that lets fast units pillage first when a group is ordered to pillage. That template has made it much easier to implement item 3. The order I've implemented for bombardment prefers high bombard rates, tries to avoid overshooting and, as a tiebreaker, prefers bombarding with cheap/ inexperienced units. Here's the source code:
GitHub.com/f1rpo/...//CvSelectionGroupAI.cpp#L614 (getting called fwiw from CvSelectionGroup::startMission)
I'm not taking into account hitpoints because, if the player is able to conquer the city right away, he or she may prefer to move damaged siege units into the city so that they can heal asap. Ideally, I guess, the game should use AI code to check whether the city is likely to be taken. Let's perhaps see if that problem comes up in a game; always easier to fine-tune based on a savegame.

Items 1 and 2 didn't require a lot of code to be added (Git commit), but are probably still not easily portable because they're embedded in K-Mod code. I've implemented split-upon-completion behavior for Build and Bombard missions (as requested) and also for Air Bomb, Pillage and Move. That is, a group of 2-move and 1-move units will split in two when it reaches its destination. That may sound potentially annoying, but BtS stops unit cycling in that case, which isn't any better I think – and it's nice to have consistent behavior for Build and Move missions. I haven't applied the same rules to the Route-To mission because that would cause workers to split up only once the whole route is completed; along the way, they'd stick together. As it is (i.e. as in BtS/ K-Mod), players would do well to split worker groups up before issuing Route-To commands or, for that matter, automating workers. Those are high-level commands, so this shouldn't be a big inconvenience. It might be nice to have the game automatically split up workers upon a Route-To command; perhaps still to be implemented.

The above applies only when no further missions are queued (Shift key). As far as I can tell, a worker (in BtS?/K-Mod/AdvCiv) will get started on the next mission in the queue even if the other workers aren't ready yet – so long as the next mission is in the same tile. Good enough I think.

I've expanded item 2 to apply to all attacks that kill the last enemy defender, not just city attacks. I agree with you and @crullerdonut that it's a change for the better; not just when using the Stack Attack option, but also when group-attacking one by one – it's easy to miss the point where there is just one defender left. I wonder if karadoc, for one, would disagree. He had gone through some pains to make sure that Gunships (which can't capture cities) aren't left behind when a stack captures a city. Maybe it just hadn't occurred to him that all units should be left behind instead. I'm tending (contrary to what the Git commit linked above says) not to add an option for this until someone complains. A multiplayer-safe BUG option would take a disproportionate effort to implement. (I'll probably make it singleplayer-only if an option is needed.)