Wake of Gods Forum | Форум Во Имя Богов

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174

Crash in on HE:F?/?/?/?/1 command.
Crash is in combo artifact handling, which hero wears. Like some plugin extends wog table incorrectly.

This is the table:

Code:

Byte ArtSlots[]={

// номер,+атака,+защита,+сила,+знания, занятые слоты ...

  0x81,21,21,21,21, 0,2,4,5,7,

  0x82,0,0,0,0,     2,7,

  0x83,0,0,0,0,     6,6,

  0x84,3,3,2,2,     0,3,4,

  0x85,0,0,0,0,     8,8,8,8,

  0x86,16,16,16,16, 0,1,2,3,4,6,6,7,

  0x87,9,9,8,8,     0,4,5,

  0x88,0,0,0,0,     2,

  0x89,0,0,0,0,     8,8,

  0x8A,0,0,0,0,     8,8,

  0x8B,0,0,0,0,     1,2,

  0x8C,0,0,0,0,     1,6,6,

  0x99 // последний

};

Combo Artifact ID, +attack, +defense, +spell power, +knowledge occupied slots
Table position is huge in code. It means either 0x99 value was overwritten by plugin or the whole table is corrupted.

I tried a few times, but no crash. Cannot reproduce.

Berserker, The savegame was passed from a player, and I was able to reproduce, strange. :/

Could it be something from HD mod? I heard about HD handles combo artifacts and stuff, that's the main reason Third Upgrade Mod has its own hd_wog.dll.

______

Is it possible for you to raise the limit of HE:V? Currently, the limit is set to 0 - 31, objects with ID larger than 31 will result in ERM error. I believe this should be eliminated.
ERA handles objects like Garden of Revelation with more than 32 in a map quite well, Unleashed Editor by RoseKavalier also allows more than 32 of the objects to be added, the only remaining is the HE:V command.

I didn't checked it without HD mod. We need the third tester. As far as I can see, crash should not occur unless WoG memory is corrupted. I loaded your savegame and didn't reproduce the crash. More testers, more experiments will be probably necessary.

HE:V limit is not changeable, because it's 4-bytes integer value with 32 bits (1 byte = 8 bits). Extra objects overwrite other objects bits and even memory after that bits.
In Hero structure exactly 10 integers of 32 bits each are allocated for storing visited objects flags (10 object types). This is hardcoded restriction, unless someone patches all places, where these fields are used.

So you suggest that if a map is with more than 32 Garden of Revelation, data could be corrupted?

Hmmm...I think I need RoseKavalier to tell why he lifted this limit in his editor 102

No corruption occurs from this, game code performs (garden_id % 32).

Archer30, RoseCavalier means, that corruption occurs actually. When you visit one garden, it overwrites "visited" flag of another one. 33-th garden shares "visited" flag with the first one. 34-th shares the "visited" flag with the second garden and so on. It may be suprising for knowledge stones, for instance.

It's not really corruption in the sense the word is usually used - it just creates 'duplicate' objects. Save game will be safe.

Data corruption would be Artifact Merchant overflowing to read hero's visited towns for example, that can crash the game.

RoseKavalier, so basically if a map has 70 Garden of Revelation, when you visit the No.0, No. 32, No. 64 would also be marked as visited, right?

Then I say it could be handy if HE:V could automatically convert ID>31 to the 0-31 range 102

Archer30, ok, added to TODO. Though it's a crutch, buggy code will work now. Any positive value will succeed for HE:V.

Berserker, Thanks!

A report about possible ERM engine issue. I know it's bad practice, but check this:

Image: 7WVksMe.png

The first attempt does not return 50 but 0. Any idea?

ERM receiver subcommands are executed one by one. It's not expression, stored in some temporary memory.

!!VRy1:S100 -y1 is the same as

Try

Thanks! That explains.

I don't see any issues. That's is fully arithmetic correct.

daemon_n, a = 100 - a in most programming languages is evaluated as t = a. a = 100 - t.

Berserker, я не понял твоё предложение, но повторю и своё по-русски.

Считаю, что ерм отработал правильно в примере от Archer30, потому не могу согласиться с тем, что там какая-то ошибка.