(Review Completed) [SP] Abandoned Armies

[macguba]

Lol.   ;D   *Scribbles picture of large thumbprint on THobson's forehead.*

Triggers are not evil, they are good.   You can't make a decent mission without triggers.   (Well ok I supposes its theoretically possible to replace all of them with scripts.)    However, like all good things, if you eat too many they make you sick.   Sick of the lag, in this case.    

Everything in the game causes lag, by definition, and that includes triggers.    However, even when you are close to the limit (as this misson is) adding one simple trigger is not that big a deal.   The trouble here is that there are a dozen or so towns and each one needs two triggers.    Those two dozen checks the computer now has to do every frame constitute a non-trivial workload given the amount the comp has to do already..

I wrote a tute on lag once .... here.

I don't know for sure, but I suspect you are right to delete triggers.   You can still use list triggerName commands after they have fired, which suggests that fired/not fired is treated sort of like another element in the Condition line.   In other words I suspect that fired triggers still poll, and consequently deleting them will help.   And information on this appreciated, I can add it to the tute.

[Mikero]

I had in mind that the dead policeman in Vigny was 'good and decent' he was trying to do what was right and that is why he got shot.

I understood that implicitly. It was one of those 'richness' things, which in this case needed no triggers and blah

[Mikero]

I suspect that fired triggers still poll

While I don't know diddly squat about scripting in ofp, I do know programming techniques and languages reasonably well.

The triggers would be intitally 'registered' by the engine.

The engine builds a dynamic queue in a frame event handler.

If an author can interrogate *a* specific trigger to find out if it's fired, then that status will be part of the trigger, rarely, part of the queue, and the answer therefore would be that the engine still polls the trigger to find out it doesn't have to do anything! (just like the author can)

If you can't interrogate 'this' (type of) status, it's because the trigger has been removed from the queue (but not deleted)

The clue, programming wise, to the answer is whether you can address a trigger by a 'this' style inference (queue) or only by specific name (a deregistered trigger). Btw, I don't know what 'this' means in ofp, just educated guessing.

OFF TOPIC

@Mac, I know your reading this thread and are a busy man, so may have missed my returns on the editorupgradeONE.pbo, would you mind looking at it please in the relevant thread.

[THobson]

Each trigger has an array associated with it.  That array contains all the units that cause the trigger to fire.  Interogating the contents of this array shows that it changes dynamically even after the trigger has fired.  I see two options:
- the trigger is continually checked by the engine irrespective of whether or not it has fired
- the act of interogating the trigger's array causes it to be up-dated.

The second seem like a long shot, the first one seem much more likely.

In which case fire once triggers continue to consume CPU time even after they have fired.  This is my assumption and so I now delete fire once triggers after they have been used - but that does mean that they have to have a name - which for most missions without ECP will cause no problem at all.

Attached is the flag change.  Just stand and watch.  You will see a flagpole with Andropov's new flag flying.  Then one of Stamenov's loons will turn up carrying his new flag. and will change the flag on the pole.  Keep watching and some of Anropvo's loons will re-take the area.  It may be that it is the guy carrying the flag that goes to the flagpole to do the change - but it need not be.

It is still work in progress.  It has two issues currently:
- the flag changer does not go to CARELESS when changing the flag
- if an attack is successfully repelled then one of the defenders will go to the pole, bring down his own flag, and then put it back up again.

As I said this is WIP

[Mikero]

No intro

no overview

no brefing

<slap>

umm to test 'proper' I'd need one side nato, one side russkie. Seemed overwhelmingly blue side.

apart from several tests:

shot red guy before he made it. Pole stayed blue

shot next blue before he made it
blue flag went down, blue flag went up

later on, inexplicably, pole went red. all blue around pole and no-one near it.

I think you will have to prevent any loon with a flag from raising the flag, it jars that he's still carrying 'it' afterwards. Doesn't matter that he's got a spare in his pocket, just doesn't look 'right'

[THobson]

Did I say there were only two issues with it?  I had better count again.  Thanks.  I was just so pleased to get it working I didn't get involved with the shooting.  Good test.  Thanks.

[macguba]

mikero, which thread?   Do you mean the Comment on the submission in the Ed Depot?    No I haven't seen your reply anyway.

Much better flags.

In the script in #setflag there is a missing _ in front of flagpole.   At least I presume it's missing.

I tried a couple of tests and its not robust but you know that.

An animation to make it look like he is changing the flag would be good.   In Un-Impossible I used waypoints so you'll need to play with the delays, but the critical part is:-

yank1 switchMove "FXShow3"
flag1 setFlagTexture ""
yank1 switchMove "FXShow3"

Try safe rather than careless.

How did you get the flag to descend the flagpole?   Looks great.

I don't think there is a problem with the group leader doing the change.  However, it would look better if somebody else did it.

[THobson]

Thanks - now working on robustness.

If you give a flag an owner using setFlagOwner the the flag comes down the pole.

I actually tried safe before I tried careless

Actually I like the group leader changing the flag - but the script could select anyone

[Mikero]

@mac

yes, the editor stuff, sorry for the totally off topic.

[macguba]

Actually I like the group leader changing the flag

Well keep it then.  

mikero - checking now ... I'm assuming you are freda.

[Goettschwan]

Morning.  

Thobson, i did not mean to criticise so much if it came through like that.
I agree with macguba on the script, or, rather, on what i think he wanted to say.
If you cannot or are not willing to redo some takes please consider the spacing of the dialogue.
You have done a magnificent work on those audios, and i don't even add "for an amateur".  Short of pro experience or maybe musicians in the team thats as good as it can get.
I'm not french , so i don't know if "naff" means anything. Don't know the word, though.

I mentioned the problems with the addons as a caveat for other testers, maybe even to  establish a "not compatible with" or a "not recommended with". Maybe others could look into the same problem. It would be sad to lose players with an issue like this.

I found out another thing this morning i'd like to discuss, the dxdll i mentioned will show you the speed of the game in fps in the above left corner.  So i know i play the mission at about 15-25 fps depending on situation. But as soon as i take out the map the game drops to 6 fps. Is this a known OFp problem, anybody?  I find it strange to have the frame rate drop although there is nothing to draw anymore?

Thanks, StG

[THobson]

Break this one then.  

If you kill the flag changer when he is changing the flag he will be replaced by someone else - if there is no one else then the pole stays empty.

[THobson]

StG

I did not feel you were criticising,  I was just trying to make excuses in case the next version doesn't have much better sounds.  We have re done them all quite a few times, but it is surprising how often the one we started with is the best quality.  That is a real problem if I change the words though ;D

Please keep the comments coming - I do like to be told good things (I am only human) but the mission will only get better of people also tell me what they don't like.

I really have no idea about the impact of the map on fps, sorry.

[Mikero]

>flags

goes down nicely but never goes up. It just appears at top

tried all combinations i could think of shooting loons not shooting etc, all combos worked in the sense that eventually each loon attempted to put flag back. All were russian blues apart from the initial red m16

@mac

yes, freda is my login and fred was my password, These mental abberations I now have to live with.

PS thank you for replying, I know, you're a busy boy.

[macguba]

@mikero - My pleasure.  

@StG - beta tests always sound a bit negative.  It is in their nature so don't worry about it.

FPS going down while map displays?   Explains a lot.  I bet its deliberate.   Give the comp a wee rest while there isn't much to do.

Tried very briefly to break new version but failed.     What happens if the flagpole is destroyed/damaged?