As a French person I feel like it's my duty to explain strikes to you. - AdrienIer

Create an account  

 
Caster of Magic II Bug Reports!

(February 8th, 2023, 05:33)Suppanut Wrote:
(February 8th, 2023, 00:47)Seravy Wrote:
(February 7th, 2023, 23:28)Suppanut Wrote: Please check if new feature of custom attributes are actually working or not. I have tried using it and found that although no error warning on process from units.ini and master.cas for invalid attribute, script part in unitcalc.cas, unitcalcpre.cas and disabil.cas does not trigger on condition using them.

I see no obvious problem in the source code.
Please post an example unit from units.ini and the script code for the ability and I'll try to reproduce the problem.

Here is example in my test build. I will picking part that could be easy to reproduce for you.

Units.ini
Code:
[197]
Name=Nagas
Attack=4
Ammo=0
Hit=40
Defense=4
Resistance=7
Moves=6
Cost=65
LairCost=98
Upkeep=1
Race=17
Building1=6
Building2=0
HP=4
Scouting=1
Transport=0
Figures=3
Roadbuilding=0
AIProduction=0
AIgarrsion=6
Sound=146
Waterwalking=Yes
Fantastic=Yes
FirstStrike=Yes
Poison=3
Custom1=Yes
Foodupkeep=0

Master.cas
Code:
AFExorcise=66;

: SCustom=100 , Use 100-119 to read/write custom data to the unit, not used for anything else.:
SMariner=100 : Custom1 :

DisAbil.cas
Code:
IF (GetEnchantmentFlag(U,EncMariner,0)>0) %OR (GETSTAT(U,SMariner,1)=1) THEN {
AddAbilityLine 0,194,"Mariner","Mariner"; }

Unitcalcpre.cas
Code:
IF (ISCOMBAT()>0) THEN {

: if Kraken/Nagas/Marines arrive at combat sea tile :
X=(GetStat(U,SCoX,0));
Y=(GetStat(U,SCoY,0));

: Mariner enchantment is now using by Marines and Sea Hags and given by script :
IF ( INCOMBAT(U) ) %AND ((GETTERRAIN(X,Y,0))=2) %AND ( (GetEnchantmentFlag(U,EncMariner,0)>0) %OR (GETSTAT(U,SMariner,1)=1) ) THEN {
  SETSTAT(U,ASailing,0,1);
  SETSTAT(U,AFireImmunity,0,1);
  SETSTAT(U,SOLMaxMoves,0,(GetStat(U,SCombatMaxMoves,0)+4));
  SETSTAT(U,SOLMovesLeft,0,(GetStat(U,SCombatMovesLeft,0)+4));
  SETSTAT(U,SCombatMaxMoves,0,(GetStat(U,SCombatMaxMoves,0)+4));
  SETSTAT(U,SCombatMovesLeft,0,(GetStat(U,SCombatMovesLeft,0)+4));
}
}

Code in unitcalcpre.cas and disabil.cas was written to make sure that it would not break old savegame. You could remove part related to enchantment flag "EncMariner" and result would still be the same.

And here is test build in question that support version 1.04.07 of CoM for windows in case you want to see full code.
https://www.mediafire.com/file/kutjer0cy...0j.7z/file

I found the problem.
It should be "Custom1=1" instead of "Yes". Custom abilities are integer values.
Reply

Thank you. So it is custom1=1 and custom2=1 and so on and so on?
Reply

(February 8th, 2023, 23:54)Suppanut Wrote: Thank you. So it is custom1=1 and custom2=1 and so on and so on?

Yes, exactly. Or any other number you prefer and check for in the script.
For example you could have an ability that works like "Regeneration X" and put the X, the amount of hp, as the number.
Reply

(February 7th, 2023, 06:48)Anskiy Wrote: A save with the Warrior Mage's stack could help pinpoint the problem. It does sound like the auto combat is exaggerating some of his abilities.

Here is the save.
The stack is 5 tiles north and 3 tiles west from my capital. On the next turn they will attack the node with 6 hydras below them.

You can also see my node 4 tiles west from my capital - he cleared that and just moved on earlier, that's how I melded it smile And that's a fat node too... It had efreet and few doom bats acc to earth lore.

In order to pinpoint the turns where he cleared the other hard nodes I will have to really dig for a while and I don't really have the time... If you decide that that would better the game I will though, just let me know.


Attached Files
.zip   5.zip (Size: 107.37 KB / Downloads: 2)
Reply

What could cause game to crash upon attempt to dispel guardian wind? I have got report twice from different persons on the same issue from Warlord mod (one is from savegame above). It seem to not related to DPower.cas as edit back to vanilla does not prevent the crash.

Edited: condition of crush upon dispel guardian wind seem to be very specific as it seem to only occur on lair creature cast guardian wind and then player dispel it.

Edited2: It occur to all attempt to dispel unit enchantment cast by any creatures in lair combat. And it might be bug from base CoM.
Reply

It seems like the Dispel bug specifically applies to buffs casted by lair enemies. I had the game crash while trying to dispel Immolation cast on some Chimeras in a Chaos node too. Dispelling buffs cast by wizards seems to work fine though. Save attached.


Attached Files
.zip   Dispel bug.zip (Size: 32.61 KB / Downloads: 0)
Reply

Dispel bug :

This seems to be the usual issue of referencing the "neutral player"'s data which doesn't exist - in this case while calculating dispel resistance.

The default script clearly starts with "IF W<>NeutralPlayerID THEN" to prevent that from happening so unless that was changed the problem is elsewhere.

...found it. It's the logging line. Trying to log the name of the player who owns the enchantments is crashing for the neutral "player". This will be fixed in the next update.
Reply

About the automatic combat save file.

The sprites have a "unit power" rating of 480 each.
The hero has 23632.

These numbers seem reasonable - the hero has 4 times the hp, attack strength and like, 6 times the defense.
So it being deemed about 50 times stronger is fair - that's actually the truth.

Which means the hero's stats are weighted against the sprites in a ratio of 50 to 8 to determine what's the "average" in the army.
In plain words, the game sees this army as if it was 9 units that consists of 80% Warrior Mage heroes and 20% Sprites, because the weighting formula pretty much says "the hero is putting in most of the work".

The overall result is the stack fights as well as if it had 7 of those heroes and 2 sprites in it instead.

Now, some weighting must be done, otherwise the average will be very close to the sprites instead, and the game would pretty much see an army of 9 slightly better sprites fighting, as if the hero wasn't even there which is even more unrealistic.
The stronger units clearly put in more work than what simply adding up the numbers would suggest, otherwise 4 sprites would basically be enough to kill that hero which is nonsense.

But maybe this much weighting is excessive?

Would using the square root of the unit rating instead of the actual value help, I wonder?
The primary problem might be that unit rating is already non-linear as it's attack*defense*hp+/- some modifiers in the formula.

Using the SQRT in this combat would put the sprites at 21.9 and the hero at 153,72 weight, which seems more realistic.
That way the hero would be 153 and the 8 sprites 172 total weight so the hero would "only" represent about half the army instead of 80%.

Of course even that won't completely "fix" the problem for the more extreme cases like a demigod hero with 8 spearmen but should help at least for the more common situations.
Reply

(February 11th, 2023, 21:34)Seravy Wrote: Dispel bug :

This seems to be the usual issue of referencing the "neutral player"'s data which doesn't exist - in this case while calculating dispel resistance.

The default script clearly starts with "IF W<>NeutralPlayerID THEN" to prevent that from happening so unless that was changed the problem is elsewhere.

...found it. It's the logging line. Trying to log the name of the player who owns the enchantments is crashing for the neutral "player". This will be fixed in the next update.

Thank you.
Reply

(February 12th, 2023, 00:09)Seravy Wrote: But maybe this much weighting is excessive?

Would using the square root of the unit rating instead of the actual value help, I wonder?
The primary problem might be that unit rating is already non-linear as it's attack*defense*hp+/- some modifiers in the formula.

Using the SQRT in this combat would put the sprites at 21.9 and the hero at 153,72 weight, which seems more realistic.
That way the hero would be 153 and the 8 sprites 172 total weight so the hero would "only" represent about half the army instead of 80%.

Of course even that won't completely "fix" the problem for the more extreme cases like a demigod hero with 8 spearmen but should help at least for the more common situations.

Autocombat has definitely been broken for quite a while. I would welcome anything that makes the results more realistic. Few things are more annoying than seeing the AI loot lairs with armies that clearly shouldn't have been able to win.
Reply



Forum Jump: