 |
| |
|
|
Immortal Wombat
|
 |
in perpetuity
Dec 2000
time: 05:25
|
|
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:
code:
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...
 Attachment: battleaftermath.jpg
This has been downloaded 122 time(s).
|
|
| |
|
|
|
Peter Triggs
|
|
Gone Fishin, Canada
Jan 2000
time: 05:25
|
|
Weird stuff. I tried:
code:
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:
code:
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.
|
|
| |
|
|
|
MrBaggins
|
|
Out of curiousity, do we know for a fact that *this*
quote:
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?
|
|
| |
|
|
|
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?
|
|
| |
|
|
|
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
|
|
| |
|
| |
|
|
|
Martin Gühmann
|
 |
Berlin, Germany
Mar 2001
time: 06:25
|
|
quote:
Originally posted by MrBaggins
Out of curiousity, do we know for a fact that *this*
quote:
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? |
In that case I would recomment to read the small sentence under the code:
quote:
The author apologizes for this and promises that if there is another patch it will be fixed. But the above workaround should always work. |
Most important here is the little word: if. They promissed to fix it if there will be another patch but as we all know there was no more patch therefore this bug isn't fixed.
-Martin
|
|
| |
|
|
|
MrBaggins
|
|
weren't there two patches?
1.1
and
1.11
Anyway... I guess its wise to be wary of the warning, and copy these non-ints locally, when you use them.
|
|
| |
All times are GMT. The time now is 05:25.
Apolyton Time is 00:25. |
top of page
|
| archivepost |
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
02-02-2003 05:15
I can't give you the exact string, I removed it when I used the tester message for something else.
|
