(Review Completed) [SP] Un-Impossible Mission

[THobson]

One (final?) comment.

I think the absence of an hyphen in 'UnImpossible mission'  in the list at the begining is less likely to be noticed than the absence of half of the 'n' in Un-Impossible mission.  I don't think it is necessary change all references just that one.

Ok it is two comments:

At the end what about an absolutely cast iron, copper bottomed, iron clad, safety net (which probaly would not be safe if it was made of those materials!).  Something like deleting all loons > than a certain distance from the flag, and over time steadily reducing the distance.  Only start this after a long time (so that it would only kick in if something went wrong).  That way you could guarantee the mission will end.  If you have someone devoting the time necessary to complete this mission I think you owe it them to make sure it finishes, even if you do cheat to do it.

[macguba]

1)  That's a good idea, I'll try that.

2)  I've been thinking about that too.   I've been testing that script this morning, and there are no problems at all with stuck vehicles - the loons just disembark.    However, I found two other major problems with it, only one of which is fixed so far.  

[THobson]

I have often written programs that had problems,  I fixed the problems only to discover more.  Eventually all that changing killed whatever structure there was and I found the best solution was to start again.  I had a bit of that feeling looking at Uphill.sqs

As this really is absolutely key to the mission I would be happy to have a look through it if a second opinion would help.

[macguba]

Well, the good news is that I not only fixed the outstanding problem, but also the problem that it introduced and another independent problem.   ;D

I've added a line to delete anybody other than a cobra more than 1760 away from the flag... yes I know its metres not yards but a conversion would be inelegant.  

Latest version of the script attached - second opinions very welcome.   At present it seems to be working.

[macguba]

Wouldn't attach to the last post for some reason.

Edit:  aaarggh it thinks it is.

Edit:  the real name is

uphill.sqs

if you want it to work in the mission.   The TEST part is just to get it posted here.

Edit:  that version still has a problem.   New one coming.

[THobson]

I am not sure I understood much of that.

I will focus on

New one coming.

[macguba]

Lol, I can't say I do either.

Anyway, here is the latest version.

It's still not working correctly.   I don't really understand why  not:  I think it may be something to do with the way the game handles vehicle units.   Or it may just be a mistake.

[macguba]

Ahha!  Found it.   Had a couple of == instead of >=.

[THobson]

A gift.  

It took exactly 10 minutes.  I know because that is how long it took for my pizza to cook.

To change the amplitude of the swing change, wait for it  _swing
and to change the periodicity of the swing change, you guessed  _period

It doesn't look too bad as it is

I will now have a look at the latest uphill

[Planck]

You know guys............

Un-Impossible Missior looks just as good as Un-Impossible Mission.

However if you really want to change it, the difference is minimal........unless english isn't your first language.

;D  ;D  ;D


Planck ;D

[macguba]

A present?  For me?  Oh, you shouldn't have.  

That's pure dead brilliant, thank you.     I love the little pause at the end of each swing, so much better than before.     Very kind.


@Planck ... hmm, yes the Un-Impossible Missior ..... an interesting thought ......  

[macguba]

Done it.  This one appears to work the way it was supposed to.    There were a couple of typos in the last version.

[THobson]

Bloody hell... I can't keep up.  Here are my comments and questions on WORKSuphill.sqs.

General points:
For each unit that is in a group of N units that unit will be given the required instructions N times for each loop (applies to both Sections1 & 2).  I suppose it gets the message home.  I think writing it from scratch an alternative might be to ignore units that are not group leaders and then run all the instructions for each member of each group.  I would not suggest you change now though.

There are several hints that have not yet been commented out.


Specific
1.

Code: [Select]

; these variables ensure that the setpos loop is done only once
_pass1=false
_pass2=falseThe comment is not correct.  The setpos command is done every second time through the Section2 loop if loons <=3.  (_pass1 = false in Section2 ensures this.  The code is good the comment is not.)

_pass2 is not used

2.  allowGetin false is used in Section2 but not in Section1.  Is this okay?

3.  What does setUnitPos {auto} do?  I presume it is ok to use lowercase??  Comref shows all uppercase.

4.  Section1:  _cargo is a sub-set of _group.  I think therefore that all of the following is redundant:

Code: [Select]

"_x setUnitPos {auto}" forEach _cargo
"_x allowFleeing 0" forEach _cargo
"_x setBehaviour {aware}" forEach _cargo
"if (alive _x and (not canStand _x)) then {_x setDammage 0.2}" forEach _cargo
"_x doFollow leader _x" forEach _cargo
"_x doMove getPos flag1" forEach _cargoas it is all repeated immediately for _group


5.  This appears a lot:

Code: [Select]

_trigList = list mapTrig
_upList = +_trigList
_count = count _upList
Why this and not:
_trigList = list mapTrig
_count = count _ trigList
?

6.  The line:

Code: [Select]

? (alive _endLoon1) and (_endLoon1 distance flag1 > 250) and ((flag1 distance _endLoon1 < (_pos1 + 2)) and (flag1 distance _endLoon1 > (_pos1 - 2))) : _endLoon0 setPos [(getPos object 42683 select 0) + 2, (getPos object 42683 select 1) + 5, 0]
Should read:
? (alive _endLoon1) and (_endLoon1 distance flag1 > 250) and ((flag1 distance _endLoon1 < (_pos1 + 2)) and (flag1 distance _endLoon1 > (_pos1 - 2))) : _endLoon1 setPos [(getPos object 42683 select 0) + 2, (getPos object 42683 select 1) + 5, 0]

I will now have a look at the latest.

[macguba]

Bloody hell... I can't keep up.

Lol yes it has been a bit of a shambles, sorry.

For each unit that is in a group of N units that unit will be given the required instructions N times for each loop (applies to both Sections1 & 2).  I suppose it gets the message home.  I think writing it from scratch an alternative might be to ignore units that are not group leaders and then run all the instructions for each member of each group.  I would not suggest you change now though.

The multiple passes are required for some reason:  with single pass a fair number of loons just hide in forests.  I suspect that they are so stupendously scared that the allowFleeing 0 command kinda wears off.

There are several hints that have not yet been commented out.

I think I got them all in the BETTER version.

1.; these variables ensure that the setpos loop is done only once

Fixed

2.  allowGetin false is used in Section2 but not in Section1.  Is this okay?

Yes.   Section 1 is not about getting loons out of vehicles really:  section 2 is.

3.  What does setUnitPos {auto} do?  I presume it is ok to use lowercase??  Comref shows all uppercase.

OFP code is supposed to be case insensitive.   It usually is, though rare and obscure counterexamples have been reported.     There are some units (eg snipers) that have setUnitPos "down" commands:  this keeps them on their bellies.   "Auto" allows them to stand up, which means they don't have to crawl up the hill.

4.  Section1:  _cargo is a sub-set of _group.  I think therefore that all of the following is redundant:

It would be if the loons in cargo were in the same group as the vehicle.   If they are a seperate group then you need to duplicate the code.  In fact, the only group where this occurs is the Bradleys (light armour) and it's unlikey they would still be alive, but you never know.   If a group is totally in cargo in a seperate vehicle you can't grab them with a West present trigger.

Edit: yes of course I should have added the arrays together.  Duh-oh.

5.  This appears a lot:
trigList = list mapTrig
_upList = +_trigList
_count = count _upList

The command + is vital: it crystallises the array.   If you don't use it, then the array you are dealing with updates automatically while the loop is running.    Consequently lots of bad stuff happens becuase your counters get screwed up as the number of loons in the array changes.  The number can go both up and down of course.   You could code your way out of it but this seems easier.

6.  The line:
Code:? (alive _endLoon1) and (_endLoon1 distance flag1 > 250) and ((flag1 distance _endLoon1 < (_pos1 + 2)) and (flag1 distance _endLoon1 > (_pos1 - 2))) : _endLoon0 setPos [(getPos object 42683 select 0) + 2, (getPos object 42683 select 1) + 5, 0]

Should read:
? (alive _endLoon1) and (_endLoon1 distance flag1 > 250) and ((flag1 distance _endLoon1 < (_pos1 + 2)) and (flag1 distance _endLoon1 > (_pos1 - 2))) : _endLoon1 setPos [(getPos object 42683 select 0) + 2, (getPos object 42683 select 1) + 5, 0]

Now that is a very impressive spot.   :thumbsup:   I found it myself, sadly:  it is the most important change between WORKS and BETTER.

Many thanks for hacking through this.     I've found several other minor mistakes in the mission while trying to fix it.

[THobson]

OK It is now 'glass of wine time'  so you won't get much coherent out of me after this for today.

One comment:

Have you seen how far away 1760 is from The Hill??   Instead of:

Code: [Select]

"if ((_x distance flag1 > 1760) and (not (typeof _x == {cobra}))) then {deleteVehicle _x}" forEach list mapTrigWhat about something like:
 if (_time <60*30) then {_killdist = 1760} else {_killdist = 1760 - (_time - 60*30)*(1760-250)/(60*45)}
if (_killdist < 250) then {_killdist = 250}
"if ((_x distance flag1 > _killdist) and (not (typeof _x == {cobra}))) then {deleteVehicle _x}" forEach list mapTrig

For the first half hour it will kill things > 1760 away.  for the next 45 minutes the distance will reduce steadily until it is killing anything >250 away.

Just a thought.

I will have a look through the latest version tomorrow if that is okay.