Single Player bugs and crashes v35 download - After the 18th of August 2014

I released a colony through the F1 screen, and it caused three volcanoes to erupt!:lol:
Save available.
 
When using a continents map and selecting a 'random' number of land masses... it often picks waterless, cake sheet as an option. As this is the single most resource intensive amp type and completely the opposite type I wanted... please remove this as a result.

Not only are huge portions of the tech tree useless (naval) and nonsensically required to get far, but I get major confusion as I run into 'Shark Bay' and the like on these maps.

I keep having to scuttle games from this and can't tell until a few hundred turns in unless I spoil the map by going into the world builder.
 
When using a continents map and selecting a 'random' number of land masses... it often picks waterless, cake sheet as an option. As this is the single most resource intensive amp type and completely the opposite type I wanted... please remove this as a result.

Not only are huge portions of the tech tree useless (naval) and nonsensically required to get far, but I get major confusion as I run into 'Shark Bay' and the like on these maps.

I keep having to scuttle games from this and can't tell until a few hundred turns in unless I spoil the map by going into the world builder.

That occurs when the python script for the map you chose doesn't have coding within it for the size of map you chose.
 
[ about earning money for disbanding splitted units ]

hmm... there was an attempt to keep this in ratio as well... I may have to go back and look into this again apparently. That is if we get to keep Size Matters at all.

I am not a programmer (however, I do some numerical simulations) but I can imagine how it could be done. If you have a record with unit data, make one more field (could be even ShortInt/Signed Char/whatever), let's say n. Value 0 would mean that the unit is neither split nor merged, each merge would increase n by 1 and each split would decrease n by 1. Let's define effective number of units in one unit N:=3^n (a real number). Then:

- money for disbanding would be (base money for disbanding)*N, rounded down if necessary
- total maintenance cost of all units of this type would depend on Ntot=the sum of all N's, rounded up
- total number of national units would be equal to Ntot
- when splitting, promotions like Lead by Noble or Lead by Great General should be lost.

In my recent game I have made two tests with national units: in my main military city (tons of XP, free promotions and production bonuses)

- I kept producing Tlatico (?) War Priests and merging them. I ended up with 2 super-units consisting of 27 units each (3 merges) while normally I could produce only 15, then after Smithing I upgraded them to Swordsmen (for free, because of The Art of War and IIRC Seti Pir)

- I made a super-unit consisting of 9 Spartan Warriors, attached a Noble and split the unit; after one split each of the units had "Led by Noble" promotion; I suspect it would be similar if I attached a GG/Hero.

I think dropping Size Matters would be a wrong decision, because it adds a new depth to military strategy... and AI sometimes merges or splits its units. I wondered why one of the rival civs split Archers to many small units but I guess they wanted to get the advantage of their shots (their strength or chance of success should also depend on N).


S.
 
[ about earning money for disbanding splitted units ]



I am not a programmer (however, I do some numerical simulations) but I can imagine how it could be done. If you have a record with unit data, make one more field (could be even ShortInt/Signed Char/whatever), let's say n. Value 0 would mean that the unit is neither split nor merged, each merge would increase n by 1 and each split would decrease n by 1. Let's define effective number of units in one unit N:=3^n (a real number). Then:

- money for disbanding would be (base money for disbanding)*N, rounded down if necessary
- total maintenance cost of all units of this type would depend on Ntot=the sum of all N's, rounded up
- total number of national units would be equal to Ntot
- when splitting, promotions like Lead by Noble or Lead by Great General should be lost.

In my recent game I have made two tests with national units: in my main military city (tons of XP, free promotions and production bonuses)

- I kept producing Tlatico (?) War Priests and merging them. I ended up with 2 super-units consisting of 27 units each (3 merges) while normally I could produce only 15, then after Smithing I upgraded them to Swordsmen (for free, because of The Art of War and IIRC Seti Pir)

- I made a super-unit consisting of 9 Spartan Warriors, attached a Noble and split the unit; after one split each of the units had "Led by Noble" promotion; I suspect it would be similar if I attached a GG/Hero.

I think dropping Size Matters would be a wrong decision, because it adds a new depth to military strategy... and AI sometimes merges or splits its units. I wondered why one of the rival civs split Archers to many small units but I guess they wanted to get the advantage of their shots (their strength or chance of success should also depend on N).


S.
A good list of some considerations to work in soon. I was only considering dropping SM due to some memory problems we appeared to be having.

Again, will just need to review the way the programming was setup in regards to the costs for disbanding again. It's supposed to work pretty similar to what you described.

after one split each of the units had "Led by Noble" promotion
Yeah, this really should remain but only on the first unit, not all of them... something else to correct for sure. Thanks for the tip.
 
Yeah, this really should remain but only on the first unit, not all of them... something else to correct for sure. Thanks for the tip.

Yes, it sounds better than to remove the promotion at all. But it should work also in the opposite direction: a GG or Noble at one unit should carry to a greater group. BTW: I have made a test with a Hero attached to one of the groups of 27 units and after one split I had 3 units led by a GG...

I reconsidered my suggestions about n and N and I think everything should be made on integrals. Let nmin=0 be associated with the smallest possible group and nmax (10?) with the greatest one. n0 will be the default n for a newely produced unit and n will be the actual number for a given unit (+1 for each merge, -1 for each split).

N:=3^n (so for a newely built unit N=3^n0)
Nmin=3^nmin=1
Nmax=3^nmax (I don't remember nmax, but if it is 20 it would be difficult to fit it to the 32-bit signed integer)
Ntot=(the sum of all Nmax for all units of a given type, so it should be either 32-bit for nmax about 10 or 64-bit for nmax about 20)

Maintenance costs and effective number of national units should be based on (Ntot/3^n0) rounded up, money for disbanding should be equal to (base money)*(Ntot/3^n0).

Why integers? In order to avoid inaccuracies like: 1.000001 rounded up = 2, 0.999999 rounded down is 0.

S.

Edit: if a GG/Noble remains at the first unit, what to do with the promotions from the GG/Noble line for the other units? Perhaps these promotions would be removed but the player could replace them with some other promotions?
 
Yes, it sounds better than to remove the promotion at all. But it should work also in the opposite direction: a GG or Noble at one unit should carry to a greater group. BTW: I have made a test with a Hero attached to one of the groups of 27 units and after one split I had 3 units led by a GG...

I reconsidered my suggestions about n and N and I think everything should be made on integrals. Let nmin=0 be associated with the smallest possible group and nmax (10?) with the greatest one. n0 will be the default n for a newely produced unit and n will be the actual number for a given unit (+1 for each merge, -1 for each split).

N:=3^n (so for a newely built unit N=3^n0)
Nmin=3^nmin=1
Nmax=3^nmax (I don't remember nmax, but if it is 20 it would be difficult to fit it to the 32-bit signed integer)
Ntot=(the sum of all Nmax for all units of a given type, so it should be either 32-bit for nmax about 10 or 64-bit for nmax about 20)

Maintenance costs and effective number of national units should be based on (Ntot/3^n0) rounded up, money for disbanding should be equal to (base money)*(Ntot/3^n0).

Why integers? In order to avoid inaccuracies like: 1.000001 rounded up = 2, 0.999999 rounded down is 0.

S.
Sorry but I have no idea how to follow those mathematical expressions. ^ has no meaning to me. The term integrals also does not register. Is that another way to say integer?

I must apologize but while I'm capable of DOING some fairly intricate math, expressing it is another thing entirely and I'm fairly insufficient in this regard.

Edit: if a GG/Noble remains at the first unit, what to do with the promotions from the GG/Noble line for the other units? Perhaps these promotions would be removed but the player could replace them with some other promotions?
One of the earlier projects Koshling and I hammered out was to make it so that if the unit no longer qualifies to maintain a promotion it has it will lose the promo and get an opportunity to select another one. This would happen as a natural result of losing the Lead By promo.


Also, just to clarify, unique free promos like Lead By should only be maintained by a merged group IF it's possessed by the unit that initiated the merge. That goes for pretty much all 'free' promos - those not assigned by earning xp and leveling.
 
The ^ represents exponent notation. E.g. 4^2 = 16.
I am presuming he ment 'interval'.
 
Sorry but I have no idea how to follow those mathematical expressions. ^ has no meaning to me.

Power. 3^2=3*3, 3^4=3*3*3*3 etc.

The term integrals also does not register. Is that another way to say integer?

Oops, my mistake :blush: Of course I meant integers, integrals are something hmmm... more sophisticated and not applicable in this case ;) I am not a native English speaker...

One of the earlier projects Koshling and I hammered out was to make it so that if the unit no longer qualifies to maintain a promotion it has it will lose the promo and get an opportunity to select another one. This would happen as a natural result of losing the Lead By promo.

Excellent.

Also, just to clarify, unique free promos like Lead By should only be maintained by a merged group IF it's possessed by the unit that initiated the merge. That goes for pretty much all 'free' promos - those not assigned by earning xp and leveling.

O.K. I was wondering what happens in this case. Anyway, I think in general it is better to merge units of the same XP level and with the same promotions...

S.
 
Power. 3^2=3*3, 3^4=3*3*3*3 etc.
Ok, so reviewing everything you've said with these expressions then, it makes sense but the math is constructed a bit differently though the end result is much the same. You do have an efficient way of expressing it and if I thought about it all this simply it might've made this project much easier.

A calculation method similar to your expression would probably be helpful indeed for establishing useful recovery of unit limits. I find the loosening of limits on limited units on SM a 'soft unlimited units' option. I play with unlimited national units myself and really don't see the need for the limits on most units in the first place. It also would mean that you might be able to build a total of one fully fleshed out merged unit if the limits are firmly enforced and that seemed a bit odd to me. The units that do need to be really truly limited like settlers do remain limited since they can't merge or split.

But I can see a way to adjust the way the limit count is made that would make it mathematically equivalent to what you expressed that shouldn't represent much delay or reduction of available memory (the two things I couldn't at first see a way around at first so was why it wasn't implemented right away there.)
 
You do have an efficient way of expressing it and if I thought about it all this simply it might've made this project much easier.
[...]
A calculation method similar to your expression would probably be helpful indeed for establishing useful recovery of unit limits.

Well... manipulations on formulae etc. are a part of my profession (I am a physicist), so if I may be of any assistance...

I find the loosening of limits on limited units on SM a 'soft unlimited units' option. I play with unlimited national units myself and really don't see the need for the limits on most units in the first place.

"Soft unlimited units" sounds interesting. I have played with unlimited only once and I did not like it very much. Well, I could spam Privateers, Hashashins, Inskillings etc. like crazy (I am a big fan of HN units during peace), but at the same time rival civs built a lot of Early Imperial Guards and Warlords (which tended to be killed by my Heavy Swordsmen and Crusaders, so I had a lot of Military Commanders to settle). Some units are simply imbalanced.

S.
 
Well... manipulations on formulae etc. are a part of my profession (I am a physicist), so if I may be of any assistance...
That does go a long ways towards explaining your skill in expression there. I may indeed need some deep assistance with some advancements in odds calculations I've been seeking to make here. In particular, modifying the odds calculation formulas to account for increasing and decreasing combat % modifiers per round and an effect that makes a unit stronger for the first rounds then returns it to normal strength thereafter.



"Soft unlimited units" sounds interesting. I have played with unlimited only once and I did not like it very much. Well, I could spam Privateers, Hashashins, Inskillings etc. like crazy (I am a big fan of HN units during peace), but at the same time rival civs built a lot of Early Imperial Guards and Warlords (which tended to be killed by my Heavy Swordsmen and Crusaders, so I had a lot of Military Commanders to settle). Some units are simply imbalanced.

S.
You had Warlords being spammed so you must've played before the bUnlimitedException tag was fixed. Warlords have successfully been limited. That was the main problem spot that emerged since they are indeed simply stronger. Some unit reviews and AI restructures are coming in the near future that should help with the rest of the issues that you probably experienced. I didn't see the Imperial guard issue but probably didn't play far enough in to witness it.

IMO, HN units should be balanced by excessive upkeep costs to maintain them (which is a big reason gold balance for the game as a whole needs to be corrected!)
 
I may indeed need some deep assistance with some advancements in odds calculations I've been seeking to make here.

I would need to know exactly how it is handled in the game. As far as I understand, attack (+modifiers) A s compared to defence (+modifiers) D. Each unit has some HP (default 100?). Round 1: a random number (R) from 0 to 1 is calculated, if R<A(A+D) then attacker wins (-1HP for defender), otherwise the defender wins (-1HP for attacker) etc, the fight ends when one unit loses the last HP or retreats?

In particular, modifying the odds calculation formulas to account for increasing and decreasing combat % modifiers per round and an effect that makes a unit stronger for the first rounds then returns it to normal strength thereafter.

Hmmm... sounds difficult, but I may try to do this. It would be quite easy to calculate the result for one, particular battle, but I would need to be very careful when calculating combat odds. I assume that brute force (repeating the calculations e.g. 10000 times with various random seeds, counting wins, losses and retreats and then displaying the results) is not an option?

S.
 
I would need to know exactly how it is handled in the game. As far as I understand, attack (+modifiers) A s compared to defence (+modifiers) D. Each unit has some HP (default 100?). Round 1: a random number (R) from 0 to 1 is calculated, if R<A(A+D) then attacker wins (-1HP for defender), otherwise the defender wins (-1HP for attacker) etc, the fight ends when one unit loses the last HP or retreats?
It's a bit more complex than that but you aren't toooo far off the mark. It'll take me some real effort to compile the actual current formula so be patient with me for that and I'll produce what I can as soon as possible.

It deals with ratios of unit strength totals. Damage ranges each round from MISS to 6-40 or so (I think - I'd have to look to say for sure). Now there are manipulations from the original formula to account for a number of new effects as well... get's quite intricate.


Hmmm... sounds difficult, but I may try to do this. It would be quite easy to calculate the result for one, particular battle, but I would need to be very careful when calculating combat odds. I assume that brute force (repeating the calculations e.g. 10000 times with various random seeds, counting wins, losses and retreats and then displaying the results) is not an option?

S.
Correct that it's not an option. It would need to be statistically calculated which the current odds model already does - I just need to adapt that model to the new effects and I realize it's exponentially more complex than calculating the odds of winning coin tosses multiple times in a row. If you're good with statistical math it should be an interesting challenge to sort out the proper formula.
 
It deals with ratios of unit strength totals. Damage ranges each round from MISS to 6-40 or so (I think - I'd have to look to say for sure). Now there are manipulations from the original formula to account for a number of new effects as well... get's quite intricate.

O.K., I think I've caught it. Damage ranges make it more complicated than I thought, but this is still manageable.

We have two units: attacker (base strength A) and defender (base strength D). Maximum HP for A is AHPmax, for D is DHPMax; initial HP at the start of combat (because they don't need to be at full strength) will be AHPinit and DHPinit; actual HP at the beginning of the round will be AHP and DHP.

Total attack of the attacker will be Atot=A*(1+bonuses-penalties)*(AHP/AHPmax) and total defence of the defender will be Dtot=D(1+bonuses-penalties)*(DHP/DHPmax). A chance to win or lose each round perhaps will be governed by the ratio of Atot/Dtot:

Atot/(Atot+Dtot) to win
Dtot(Atot+Dtot) to lose

Bonuses and penalties may depend on the round, so I will define a set of functions

pn(i,AHP,DHP)

for n=1 to ntot which represent outcome n for the round i. The outcomes may be:

p1(i, AHP,BHP) - A wins but misses
p2(i, AHP,BHP) - A wins and takes minimum possible number of HP
p3(i, AHP,BHP) - A wins and takes minimum possible number of HP + 1
...
- A wins and takes maximum possible number of HP
- A wins but B retreats
- B wins but misses
- B wins and takes minimum possible number of HP
- B wins and takes minimum possible number of HP + 1
...
pntot-1(i, AHP,BHP) - B wins and takes maximum possible number of HP
pntot(i, AHP,BHP) - B wins but A retreats

p1(i, AHP,BHP)+p2(i, AHP,BHP)+p3(i, AHP,BHP)+... should add up to 1.0 for each i, AHP and BHP.

Now we define two arrays representing the state of the battle, S0 and S1. They will be arrays of real numbers indexed (-1...AHPinit) and (-1...BHPinit): these indexes represent actual HP of the attacker and defender. 0 means that the battle is lost, -1 means that the unit retreated.

Before the fight: all elements of S1=0, almost all elements of S0=0, S0(AHPinit,BHPinit)=1.

i:=1 {the number of the round}

@NextRound

FOR k:=1 to AHPinit do
FOR l:=1 to BHPinit do
FOR n:=1 to ntot do

BEGIN

{if A loses some HP -> I will call it HPlost}
S1(k-HPlost,l) := S1(k-HPlost,l) + pn(i,k,l)*S0(k,l)

{if B loses some HP}
S1(k,l-HPlost) := S1(k,l-HPlost) + pn(i,k,l)*S0(k,l)

{if A or B wins but misses}
S1(k,l) := S1(k,l) + pn(i,k,l)*S0(k,l)

{if A retreats}
S1(-1,l) := S1(-1,l) + pn(i,k,l)*S0(k,l)

{if A loses and k<=HPlost -> A loses the fight}
S1(0,l) := S1(0,l) + pn(i,k,l)*S0(k,l)

{if B retreats}
S1(k,-1) := S1(k,-1) + pn(i,k,l)*S0(k,l)

{if B loses and k<=HPlost}
S1(k,0) := S1(k,0) + pn(i,k,l)*S0(k,l)

END

FOR k:=1 to AHPinit do S1(k,0):=S1(k,0)+S0(k,0) {add all cases when D lost earlier}
FOR k:=1 to AHPinit do S1(k,-1):=S1(k,-1)+S0(k,-1) {add all cases when D retreated earlier}

FOR l:=1 to DHPinit do S1(0,l):=S1(0,l)+S0(0,l) {add all cases when A lost earlier}
FOR l:=1 to DHPinit do S1(-1,l):=S1(-1,l)+S0(-1,l) {add all cases when A retreated earlier}

i:=i+1

S0:=S1 {copy whole array}
S1:=0 {clear the array}

GOTO @NextRound

The loop ends when for all l=1...DHPinit and k=1...AHPinit S0(k,l)=0 so the only nonzero elements are S0(k,-1), S0(k,0), S0(-1,l) and S0(0,l).

Probability that A wins: the sum of all S0(k,0)
Probability that A wins but B retreats: the sum of all S0(k,-1)
Probability that B wins: the sum of all S0(0,l)
Probability that B wins but A retreats: the sum of all S0(-1,l)


However, this may be an infinite loop, because there may be some cases when A or B misses and misses (no loss of HP). In order to avoid that, it is necessary to include some condition for the cases when A or B misses, e.g. if pn(i,k,l)*S0(k,l) gets below some limit (e.g. 1/(AHPmax*BHPMax*1000000), it gets assigned to the situation when A or B wins but with minimal HP loss for the opponent.

Uff! I think that if I had made no stupid mistakes and if I did not overlook something, it should work.

S.
 
@S:
Do me a favor and start a new thread on the subject with that post. It looks like you can read c++ pretty well since you express in the same logic. I'll post to you what we HAVE now in the code there later after work and you can see what we're currently working with. From what I could see of what you sorted out there (VERY impressive btw!) it looks like you might be just about right on target. There just may be a few tweaks needed still and I certainly will need some help converting it into the code meaningfully so will need to go through things very patiently with you.
 
@S:
Do me a favor and start a new thread on the subject with that post.

O.K. I will put it in the main forum. And I will correct one small mistake I have found :)

It looks like you can read c++ pretty well since you express in the same logic.[...]

Well... I know C and C++ only passively, my main programming language is Pascal - I hope this will be enough. And I hope there are no elements of object programming there, because I have never managed to force myself to get familiar with objects :)

S.
 
O.K. I will put it in the main forum. And I will correct one small mistake I have found :)



Well... I know C and C++ only passively, my main programming language is Pascal - I hope this will be enough. And I hope there are no elements of object programming there, because I have never managed to force myself to get familiar with objects :)

S.

We'll work it out together ;)
 
O.K., so another issue. If I set an unit (a Hunter or military one) to autohunt, instead of attacking animals it goes between them and waits until it is attacked (the same for sea units like Caravels). This may be O.K. if I send them to hunt animals, but if I send a HN unit like Warlord to disturb my rivals, this is very irritating. There are only two cases when the units behave as expected:

- if they are also Stealth ones, like Hashashins or Ambushers
- if they are Pirates (Barbary Corsairs, Privateers) and I set them on automatic piracy.

So my suggestion is: either change behaviour of HN units at autohunt or give them Automatic Piracy button.

S.
 
O.K., so another issue. If I set an unit (a Hunter or military one) to autohunt, instead of attacking animals it goes between them and waits until it is attacked (the same for sea units like Caravels). This may be O.K. if I send them to hunt animals, but if I send a HN unit like Warlord to disturb my rivals, this is very irritating. There are only two cases when the units behave as expected:

- if they are also Stealth ones, like Hashashins or Ambushers
- if they are Pirates (Barbary Corsairs, Privateers) and I set them on automatic piracy.

So my suggestion is: either change behaviour of HN units at autohunt or give them Automatic Piracy button.

S.
What are your autohunt settings at in the bug menu regarding the minimum attack odds?
 
Top Bottom