More no-rng options

Leodim

Warlord
Joined
Nov 25, 2013
Messages
108
Following the no-rng Battles option that works well here and is currrently on Pull Request, (it is discussed here https://forums.civfanatics.com/threads/quick-questions-quick-answers.647831/post-16459422 ) and which I still have to apply to air combat too, here are some other options on my TODO list.
And yes, I might seem a bit maniac on the matter, totally personal ofc, this is just options that would be disabled by default.
I like the fact that each option can be chosen individually, to suit everyone's style. The only matter is that it would increase the number of checkboxes in options significantly (5).
Feel free to comment.

1) No-rng subdues (hunting)
Each unit that can fight has a new not-so hidden var attached to it. Some sort of subdueCount.
It starts at 50. Each fight, it is increased by the chances of subdue the opponent (so if 0, stays the same). If this sum is >=100 then the opponent is subdued and the subdueCount goes back -100.
Example with 37% : 50, 87, 124=24 (success), 61, 98, 135=35 (success), 72,...
So overall each unit will have exactly the expected % of success. Promotions still have the same "game value".
Evolving values are not a problem.
The only thing is that it is now predictable, so you can plan a bit. Which while this is an aberation to most, is totally the goal to me :D
UI wise, using same example as above, the text at rollover "37%: Subdue Animal" would become "37%: Subdue Animal (+50=No)" then next fight "37%: Subdue Animal (+87=Yes)" or something like that. Trying to keep it plannable but very short.

2) No-rng capture
Exactly the same as subdue but with another var for each unit (the one that captures), lets call it captureCount.
Ofc the reduction to capture chances from the other unit still apply, it simply still changes the computation of the +value (and if 0 well then 0, works). No changes to be done or problems here either.

3) No-rng spies (chances of success/failure)
Same idea as subdue but civ-wide instead of unit-wide. Because if it was linked to each spy, none would be able to ever survive in the long run unless it only does actual 100% jobs.
So here it makes the game a tiny bit easier since you can plan which one to "suicide" and which ones to keep if you are carefull. RP-wise we can totally call them decoy: you lure the counter-intelligence services after some spy so you can succeed in your other more important mission.
Cost-wise (spy points) it doesn't change a thing because failed mission cost 0 anyway. Cost-wise (unit/prod) it reaches indeed the average expected, minus the small bonuses of having better promotions in the long run since you can plan who to keep. Seems ok to me.
Will have to think about the "success but discovered part", shouldn't be hard to include.
Ofc you can still keep the option deactivated, which is the default to all of this stuff, don't worry.

4) No-rng withdraw
Again not really possible to do it unit-linked because each failure = unit death (as for spies) so 49% would be 0% in fact.
Debatable:
We could have attached it to the civ doing the withdraw roll (as for spies), but I wonder if it's not better to link it to the human player civ. And let it be owner based when no human player involved on either side of the withdraw.
I mean my goal is to make things more predictable for the player, keeping the average result of each mechanic. So that he feels neither lucky/unlucky overall and able to plan. I don't really care that the AI/Animals/... is averagely lucky or not on small actions (it already cheats due to handicap anyway).
Let it be two new numbers oppWithdrawCount and myWithdrawCount, for each civ. And always use the human value when one of the protagonist is human.
So yes it also means you can "plan your bad luck" on a small animal running away before avoiding a real AI civ's unit running away. Again while this is an aberation to most, it is predictable so I think I'm ok with it.
And if both player are human in a fight (multi), let the owner do the counting, as per AI vs AI.
The other possibility is to have only one of the 2 var, but I think I like it less.

Again, feel free to comment.

EDIT : And I admit I give 0 promise as to IF or WHEN this will be done (I hope I will do it ofc), but still nice to plan it and share ideas for now anyway.
 
Last edited:
Disagree with Hunting/Capturing - it should be more of a surprise outcome for my taste.
Withdraw should have a per-clash counter (the mini-fight inside the big-fight, the stuff that has First Strikes and so on), since in many cases a unit has the chance several times per fight, if its Withdraw range is high enough (meaning: it could try to withdraw at 20%, 15%, 10%, 5% Health, and then just outright die at 0% if all else fails, all of which happening during a single fight).
 
Just added air battle to RP. Working on subdue atm (outcomes).

Disagree with Hunting/Capturing - it should be more of a surprise outcome for my taste.
Withdraw should have a per-clash counter (the mini-fight inside the big-fight, the stuff that has First Strikes and so on), since in many cases a unit has the chance several times per fight, if its Withdraw range is high enough (meaning: it could try to withdraw at 20%, 15%, 10%, 5% Health, and then just outright die at 0% if all else fails, all of which happening during a single fight).
About Hunting/Capturing:
Yeah, removing all surprise is not for everyone's taste. Just leave it unchecked (default) I guess.
Overall, the goal is that if you change nothing in options, their default values change nothing in the game at all.

About Withdraw:
I didnt know a unit has several chances per fight, in my (possibly wrong) memory in BTS it was a simple roll when a unit would otherwise die inside the combat loop.
Or you mean it could be added? Oh I get it now. Will definitely look at that and how it could be done "per-fight", if possible with high enough precision.
The thing is I want it predictable for this no-rng option. Not only "more likely" because of more rolls and more possible outcomes.
And I also want to avoid the issue X% = never and X+1% = always, since outcome is still binary in the end; even if there is a hp-loss factor in case of success.
The goal is X% is indeed X% (average luck overall) but you can predict when which will roll. Again clearly not for everyone's taste I admit.
 
Last edited:
Dude, you are mixing things up here.
C2C has a very different battle mechanic than Vanilla BtS.
It literally splits any single battle into a whole lot of smaller attacks that slowly chip at Health of both units, starting with something like 10% Health per hit.
And I know that "this unit starts withdrawing at this Health factor" uses numbers like 40% or even 70%.
Which is why you CAN see animals (pesky Pigeons, lol) literally running away WITHOUT A FIGHT altogether - they just NOPE out of it at the very first hit.
Sure, I don't know for 100% whether a unit tries withdrawing again after it fails once (and DOESN'T die yet), but it should be logical to assume so.
Thus I said that it would be funny to see that chance of withdrawal accumulate DURING THE FIGHT ITSELF (it tries, and tries, and tries, and... finally succeeds... at 5% Health).
But overall... I kinda don't like your concept that much to begin with, sorry.
 
Dude, you are mixing things up here.
C2C has a very different battle mechanic than Vanilla BtS.
It literally splits any single battle into a whole lot of smaller attacks that slowly chip at Health of both units, starting with something like 10% Health per hit.
And I know that "this unit starts withdrawing at this Health factor" uses numbers like 40% or even 70%.
Which is why you CAN see animals (pesky Pigeons, lol) literally running away WITHOUT A FIGHT altogether - they just NOPE out of it at the very first hit.
Sure, I don't know for 100% whether a unit tries withdrawing again after it fails once (and DOESN'T die yet), but it should be logical to assume so.
Thus I said that it would be funny to see that chance of withdrawal accumulate DURING THE FIGHT ITSELF (it tries, and tries, and tries, and... finally succeeds... at 5% Health).
But overall... I kinda don't like your concept that much to begin with, sorry.
Hmm I think you missed this part in OP : https://forums.civfanatics.com/threads/quick-questions-quick-answers.647831/post-16459422 (the spoiler part)
It already works well in C2C concerning battles hp outcome (and in other mods/civcol/BTS I included it localy, for personal play) and this part is currently on pull request.

This thread is about including the concept to other mechanics in C2C as options, without modifying the mechanics itself (or the least possible). Some are binary, and some indeed are outside resolvecombat (for example, outcome for subdue).
Currently doing the subdue option. Will keep you posted if I ever get to the withdraw (laziness :lol: and also too much work piling on irl).
 
Quick question (might not be the right place):
I never looked at saved game files.
- How do you add lets say an int per unit to the savefile? I don't even know if it's c++ side or not. I might find docs on my own but would save me time.
- Also, in the case the saved file doesn't include said variable (saved with previous version), is there a way to assign it a default value at loading or the save files won't just load because of format change (game breaking)?

EDIT : appart that save part (which is crucial), no-rng subdue option is done and working here. I also have to apply it to "tales" etc. now that I think about it ;)
 
Last edited:
Quick answer to myself, seems to be (didn't try yet but that's my bet) in void CvUnit::write(FDataStreamBase* pStream)
With things like WRAPPER_WRITE(wrapper, "CvUnit", m_iDCMBombRange);
(resp. read)
But is there an accessible versioning tag at the start of the save file or somewhere, so that if save version is below, we assign a default value instead of breaking the loading?
I'll look for that for now.

EDIT : I found C2C_VERSION but I didn't find it inside of saved games yet. I'm pretty sure it (or something like it) must be there though.
EDIT2 : I found SAVE_FORMAT_VERSION but it's either 3 or 4 (v43, v44 I suppose), which is a bit limited tag-wise. Still looking.
Well I could of course keep my save since I can do the write part, compile, save, then do the load part, compile, load.
But it will only works for me, no-one else's game in progress would be compatible.
I guess I still have some really ugly solutions like cheating on iNumGameOptions which doesnt seem to be used (not a member) but I was looking for cleaner ways. Maybe with m_paGameOptionInfos? I know I do a monologue here :lol:

EDIT3 : I made some ugly test on iNumGameOptions and created an invisible dummy game option.
Good side : it works both with previous v43 saves and the new one I just did.
Bad side : this is sooo ugly code-wise and evolution-wise I'll never commit this. It is really a shame :lol: :lol: :lol:
 
Last edited:
Bad side : this is sooo ugly code-wise and evolution-wise I'll never commit this. It is really a shame
Don't worry about that. We have lots of modders in the code that kinda enjoy doing refactoring for the sake of correction/clarification/beautification and so on. The one thing to worry about properly with options is to keep enumeration of them aligned or you'll break in-progress games... place at the end and update the enums. The thing about save wrappers, place at end always and never remove later or try to re-organize them unless very carefully and in full knowledge you're breaking save games to do so. If you place at end of the read and write sequences, you'll be fine to not break saves.

I like the option and welcome you to the team - we need more sorting out how to get involved.

I really will be soon looking to create a modder's training zone with videos and stuff but it will still take some time to get on top of my business requirements first.
 
If you place at end of the read and write sequences, you'll be fine to not break saves.
Really? You mean I could just get rid of the ugly test on the dummy option, place it at the end of CvUnit::read / write and it'll all work like a charm with previous saves?
That would be great! I didn't even try that, I was so sure this would break.

I like the option and welcome you to the team - we need more sorting out how to get involved.
Thanks! :)
But I have to be honest: I do have a lot of work piling on and I really don't know when (or if) I'll be able to get back to finish all of this.
I'll just try to PR what I did so far so the contribution is not lost; and for the rest, we'll see.
 
Indeed it seems putting it at the end of the read method is safe without version check. :)

Added no-rng subdue to PR.
Still needs to apply it to "tales" and other sea subdues.

EDIT : sea+tales done and PRed.

EDIT2 (to avoid useless bump) : spy espionage missions done and PRed.
Notes:
- Captures seems to be python side onresult instead of outcome this time (dunno if there is a UI preview)
- Withdraw covers multiple sub chances or types indeed (didnt check if preview alt-ctrl is right, I suppose so).
 
Last edited:
Top Bottom