Inhibiting waypoint statement execution + limitations of lockWP

[madrussian 347]

Hi all, I've been playing around with the lockWP command, trying to understand exactly what it does and what it does not do.

 

Quick editor testing reveals:

1. If you lock a group's WPs (via lockWP), and then add WPs to that group (via addWaypoint & setWaypointType "MOVE"), group will still move towards its new WP.
2. Then upon arriving at WP, even though group has lockWP true, it will still evaluate its WP condition, and still execute its WP statements.
3. If you then move that group's current WP (via setWPPos) (which group hasn't passed because lockWP true), even though group has lockWP true, group will again move to the WP's new position, and will again still evaluate its WP condition, and again still execute its WP statements.

Conclusions:

• lockWP does not inhibit group moving towards current WP
• lockWP does not inhibit evaluating WP conditions
• lockWP does not inhibit executing WP statements

Seems the only thing lockWP does is stop currentWaypoint (index) from advancing.

 

What I'd like to know specifically is:

How to inhibit execution of WP statements?  (whilst not removing them)

 

^ If there is currently no way to accomplish this, how about an alternate syntax for lockWP (inhibiting most or all of these things)?

 

Bit of background:

 

Spoiler

I'm writing an AI system and one of my tenants is not altering mission creators' WPs in any way.

When I grab a hold of an AI group though, conversely I don't want that AI group executing user WP statements, because that of course could (eventually, sooner or later, will?) totally mess up what my AI system is doing.  I'm using lockWP on these groups, but now that I know the above (lockWP not inhibiting executing WP statements), seems this command is not cutting the mustard.

Again, I need a way to simply inhibit WP statements.

 

[pierremgi 4737]

I never use that. I'm scripting waypoints. So, there is no reason for inhibit the move on next waypoint...  you just have to write a condition for creating the next waypoint.

[panther42 40]

I believe it will only work if you've given multiple waypoints to begin with.

You give AI multiple waypoints in script, then further in script, lockWP at one. 

Adding waypoint "after" the lockWP may override.

There are several topics on lockWP available in search.

 

This one from @johnnyboy may help.

 

If you want to inhibit the execution of the waypoint statements, just change out the condition to what you want to evaluate, or the statement itself.
If you change the condition from the default "true", the waypoint will not complete if your condition does not evaluate to "true".

If you want to leave condition to "true" so the waypoint will complete, evaluate what you want done in your statement.

Or, I've missed exactly what your intent is.

 

I tested lockWP in the editor, no mods except CBA loaded.  Works as expected.

place yourself and another soldier not grouped to you in the editor.

give the soldier one waypoint (close to you for testing).  In that waypoint under Waypoint: Expression >> On Activation: group this lockWP true;

run the scenario, and aim your cursor at the soldier once he gets to waypoint

hit esc and enter the following: group cursorTarget addWaypoint [position player, 0];      LOCAL EXEC

Does he move?

Point your cursor at the soldier again, and hit esc.

Enter the following: group cursorTarget lockWp false;      LOCAL EXEC

What happens?  He should move to your position.

You can add several waypoints to that soldier around yourself.  Put lockWP true as noted above in each one.  Follow above procedure to only lockWP false at each.  He will not move to next waypoint until such command is given.

[madrussian 347]

Thanks for the responses.  So, I read through carefully and agree you guys sound right on all points.  Also yes, seems I should clarify my intent.

 

In the system I'm creating, by design I'm not messing with WPs at all (aside from trying to stop group from continuing along WP positions or processing it's WP statements temporarily via lockWP or similar).  My code is designed to run alongside mission creators WPs.  I'm just looking for stronger way to "lock" these user created WPs, so my system is not affected by their WP statements.

 

I get that the WP's condition is the normal way to inhibit WP statement execution, and have used WP condition "false" many times in the past to achieve various ends.

 

Ok, I shall repeat original question & re-phrase slightly for clarity:

How does one inhibit execution of WP statements?  (whilst not altering WP's condition or statement, or changing group's current WP index)

 

Perhaps there is simply no way to do this.

 

^ If that's the case again I advocate for lockWP alternate syntax, to accomplish this.  AI creators could definitely make use of it!

[panther42 40]

15 minutes ago, madrussian said:

How does one inhibit execution of WP statements?  (whilst not altering WP's condition or statement, or changing group's current WP index)

Only way I can think of, without digging too deep, is "shoot him" before he reaches WP...  😁

I really do not think there is a way without manipulating the current WP, I.E. setCurrentWaypoint, or changing the WPs already given.

I don't quite understand what you are running along side the mission creators WPs themselves:

21 minutes ago, madrussian said:

In the system I'm creating, by design I'm not messing with WPs at all (aside from trying to stop group from continuing along WP positions or processing it's WP statements temporarily via lockWP or similar).  My code is designed to run alongside mission creators WPs.  I'm just looking for stronger way to "lock" these user created WPs, so my system is not affected by their WP statements.

 

[madrussian 347]

 

2 hours ago, panther42 said:

I tested lockWP in the editor, no mods except CBA loaded.  Works as expected.

place yourself and another soldier not grouped to you in the editor.

give the soldier one waypoint (close to you for testing).  In that waypoint under Waypoint: Expression >> On Activation: group this lockWP true;

run the scenario, and aim your cursor at the soldier once he gets to waypoint

hit esc and enter the following: group cursorTarget addWaypoint [position player, 0];      LOCAL EXEC

Does he move?

Point your cursor at the soldier again, and hit esc.

Enter the following: group cursorTarget lockWp false;      LOCAL EXEC

What happens?  He should move to your position.

You can add several waypoints to that soldier around yourself.  Put lockWP true as noted above in each one.  Follow above procedure to only lockWP false at each.  He will not move to next waypoint until such command is given.

 

Agree your test works as you state (and thanks for the help)  But it doesn't really cover my core concern, which goes something like this:

 

Let's say an AI group is moving towards its next WP, and I want to take some control over that group temporarily (like something rather complicated, using doMoves, doStops, and doFollows, but nothing to alter that group's WPs).  In this case, part of my intent is to stop that group's WPs from affecting the group while I'm messing with it.  At this point (while I am "controlling" the group's units), specifically:

 

1. I don't want the group advancing past it's current WP

2. I don't want the group evaluating it's current WP condition

3. I don't want the group executing it's current WP statement

 

Now lets say, while I am "controlling" the group's units, that leader does somehow arrive at group's next WP.  (Because I'm not necessarily doStopping all group's units all the time or anything.)  In this case, lockWP will stop #1, but not #2 or #3.

 

Meanwhile, #3 (group executing it's WP statement) could potentially really mess up what I'm doing.  (If you saw what I'm up to you'd totally understand.)

 

^ Edit: Typed all that before your latest response.

 

15 minutes ago, panther42 said:

Only way I can think of, without digging too deep, is "shoot him" before he reaches WP...  😁

 

Haha, that's awesome! 😉

 

15 minutes ago, panther42 said:

I really do not think there is a way without manipulating the current WP, I.E. setCurrentWaypoint, or changing the WPs already given.

 

That's what I'm thinking.

 

15 minutes ago, panther42 said:

I don't quite understand what you are running along side the mission creators WPs themselves:

 

Spoiler

Picture your run-of-the mill AI system, only probably more bizarre & haphazard.  Unfortunately I'm not anywhere near ready to reveal anything.  Lets just say it does lots of doMoves, doStops, and doFollows, other crazy stuff.  And needs to somehow not break peoples' missions.

 

[sarogahtyp 1104]

@madrussian why is it not an option to insert a "Hold" or a "Scripted" waypoint in groups waypoint chain then do your things with that group and if you have done what you want just remove that waypoint and set the current waypoint to the one it was before?

This should not break anything of the mission and you can do what you need to meanwhile...

[panther42 40]

@madrussian, What about copyWaypoints, to gather prior to your takover?

Copy groups WPs, and get their current, then manipulate after your done to "continue as you were"...

 

or, as @sarogahtyp mentioned above.

 

edit, that copyWaypoints may not work, as I expected.  Must copy from one group to another, unless you cloned the original group, etc.

[madrussian 347]

1 hour ago, sarogahtyp said:

@madrussian why is it not an option to insert a "Hold" or a "Scripted" waypoint in groups waypoint chain then do your things with that group and if you have done what you want just remove that waypoint and set the current waypoint to the one it was before?

This should not break anything of the mission and you can do what you need to meanwhile...

 

Good idea, yes I was considering this.  Seems to me, could still potentially mess up peoples' missions though if they are counting WPs, or storing WPs as they are in format [_group, _index] and all.  Also now that I think on it, wouldn't work in my existing dynamic mission Fight Back (without heavy modifications), because on various groups I'm regularly "deleting all WPs and giving them a new WP" in a new place.  Makes me wonder how many other missions do that too.

 

Seems we have competing ideas on best way to handle this:

1. Allowing groups to potentially run WP statements while one "controls" them (i.e. not attempting any counter-measure)
2. [sarogahtyp]: Inserting "Hold" or a "Scripted" waypoint while one "controls" group, and removing that extra WP once finished
3. [Panther42]: Copy group's WPs (via copyWaypoints), then delete the original WPs (or set to condition "false"), then "control" group, then when done restore group's original WPs (to "continue as you were")  [Hope I got the gist of this correct.]
4. [johnnyboy via PM]: Create a dummy logic in the desired group (to keep group from auto-deleting upon joining units to grpNull), then join all units to a new group via join grpNull, then "control" that new group, and once finished join units back to original group and delete the dummy logic.

So... Which would cause greatest number of problems in peoples' missions (and most severe)?  And which would cause least problems (and with least severity)?

 

Short of an alternate syntax for lockWP, seems these are the options.

 

[pierremgi 4737]

2 hours ago, madrussian said:

Thanks for the responses.  So, I read through carefully and agree you guys sound right on all points.  Also yes, seems I should clarify my intent.

 

In the system I'm creating, by design I'm not messing with WPs at all (aside from trying to stop group from continuing along WP positions or processing it's WP statements temporarily via lockWP or similar).  My code is designed to run alongside mission creators WPs.  I'm just looking for stronger way to "lock" these user created WPs, so my system is not affected by their WP statements.

 

I get that the WP's condition is the normal way to inhibit WP statement execution, and have used WP condition "false" many times in the past to achieve various ends.

 

Ok, I shall repeat original question & re-phrase slightly for clarity:

How does one inhibit execution of WP statements?  (whilst not altering WP's condition or statement, or changing group's current WP index)

 

 

Sorry, I'm totally lost about your final intent. I don't understand why you have waypoints , but you don't want to complete them... but.... but...
Does that concern your played group (player leader), any group?

Is it your scenario? are you scripting? are you trying to inject a code /cheat on a pboed scenario???

 

If I'm right, the very very basic is the use of : doStop/doFollow commands, but reading all these answers i probably missed something.

Why do you script WP statements if you don't want to run it???? Conditional waypoint statement is always possible with setWaypointStatement... but in which case do you want to change it???

 

 

[johnnyboy 3741]

16 minutes ago, pierremgi said:

Sorry, I'm totally lost about your final intent.

Hi Pierre.  Read the "background" in the top original post.  MadRussian is writing some AI code that he wants to temporarily take control of units.  During the time this AI code is controlling the units, he doesn't want any original Waypoints created by mission creator to be disturbed or to complete.  Once his special AI code is finished with the units, he wants those unit to then resume their normal waypoints.   The hope is that the AI code won't unintentionally break a mission scripted using waypoints.

 

I hope I explained that ok...  🙂

[madrussian 347]

24 minutes ago, pierremgi said:

Sorry, I'm totally lost about your final intent. I don't understand why you have waypoints , but you don't want to complete them... but.... but...
Does that concern your played group (player leader), any group?

Is it your scenario? are you scripting? are you trying to inject a code /cheat on a pboed scenario???

 

If I'm right, the very very basic is the use of : doStop/doFollow commands, but reading all these answers i probably missed something.

 

Development of a PBO-based AI system, think Lambs.  Only I've got a good ways to go, so not remotely ready to reveal anything.

Spoiler

Potential release very very far away (if ever).  May very well end up being just for personal use (or play with close friends, etc)

 

I'm not adding/using WPs, but again as a PBO-based AI system, I want this to work with any mission.  People use all sorts of WPs in their missions.  I don't want my system to break missions because I'm messing with creators' WPs.  Thus again I'm not modifying WPs.  Likewise, I don't want creators' WPs to break my system.  Thus, while in "control" I'm doing my best to inhibit WPs.

 

My system manipulates AI-only groups.  (Probably not player-led groups or AI-led groups with players.)

 

No, not a scenario.  If it was I'd have free reign over all the WPs.

 

Yes, scripting.  It's all script-based.

 

24 minutes ago, pierremgi said:

are you trying to inject a code /cheat on a pboed scenario???

 

What?  You kidding?

 

24 minutes ago, pierremgi said:

If I'm right, the very very basic is the use of : doStop/doFollow commands, but reading all these answers i probably missed something.

 

Yes, it's a bit more complicated than that.  Try it again from the top.

 

Edit:

Thanks j-boy, very good explanation. 😉

[pierremgi 4737]

Joker this time. 😉

[johnnyboy 3741]

Maybe thinking about the type of waypoints can help you decide what to do.  The most commonly used waypoints are probably Move, Get In, Get Out, Transport/Unload.

 

For Move waypoints, normal Combat AI always disturbs these anyway.  Units veer from their movement paths and fight until contact over, then resume path.  If that contact/fight resulted in them moving to a WP position, then that WP completes.  I think it would be fine for your AI system to behave the same way and not worry about the AI groups completing Move WPs inadvertently.

 

For GetIn, Transport and Unload, maybe your AI system should not take over those units during those types of WPs, as they have a more specific purpose to complete that is more important to mission design (my guess).

 

And what about player controlled groups?  If mission designer has created Waypoints for player group, then it may be more harmful to mission designer's intentions to run your AI system on the player controlled group, so perhaps exclude your AI logic from player controlled groups (or give player a method for choosing when to invoke your AI logic).

[madrussian 347]

@johnnyboy - All good ideas, man you really think this stuff through.

 

56 minutes ago, johnnyboy said:

And what about player controlled groups?  If mission designer has created Waypoints for player group, then it may be more harmful to mission designer's intentions to run your AI system on the player controlled group, so perhaps exclude your AI logic from player controlled groups (or give player a method for choosing when to invoke your AI logic).

 

I have it excluding player groups currently.  Eventually if I can make it work with player groups, I'll try to include them (with opt in from mission creator).

[mrcurry 470]

Its hard to say which method is the least intrusive, I think JBs suggestion is least likely to mess with purely editor-made scenarios but that's just a hunch, got no data to back that claim.

 

All methods have their pros but at same time I bet most of us could easily think of a legit scenario design to break each method.

 

I really question if a truly robust system is worth it. Imagine you would have to implement multiple solutions and use some auto-analysis or mission vars to control which method is used based on the situation for the group on question.

 

Maybe this early it's better to go whichever is easiest and focus on keeping the whole "pause waypoint"-functionality as modular as possible so you can easily rework if need be