FACALL bug

[Hobbes]

Hi chaps, I'm sure there is a post about this somewhere but I thought I would post it again as it has just caused me two hours of grief.

If you have an event with a line something like :-

EvalRgnStruc $Lorain|FACALL|STRUCDEF $Village

It can cause the event message to be shown to the wrong side
(and maybe some other problems).

Although the event I was using had GBR on the first line I think the FACALL can mess this up and the event is instead shown to the other side.

Worth bearing in mind (or fixing )

Cheers, Chris

[lodilefty]

FACALL clears "the Faction register" by definition.

That will:
a) Cause issues if the next action needs a Faction to work [as in build, replacements, etc.]
b) Cause messages to default to whatever the engine thinks is "side 0".

Rather than depending on the Splitter and Engine to sort it out, I put a SelectFaction command in after using FACALL:
[ATTACH]10172[/ATTACH]

Let us know if this sorts it out

[Hobbes]

Hi Lodi, I sorted it out by moving the line above another. But if the scenario designer doesn't know about this problem it will cause a lot of hassle.
I would think FACALL should just be a command that allows you not to care about who is in control of a village for example. It shouldn't mess up an event in this way.

Cheers, Chris

[lodilefty]

Hi Lodi, I sorted it out by moving the line above another. But if the scenario designer doesn't know about this problem it will cause a lot of hassle.
I would think FACALL should just be a command that allows you not to care about who is in control of a village for example. It shouldn't mess up an event in this way.

Cheers, Chris

I had long discussion when this was explained to me:

If you choose FACALL, how can you also choose just one FAC at same time?

Like any code, there are rules....

[Hobbes]

Hi Lodi, to my mind you have a command like :-

EvalRgnStruc $Le Detroit|IND|STRUCDEF $Village

so if a village exists in the region and is controlled by the IND faction then do ...


If you have :-

EvalRgnStruc $Le Detroit|FACALL|STRUCDEF $Village

then if a village exists in the region (doesn't matter who is in control) then do ...

What you don't expect is for this command to change the overall event faction. In fact even if you put a command after this such as a GenMsg with GBR in the first column the message will still appear to the IND faction not the GBR faction. This can't be right.

Cheers, Chris

P.S. am I using this command correctly? Is there something like a FACANY option which doesn't change the faction?

[lodilefty]

AFAIK, The engine carries a "current faction" variable

FACALL sets that to a "wild card" [like * in file name]

It can't retain any other 'current faction' because we just told it that the current faction is ANY faction.

You are asking for what I suspect woulld be a significant code overhaul for a relatively minor issue that already has a solution.

It is what it is... live with it

[Hobbes]

I just thought it worth highlighting in case anyone runs into this sort of problem.

[Pocus]

This would not be that significant to change, but I think it is ok this way, because the good thing is that it allows to have a conditional event, e.g I do an evaluation with FACALL, get the structure, and who is in charge of it get the rest of the event.

You can fix that easily (yes you have to know this change the faction, potentially) by just putting again the faction you play with in the first column:

GBR

is equivalent for the splitter to

GBR SelectFaction = GBR

for example an application of it is: evaluate the city of a region (so switch the faction pointer to its owner) then give VP to the said faction.

Sure, you can do that with EvalRgnOwner, but let's look at VGN... you can have a mine in a region owned by another country (say some British mine in a Chinese region)... I want to give a pat on the shoulder (give VP) to who ever owns the mine.

[Hobbes]

Thanks for clarifying chaps!

Chris