A long run

[THobson]

Does anyone have experience of large and long missions?  I have a strange problem with one I am making.

I am creating an environment that covers a whole island.  My intention is to have a wide range of activities going on across the island that represent a realistic occupation by two groups of opposing forces during an armed truce.  Within this environment I can then create several different missions.

So I have jeep patrols on circular routes, I have convoys of trucks going back and forth between towns (I use boolean variables to prevent collisions) I have fuel stations that each patrol and convoy visit (at which point I run a script that repairs and refuels them), infantry disembark from their transport, search towns and then get back in their vehicles to head off elsewhere etc. etc. The idea is to have a self contained environment that needs no help from the player to keep it all running..

Everything works, for a while, but eventually, and so far unpredictably, things break down.  Convoys and patrols get stuck at waypoints they have visited a dozen or so times before.  Jeeps get stuck between waypoints at places they have been to many times before, others in the patrol run slowly waiting for them and then eventually run out of fuel before they get back to the fuel station.  One pattern emerging is that it is not the lead jeep of a patrol that stops first.  Sometimes it all runs for a couple of hours before there is a problem and sometimes it can run for 20+ hours, but eventually something goes wrong.

So if it will keep running for several hours before there is a problem why am I bothered?  Well firstly it offends my sense of tidiness, and secondly if I don't know what the problem is how do I know it will not happen much earlier sometimes?

I am reasonably convonced that the problems do not result from convoys and patrols colliding.

Any thoughts or suggestions gratefully received.  

[dmakatra]

My advice would be to rework the entire system. Not only does this system break down, it will also use a lot of CPU to keep everything moving. Better would be to createvehicle stuff around the player and keep track of convoys and stuff via variables. It isn't über realistic, but it's a simulation and I guess that's what you're after if I ain't misstaking. It will also cause a lot less lag.

:beat: *Gets Shot* :beat:

[macguba]

You don't need refuel routines for vehicles.   They will refuel automatically if they are below the threshold (about 20% I think) and passing a fuel station or barrels.

I know the problem you refer to:   never got to the bottom of it myself but I think it's a randomness thing.     OFP has randomness built into it, that's partly what makes it such a great game.   Let it run for long enough though, and the bizarre, crap very unliklely possibilities come home to roost.    

The lead vehicle is indeed rarely the one to hit trouble:   I think this is because it has a clear road with nothing to do but follow waypoints.   The other vehicles have to follow the leader.    Because of the random element, the leader will take a slightly different route down the same stretch of road each time.    Because of the random element, the other vehicle will follow in a slightly different way each time.   If you run the simulation enough times, sooner or later the other vehicle will get itself stuck between two trees.

The solution, I think, is a slow loop that checks the position of each vehicle.   If it hasn't changed, and it is supposed to, then setpos it a few yards away.     At the end of the setpos section of the script I'd refuel and repair the whole group, just to be on the safe side.    If you want to be sure the player doesn't see, check that he is sufficiently far enough away.

I ignored all this in the Un-Finishable Mission because it didn't really matter:  I had repair routines to keep them on the road but the blackop motorbike patrol, for example, rarely makes it round its loop even once without coming to grief.   However, this just splits the group up which in some ways adds to gameplay - you never quite know if you've got them all.


Edit:  Armsty is right.

[THobson]

Thanks guys.  I feared as much.  

On the setPos trick.  I have written a script that instead of an immediate setPos will move the vehicle smoothly backwards a few meters (I don't know who might be watching at the time).  Problem is that some of the vehicles quite correctly will need to sit in one place for several minutes - either to avoid using a piece of road that is already occupied (that is guaranteed to cause a problem quickly) or to wait while their on-board troops have got out, searched a town and then re-boarded.  I am still thinking this through.

On the refuelling bit.  The script only runs when the vehicles are at a fuel station.  Each 'lap' of the patrol takes 40%+ of a tank of fuel and I have removed the fuel from all the other fuel stations on the patrol route so I do this to force a refuel even if they think they don't need it.

Another reason I wrote the script is that I did not know they would do it themselves  . Thanks for the information.

I did have a support group at a support waypoint, but they just got too active running around filling up vehicles and just got in everybody's way.

Amsty.  I know you are right.  But that is not what I want.  I really do want to create a working island.  Please bear with me in my old age!

[THobson]

OK - my solution for the jeep patrols that I am currently soak testing:

Every 5 minutes or so:

For each vehicle in the group that is not the leader's vehicle:
if the vehicle is:
- alive (ie it exists)
- canMove
- side driver == east  (or west as appropriate)
- distance to leader's vehicle >= 500
- distance to player >=500
- distance of player to leader's vehicle >= 500


then it is setPosed to 25 meters exactly behind the leader's vehicle and facing the same direction.  Subsequent vehicles being setPosed are placed 10 meters behind the previous setPos-ed vehicle.

then:
each vehicle (including the leader's) is:
- refuelled
- damage set to 0
- damage set to 0 for all crew in the vehicle

Can anyone see any logic flaws in this or ways that it can be improved?  
(For example I am not too sure about restoring full health to all crew members)
 

[macguba]

Add the fuel before checking the canMove condition, or at least investigate what result you get for canMove on a vehicle at empty.

Don't setDammage 0 the crew, setDammage (getDammage - 0.5).

These guys should be on very high skill.   Dunno if it really helps, but ...

Check the whole road network (drive along it) and make sure there are no static objects placed closer than about 2m.    An object in one place can have a weird effect on the driving of a vehicle hundreds of yards away.    Sometimes you can get away with it, and sometimes you can't.    Depends on the object and the exact location.

500m might turn out to be a little too high IMHO, but numbers like that are always subject to lots of experimentation.      As a player you don't really see much happening beyond about 200m unless you're looking for it.

Give the drivers NVGs for when it gets dark.   Some dismounts too.

[dmakatra]

A bit OT: Could you at least use the benchmark command on some units? You've told me before you sit on a badass computer (although my benchmark was higher than yours, that thread was funny. "OMG! YOU BIATCH ARMSTY! You shouldn't have that high benchmark!!" ;D ) so you won't exactly experience the kinda lag an avarge OFP player would.

:beat: *Gets Shot* :beat:

[THobson]

Add the fuel before checking the canMove condition, or at least investigate what result you get for canMove on a vehicle at empty.

Comref says that canMove is unaffected by fuel level - I will check.

Don't setDammage 0 the crew, setDammage (getDammage - 0.5).

I was wondering about this.  I have a 'complete refresh' script that sets fuel 1 dammage 0 for vehicles and crew.  It sort of simulates a crew change over.  The script is used when it returns to base, I call the same script after doing a setPos - just lazy.  I think you are right I shouldn't really do that here.

These guys should be on very high skill.  Dunno if it really helps, but ...

They are - and I don't know either.

Check the whole road network (drive along it) and make sure there are no static objects placed closer than about 2m.    An object in one place can have a weird effect on the driving of a vehicle hundreds of yards away.    Sometimes you can get away with it, and sometimes you can't.    Depends on the object and the exact location.

I have been along those roads (as a passanger in the patrols) until I was dizzy.  There was one corner where they sometimes left the road and hit a tree.  I fixed that.  I will keep checking.

500m might turn out to be a little too high IMHO,

You are right, I think I have it down to 300, and still checking.

Give the drivers NVGs for when it gets dark.  Some dismounts too.

Already have.

A bit OT: Could you at least use the benchmark command on some units?

I am a long way from finishing this and I may well do exactly that.

Bye the way Armsty - what's with the name change?

[Planck]

Bye the way Armsty - what's with the name change?

I was wondering about that too.....   ;D

Is it just coincidence that dmakatra backwards is:

artakamd.

I wonder what amd means.


Planck

[dmakatra]

LMAO! Didn't see that. And no, the answer to the name is much simpler than that. A hint, think capital letters...

I'm converting into this name gradually on all places I'm active in. I had two before, both stupid. I mean like Armstrong? I'm not even yank! ;D

:beat: *Gets Shot* :beat:

[macguba]

Dumb Motherfucker Also Known As The Real Armstrong

[dmakatra]

Actually, that's almost it. Except the Dumb Motherfucker part. It's my other nickname which I used in all other thingies outside OFP. Das Mattesnille. So it's:

dmakatra = Das Mattesnille also known as The Real Armstrong

Kinda neat eh? Anyway, we've strayed away from the topic quite a bit now haven't we?

:beat: *Gets Shot* :beat:

[THobson]

Anyway, we've strayed away from the topic quite a bit now haven't we?

Well it is my thread and I did ask the question.  You will always be Amsty to me.

[General Barron]

Interesting topic here... I don't have much experience with it myself, since I usually have infantry moving around, not vehicles. But I'm curious: when you test this, do you set the time accel to x2 or x4? At least for me, doing that will make the AI do things like crash into trees on turns in the road, and generally cause chaos.

Of course, even if you AREN'T upping the time, the actual player of the mission most likely WILL, at some point. So on my computer at least, your simulation is SURE to get wacked out, unless you use some of those ugly scripting tricks you and macguba were working on.

Keeping that in mind, you may have to implement even more ugly scripts, or else consider what Arms.... I mean dmakatra said. Or you could restrict the player from using the acc-time button.

[THobson]

All my soak testing is on x1 speed.  A 20+ hour soak causes no end of family grief.  

I plan to have a trigger that fires if Acctime != 1 and resets it to 1.  Not just to solve the problem you correctly out line, but also to ensure the player plays the game I have written and not some high octane blast through.  Is there a less resource intensive way of turning time acceleration off than using a trigger?

The execise is proving quite interesting.  After an overnight run this morning I saw my convoys were in a configuration that should be impossible.  No time to check before leaving home, so I hope the computer is not needed before I get back tonight to check the details.