Knee-Deep in SLIC

[Immortal Wombat]

I have a question.

Whilst testing out some of the deeper workings of the BattleAftermath event (damn I'm cool), I messaged myself all the values that the event called.

The following results were from a battle where the attacking army lost.

So for BattleAftermath, we have from the docu:

BattleAftermath(army_t, location_t, unit_t, unit_t, int_t, int_t, int_t)

So not having a string for army, I passed in the army[0].size in, and unit[0].type and unit[1].type, the location as {.x},{.y} and the player numbers.
The attached picture is the result.

army[0].size = 97970400 ?? erm... hows that then?
location coords are correct.
units: 1st one is a mystery even to the game apparently, but it brings up a message I've never seen before... (would this be the type of the unit in the attacking army that got wiped out?)
2nd one comes out as 87 (which was the .type of one of the defenders)
player[0] comes out fine - me
player[1] doesn't work at all
and the int at the end is 1. Maybe this means "attackers lost" and 0 is "attackers won"

But the army size thing is a mystery...

[Pedrunn]

Re: Knee-Deep in SLIC

Originally posted by Immortal Wombat
But the army size thing is a mystery...

I have seen this bug with other event. I have tested the ArmyClicked(army_t).
As i figured out you cant know the size of another civ unit in string form.

In my testing with the army[0].size revealed in a message. If you own the unit it gives the correct number but if the owner is another cive big crazy numbers show up like the one you got.

[Martin Gühmann]

Ben could you give us the exact string that you used in the message box I think you forgot something concerning player[1].

-Martin

[Peter Triggs]

Weird stuff. I tried:

int_t armysize;
int_t armyowner;

HandleEvent(BattleAftermath) 'BattleAftermathTestpre' pre {

    setstring(0,ID_pre);
    armysize=army[0].size;
    armyowner=army[0].owner;
    message(1,'BattleAftermathTestM');
}

HandleEvent(BattleAftermath) 'BattleAftermathTestpost' post {

    setstring(0,ID_post);
    armysize=army[0].size;
    armyowner=army[0].owner;
    message(1,'BattleAftermathTestM');
}

messagebox 'BattleAftermathTestM' {
show();
Text (ID_BattleAftermathTestTxt );
}

with strings:

BattleAftermathTestTxt "{action[0].text}: armysize=
{armysize}, armyowner={armyowner}, 0={player[0].civ_name_plural}, 
1={player[1].civ_name_plural},
\n unit0={unit[0].type}, unit1={unit[1].type}"

pre "pre"
post "post"

The resulting data is the same whether reported pre or post and just depends on who won the battle.

army[0] is the attacking army: if it loses the battle, it ceases to exist. It looks like unit[0] is some attacking unit and unit[1] is some defending unit. Depending on who won the battle, one of these will be the invalid unit and we get that strange error message.

[Immortal Wombat]

Originally posted by Martin Gühmann
Ben could you give us the exact string that you used in the message box I think you forgot something concerning player[1].

Oh yeah, looks like I screwed up the opening brace { I can't give you the exact string, I removed it when I used the tester message for something else.

What I wondered was whether since army[0] does not exist (a pain in the arse btw), army[0].size returns the address of the army size?

[Dale]

That large number could be the memory address location of the army. A lot of programmers use this shortcut so they don't need to pass the entire class data into new functions, as it causes multiple copies to be in memory.

[The Big Mc]

why where you testing this out is there a mod on its way.

[Martin Gühmann]

Originally posted by The Big Mc
why where you testing this out is there a mod on its way.

I don't know if Ben used it for a new mod possible it is some LOTR stuff or something else. The main information of this thread is how you can test event handlers check the values of the build in variables that are usefull for debugging and that you should extract information from invalid objects. Yeah this will give you sometimes DebugSlic=Yes errors.

So testing this stuff has the purpose of getting information and to satify our curiousity. To get ideas for new stuff.

-Martin

[Immortal Wombat]

Battle tracking in the LOTR scenario.

[The Big Mc]

I would like to see it when it is done

[MrBaggins]

Out of curiousity, do we know for a fact that *this*

Quote by MrOgre
Important note! As this documenation is being prepared, the first patch for CTP2 is about to be released. Unfortunately a bug with functions was discovered too late to fix. Specifically, in some cases, using members of unit, army, city, and location variables that are function parameters may not always work as expected. There is, however, a workaround. Copy the function parameter to a local variable and use that variable instead.

was fixed, in every case?

[The Big Mc]

Could be a lazy activsion thing. But you have a cat in hells chance of getting anything out of the puddle of eternal wisdom(activsion) I remember the war which was designated as a partial victory as the activsion staff got very offensive and would not talk to me.

[MrBaggins]

ahh... I'm not saying that there is any chance of knowing for sure... or getting it fixed if it is... but just maybe its a good idea to copy non int arguments to a local var, just in case... so that we don't get unforseen bugs?

[The Big Mc]

We could try that.

I would love to know what enemies I am attacking for my hero unit.

[MrBaggins]

I still think you'll have the problem of a non-existent (due to the fact that the designers delete the army/unit after it ceases to exist) defeated army...

The best way of dealing with this is knowing what is being attacked before the battle happens....

using, for instance...


Battle(army_t, location_t)
An army attacks a location