Advanced Civ

[f1rpo]

I´ve found about this mod today, what would be the recomended difficulty for a vanilla emperor difficulty player?

Also i find really interesting the topic of combat reworking. [...]

I'll read that tomorrow (and will think about @devolution's ideas). Difficulty: Probably Monarch. Though if you're winning 100% on vanilla Emperor, then perhaps Emperor, but I guess for a first game, Monarch can't be too far off.

By the way, known bugs in the v0.94e beta version (will be fixed in the 0.95 release, hopefully still this month, – likely in exchange for new bugs):
* AI almost always unwilling to be hired for war.
* Will probably crash upon liberating a colony.
(The beta may still be preferable to 0.94 due to various quality-of-life improvements.)

 

[f1rpo]

Adaptive Limited Combat Rounds [...]

It sounds like this could make the combat round limit less arbitrary, and it avoids having very low survival odds, which, on the attack, are somewhat implausible with regard to morale. Can we come up with a simple formula for this, or some, say, boardgame-like rule that determines when the number of rounds is decreased? If not, a variation of the withdrawal ability could be more intuitive. The current ability checks after each hit if:

getDamage() + iAttackerDamage >= maxHitPoints() && GC.getGameINLINE().getSorenRandNum(100, "Withdrawal") < withdrawalProbability()

One could simply use a lower HP threshold.

ZOC-xUPT [...]

Potential problems that I'm seeing: How can a very large stack on a chokepoint be assailed? Attacking in waves might work if the defender selection is randomized, but new AI code would seem necessary for that. And could a single unit force a large stack to split up, and, at a chokepoint, to queue up?

I don't like the idea of devolution mainly because it seems hard to integrate and would probably hurt the ai more than the player

Any specific concerns (beyond mine above)? It seems that we all agree that a stack shouldn't be allowed to make arbitrarily many attacks per turn. Combat width and @Petromax's proposal are also in that vein:

Another idea for limiting stacks would be to have a limit to the number of attacks allowed from each tile on a turn. It wouldn't really punish stacking, but it would encourage splitting them up more.

This particular rule could be bypassed by fast units, which is kind of flavorful (attacks from the flanks), but a little fiddly and possibly too powerful. Counting attacks made against a tile sounds safer.

In case of multiple engagments from different directions, I could think of two solutions: Either that if attacking from different positions that there is an extra amount of width added if expended or that if attacking a force that has expend all the width, there are far less combat rounds.

I guess this would take both the number of attacks made from and the attacks made against into account. Also conceivable.

Also, I've been experimenting with the Civ4: Reimagined collateral damage scheme [...]

I like the idea of taking the range differences between melee, archers, firearms and artillery off the map, so to speak – meaning that attacks still happen only between adjacent tiles. I don't like that a humble Archer has four(!) range-related abilities (see attached screenshot). The addition of a new unit stat (range) also makes this a fairly high-profile change. However, if we can replace the vanilla first-strike ability (entirely) with a range ability that can be explained in one line (two lines?) of game text, I'll be interested; considering that the vanilla ability is also somewhat difficult to understand and may lead to problems with the (adaptive) combat round limit. Although, surely, ranged infantry, artillery and light cavalry can't all have abilities that weaken defenders.

[...] So my solution would go on an opposite direction to what it has been proposed on this thread. Instead of making combat more complex with more rules, it needs to focus on making it as depth as possible without affecting AI. It also needs to be fair on losses for both sides, taking into account that a unit with one hp should take almost same amount of production as to replace a dead unit.

I think we're all mostly on the same page. To demonstrate my like-mindedness:

a limit on free healing could make the game a lot more challenging against the AI, as even a technologically and tactically superior player would inevitably incur some economic cost at war. [...] Any measure against SoD should, in my opinion, only slightly punish large stacks so that the AI doesn't have to be changed.

Perhaps there are some differences in the attitudes toward randomness and the scope of the changes we'd be willing to make.

Finally I don't think that puntual randomness is bad for the game, and losing a 99% figth, while frustrating, shouldn't be removed. After all most of the times you will win those figths, and the other side of the coin is when you get that result (winning a 5% chance figth with the last defender and holding the city one more time feels truly epic).

I'm very rarely happy to win against the odds – maybe only if it evens out earlier bad luck, but preferences vary on this. Last year, there was a similar discussion in the Dawn of Civilization subforum (link). But it looks like we can't get rid of the small probabilities anyway, so ... :shrug:

As for healing, see the next post.

 

[f1rpo]

On healing: I was thinking of introducing a new process, perhaps called "Build Reserves," allowing cities to convert production (possibly also food) into "reserves," which are then consumed by units that heal. Disbanded units could also add to the reserves pool (I'd really like to give players an incentive to disband units), and reserves could also be consumed by unit upgrades. However, your idea with the production penalty would be more low-key, which I generally like, and would avoid having to switch cities in and out of reserve-building, i.e. less micromanagment.

IF the third rifleman is hurt but there are no hammers left to heal it will need to wait for the others units to heal ( so a queue it's created in the order of healing needs).

I'd rather let the unit owner decide which units to heal first and whether to heal them at all. Though, if players aren't forced to heal units, the rules for "fear for our safety" and military happiness ("the troop presence impresses us") will have to be revised, so that damaged units can't be used as garrisons without ever healing them. Either way, some UI work is needed so that the player can tell which units are going to heal and how high the production penalty is.

Of course the system can be make much more complexs, with a base free repair production , population being need to miantain units, different max healing rates depending on where the unit is etc..

I'd like to allow some amount of free healing because hitpoints, to me, don't just represent how many men are still standing, but also exhaustion, ammunition shortages etc., conditions that aren't expensive to amend, but take a bit of time. I'd call this free healing "resting," and that's also where I'd let the Medic promotions (and Hospital) apply. Another idea would be to allow healing (beyond resting) only in friendly cities and to charge the cost entirely on the respective city (through a production penalty or a conversion process).

All in all, non-free healing is going to be a lot more work than some of the other ideas tossed around. In particular, collateral damage could be nerfed just through XML; the defender randomization looks, to me, like a very cheap change to make; and a fixed combat round limit is already implemented and just needs to be ported. Which is why, although I agree that this has much potential, I'd keep it on the backburner for now.

Instead of a stack being form of individual units attacking individually, combat should make each stack face each other. When combat is initiated, units will attack in a semi-random manner thougth weigths (so for example injured units would try to not engage, medics will have lower priority etc) while defenders will also be mostly randomized. I really liked the suggestion to make defenders choose units randonmly and then choosing the best counter, maybe the same could be use so that each side picks n combatants and then it follow conventional unit picking rules.

That sounds like Dale's CASA mod, or a less ambitious take on that idea. What would the combat odds preview for this look like? Anyway, this seems like too much of a departure for me.

Collateral damage should be either removed or redone in a different way, [...]

It would be a bit of a shame as there is a good amount of AI code for collateral damage, and it's a pretty flavorful ability.

[...] promotions in general should be nerfed ( something i would do anyways as I think that they are a bit tad high)[...]

I see that Civ 4 Reimagined does this; e.g. Combat I grants just 7% strength. My thinking was to reduce the amount of XP instead by reducing the XP multiplier of the attacker from 4 to 3 (and leave the defender's multiplier at 2). I don't know if that would suffice.

Also if on the mood it could be greatly expanded: [...]

No great expansions for me; too much broken stuff to fix (not just with combat). But still interesting to read.

 

[Pepo]

Any specific concerns (beyond mine above)? It seems that we all agree that a stack shouldn't be allowed to make arbitrarily many attacks per turn. Combat width and @Petromax's proposal are also in that vein:

Mainly that from other mods that I have play, ZoC and xUpT are things that the ai isn't good at handling. While I like the idea of ZoC, the Air opponents don't know where to build chokepoints and how to use then. Having additionally a dynamic limit, seems , a priori, that it could end up with lots of strange cases, like for example, declaring and having two stacks facing each other once at war. If xUPT could be implemented satisfactory I wouldn't be so negative; but all my experiences seem to indicated that it mostly benefit the player

Also about my stack suggestion, I didn't expect it to accept it, as it is probably too complicated. I did find out today about Dale mod, but other mods that integrated didn't recommend is mechanic. I wish I could try to do it myself, but learning python C++ seem way to complicated

 

[f1rpo]

[...] While I like the idea of ZoC, the Air opponents don't know where to build chokepoints and how to use then.

Identifying chokepoints just based on the (unchanging) geography shouldn't be that hard (though not exactly trivial). The AI could then prefer such spots as city sites and build Forts there. But going around a well-defended spot or breaking through seems challenging.

Having additionally a dynamic limit, seems , a priori, that it could end up with lots of strange cases, like for example, declaring and having two stacks facing each other once at war. [...]

Ah, that's a good point. Thanks for elaborating.

Also about my stack suggestion, I didn't expect it to accept it, as it is probably too complicated. I did find out today about Dale mod, but other mods that integrated didn't recommend is mechanic. I wish I could try to do it myself, but learning python C++ seem way to complicated

I had hoped that Civ 5 would move in that direction, but ... quite the opposite. Looks like the recommendations against Dale's stack attack are made mostly because of "stability issues." That doesn't sound so bad. But the UI support seems to be, well, missing; no meaningful combat odds are displayed.

 

[f1rpo]

@devolution: Some further thoughts on first strike vs. range: As you had probably already realized, range equals the number of first strikes in Civ 4 Reimagined. Well, that's mostly a technicality; I'd still argue that the flavor of the two abilities/ effects is so similar that they should be mutually exclusive. On second thought, I actually like first strike much better:
* It obviously has the benefit of familiarity.
* An attack range is something that every non-melee unit has, whereas "first strike" is a relative term, so it makes sense that it isn't given to every ranged unit, but just to those that can shoot farther than their contemporaries; e.g. not to Rifleman.
* "First strike" is slightly more general – it also works for units that sneak up on their target. Indeed, in AdvCiv, submarines have first strikes.
So I'm retracting my own (offhand) proposal to replace first strike with some form of an attack range. Your point that Civ 4 Reimagined "neatly solves the issues of not having an early siege unit to do collateral damage when facing\countering an early rush" remains, but perhaps, with the adaptive combat round limit, a first-striking Archer will already behave similarly – without stepping too far out of its customary role as a city defender.
--

v0.95 will take a few more days. I've been held up by a memory error. (Takeaway: It's not OK to add data members to CvReplayInfo.)

 

[keldath]

hi,
i look forward for 0.95,
i hope it will be good for mp games.

and i dont like much the Reimagined ranged system, but their resource system is a blast.

 

[devolution]

@f1rpo
You may have noticed that you have a new fork

I've finally realized that AdvCiv is the way forward as K-Mod is getting stale. Currently working on a number of enhancements ranging from improvements to the build system, bench-marking, optimizations, various AI improvements and the usual bug fixes. The revamped combat system is ofc not forgotten though...

Anyways, I noticed that there is an attempt to delete a null pointer (report) in WarAndPeaceAI::Team::~Team. It triggers every time I terminate the program it seems.

The SAFE_DELETE wrapper should take care of it:

WarAndPeaceAI::Team::~Team() {

    SAFE_DELETE(report);
}

 

[keldath]

devolution, do you also developing advciv?

 

[devolution]

devolution, do you also developing advciv?

I am working on a number of improvements that may or may not end up in AdvCiv *proper*. Still haven't pushed any commits but I am hoping to polish off at least two significant features that have never been implemented in any civ4 mod by the weekend. Btw, it's not the combat system yet

My apologies to @f1rpo for hijacking his thread with my blabbering

 

[f1rpo]

i look forward for 0.95,
i hope it will be good for mp games. [...]

Regarding multiplayer, I've just fixed some bugs (mainly one tough bug – it was like fighting the Balrog: "far under the living earth, where time is not counted [...] into dark tunnels" ), and now the mod seems quite stable, i.e. no problems when I run two instances on my PC on AI Auto Play into the midgame, click on various buttons, make some deals with the AI, some attacks, end the turn a few dozen times and respond to AI offers. That said, there are most likely some issues that only become apparent when actually playing a game.

And there's the potential problem of floating point arithmetic in synchronized code. (Nightinggale explains the issue here under "Why we can't use floating point calculations." ) Between my PC and my notebook, I'm not experiencing any problems, but those are both AMD processors. Between AMD and Intel, games might go OOS frequently and, if so, there are only one or two things I can try (see "003g" in the manual); replacing all the floating point calculations isn't going to be feasible.

Btw, I've claimed twice that I'm about finished with the new version, and that wasn't really untrue ... I've just kept revisiting some issues that I had put on the backburner because they seemed too difficult at the time (like doing some multiplayer testing). I'm going to play one more test game and, hopefully, that will neither expose a serious problem nor remind me of any loose ends, and then I can finally wrap this up.

You may have noticed that you have a new fork

I wouldn't have noticed, but that's good news.

I've finally realized that AdvCiv is the way forward as K-Mod is getting stale.

I like to think that it's getting to a point where there are few downsides compared with K-Mod. The floating point thing could be one, scalability (MAX_CIV_PLAYERS) another and I guess generally the larger volume of changes compared with BtS, low-key as they may be.

Currently working on a number of enhancements ranging from improvements to the build system, bench-marking, optimizations, various AI improvements and the usual bug fixes.

"Build system" refers to the compilation process I suppose? About benchmarking, I've read your proposal on the "We The People" issue tracker (link). Are the performance and AI optimizations related to the code by Koshling that you've mentioned once? That's on my radar too, but I won't get around to it anytime soon. I've adopted a couple of small changes, but still have about 1000 SVN revisions from the early days of C2C and RAND to review.

I hope I can merge whatever you come up with. But I suppose it could also happen that you merge some of my commits? Because in that case I'll have to be a lot more considerate about what I change and how I commit it.

Anyways, I noticed that there is an attempt to delete a null pointer (report) in WarAndPeaceAI::Team::~Team. It triggers every time I terminate the program it seems.

Ah, many thanks. I did see an error now and then when exiting but had no idea how to debug that. I see that the report object gets deleted already by closeReport. And I guess SAFE_DELETE should really always be used in such circumstances. Well, old code by now.

The revamped combat system is ofc not forgotten though...

On that topic, last week I read a post by @Toffer90 in the C2C subforum (quoted below) and it gave me the following simple idea for a ZoC rule: Units that attack from a city or fort receive a combat or withdrawal chance bonus when they attack units that have just moved from one tile adjacent to the city or fort to another. I don't think that this would address any pressing problem, but it should make strategically placed defensive works useful without making them an insurmountable obstacle for the AI. I would interpret movement within the ZoC as ignoring the threat from the garrison, moving in file instead of a battle formation and generally remaining unprepared for battle.

On a related note, I'm not too happy with the rule I recently added that causes units (including units in cargo) to lose all movement points when they cross a border on the same turn as war is declared. I've come to think that a kind of soft ZoC rule that prevents ships from unloading when next to a water tile with a hostile unit (of greater or equal strength) would be more plausible and effective – but would also require some changes to the behavior of AI naval assault stacks and to CvUnitAI::AI_guardCoast.

[...]there are many cases in history where armies passed right by some decently manned forts to attack scarcely manned forts, the well manned forts had strategical problems to overcome to simply leave the forts on expedition against a sometimes superior or matched opponent when the nation at a whole were undermanned militarily. Some times zones of control would have to be deactivated even for well fortified forts but how could we simulate that in C2C. By letting each player use their units to actually attack out from the forts manually to stop the enemy advancement through the cluster of forts by harassment and attrition. Future projects like TB's planned supply line feature could greatly enhance the importance of forts by allowing a player with an inferior army easier ways to harass enemy armies and their supply lines making it a risky move to push on through the cluster due to damage per turn (or through events triggered by lack of supply) or a heavy healing penalty.

The zones of control feature is a lazy way to simulating the role of forts, that imo downgrades the better simulation that is already in place.
The full stop, a a aaa you cant move your units there because they might be ambushed, removes the ability for players to actually ambush the enemy in such situations.[...]

Edit: Dead link manual 0.94f removed

 

[keldath]

take the time in testing, youll be more happy after you maxed that. new version can wait
good job !

 

[devolution]

I hope I can merge whatever you come up with. But I suppose it could also happen that you merge some of my commits? Because in that case I'll have to be a lot more considerate about what I change and how I commit it.

My intention is to set your repo as my upstream so I will simply rebase regularly on your master branch, in other words I am not "hard-forking" AdvCiv since the last thing I want is to to fracture the "DLL modding scene" even more.
I want to stay current with AdvCiv and hopefully I can live with all of your changes It would be nice if AdvCiv would eventually replace K-Mod as the baseline for future AI-focused mods.
This approach is similar to WTP, which aims to become "the DLL" to be shared by other Colonization mods.

I will ensure that my commits are put in distinctive branches to make it a bit easier to to track what's going on. Also, Inspired by you, I am going to maintain a separate documentation file where I can elaborate on my commits

A bit unrelated, but why don't we ask the moderator(s) for a separate sub-forum ? It would make it far easier to discuss specific topics. Also, we'd have a decent shot at bringing in more people that could be interested in helping out the AdvCiv effort.

 

[f1rpo]

[...] I want to stay current with AdvCiv and hopefully I can live with all of your changes [...] I will ensure that my commits are put in distinctive branches to make it a bit easier to to track what's going on. Also, Inspired by you, I am going to maintain a separate documentation file where I can elaborate on my commits

Since you're pretty adept with Git, I suppose when I e.g. replace 10 occurrences of GET_PLAYER(getOwnerINLINE()) with kOwner in some AI file, I'm not really causing extra work on your end? Well – please let me know when I do and don't inconvenience yourself with writing any documentation specifically on my behalf; I'm also fine with a typo-filled stream of consciousness.

A bit unrelated, but why don't we ask the moderator(s) for a separate sub-forum ? It would make it far easier to discuss specific topics. Also, we'd have a decent shot at bringing in more people that could be interested in helping out the AdvCiv effort.

In terms of drawing attention, I kind of like having this one thread near the top of the modpacks forum, and a subforum with just a couple of active users can seem a bit like a ghost town. That said, I don't know what you've been working on and how much may still be coming up, so it's hard to say for me how awkward it would be to discuss that here and if there's an alternative to a new subforum. As for the combat system, we could just move to a new thread in Creation & Customization.

 

[devolution]

I apologize for "jumping ahead" like this and I agree that we may not need a dedicated subforum at this time.

In other news, I have pushed some commits (the updated build system) and there are many more to come...

 

[devolution]

Just pushed the in-game benchmark and some assorted optimizations. The link time optimization (enabled by the target "Final Release")that I added in the last batch of commits accounts for close to a 10% reduction of AutoPlay time.

Update: I added a comment to your recent commit (GitHub)

 

[f1rpo]

Just pushed the in-game benchmark and some assorted optimizations. The link time optimization (enabled by the target "Final Release")that I added in the last batch of commits accounts for close to a 10% reduction of AutoPlay time.

That's music to my ears. My usual speed test (still without your benchmarking changes) also runs significantly faster (13 minutes instead of 15 and a half) when I just add the GL flag to my current makefile. I wonder if the original DLL was linked with that option. Anyway, more mods should use it.

I suppose the Visual Studio files are going to require the 2017 version? Well, I should migrate to that anyhow, so I'll try it with both.

Update: I added a comment to your recent commit (GitHub)

That worked; I got an e-mail notification.

 

[devolution]

That said, I don't know what you've been working on and how much may still be coming.

Changing the topic a bit again , but I just had to mention that I'm amazed by the level of detail (and your audacity!) in your proposals concerning "future gameplay changes". In fact, you've inspired me to collect my own thoughts on how BTS could be improved and make them available through google docs (need to edit it before making it public though). I've mentioned before that I have my own private overhaul (K-mod based) mod and I was preparing to rebase it on top of AdvCiv. However, after seeing your proposals, I now realize that our work would overlap quite a bit so it would make sense for us to thrash out some ideas together so that we could share some of the effort and hopefully avoid silly mistakes.

 

[keldath]

hi,
glad to see v095 is up.
i will try and play it if i will have some time soon.


wheres the chngelog?

 

[f1rpo]

hi,
glad to see v095 is up.
i will try and play it if i will have some time soon.

Thanks for noticing.

wheres the chngelog?

It's this monstrosity: Updates tab