[Help] Overriding or reordering waypoints in remote block.

Is there a way to take the list of waypoints in the remote block and reverse their order so the last entry is now the first and the first the last?

I know of the functionality to add a waypoint via the programmable block and to clear the list. But do we have more controlling the list than that?

I'm trying to create a Space Pirate drone that uses one remote with autopilot to circle a bunch of waypoints, then if it detects a player along the way, to switch over to a second remote block and attack the player (same functionality as the pirate drone script), but either store the waypoints in the script itself, then add them all in the reverse order they were generated and set the autopilot or simply reorder them as described above.

Basically create a breadcrumb trail and then follow it back and stop at the point of origin.

Any help is appreciated.

 

I don't remember the Api from the top of my head but I assume you can read the waypoints as well yes? If so, worst case scenario, extract all waypoints, clear the list and readd in desired order.

 

I think only add and clear :\

 

Ok, that's quite silly... I guess someone needs to do something about that then...

 

Right now not even a check if the auto pilot is active is possible

 

O.o not even via terminal property?

 

The interface offers these things:

 

The interface, sure, but what about the terminal properties? You can use my gallery to find them. I'm at work which is why I can't simply check these things myself...
https://steamcommunity.com/sharedfiles/filedetails/?id=423751353

 

I can't check either, at work, too

 

In the source code there is this:

Code:

var autoPilot = new MyTerminalControlOnOffSwitch<MyRemoteControl>("AutoPilot", MySpaceTexts.BlockPropertyTitle_AutoPilot, MySpaceTexts.Blank);

So maybe AutoPilot could be read via GetValue<bool>?

 

Yes, it should be possible to do that.

 

@Malware
btw, do you also understand the comment for GetFreeDestination in the way that it should only be available for drones? Sounds to me a bit that way

 

Kinda... What I (think I) know is that GetFreeDestination isn't really needed for drones since obstacle avoidance ended up being built-in for the remote anyway.

 

Ok. What do you think: Will GetFreeDestination go away or stay? It is used for radar scripts a lot (and is a sim speed killer) :\

 

Sorry - I haven't got the slightest idea. My money is on "no" though. It's my experience that they don't make breaking changes unless it's absolutely necessary (or make honest mistakes ).

 

So... Mr. Malware, access to the List that controls autopilot waypoints in the ability to reorder the list, insert into the list, replace a waypoint on the list, and reset the waypoint list, would be most helpful for creating better pirate drones as well as provide some additional functionality for players looking for more depth in the autopilot. This functionality is already available to players through the autopilot terminal menu, so I can't see this as a security risk as it can be done manually already. Thoughts?

 

No risk but just not available at the moment
But adding, clearing and configuring the remote control is already possible, accessing the list is not necessary imho.

 

If you're programming Pirate Drones that are dumb... yes. If you want to put some logic into them... no.

 

I agree, I can't see any problems. My general attitude towards the API is: Can the player do it through the menu? Yes? Fine, then the PB should be able to do it programmatically.

 

Why would that need access to the list? O_o Having access would probably make it a lot easier though

@Malware
The list in the UI contains waypoints from the users GPS coordinates list, not sure how that would work via scripts o_O

 

They are copied into the block, afaik

 

I think the easiest workaround currently is to either input the GPS coordinates in an LCD instead of the remote, or just hardcode them into the PB, so your program can manipulate the remote's waypoint list with just the clear and add methods. Disgusting, but it should get the job done.

Alternatively, iirc a remote can run a program whenever it reaches a waypoint. At which time the PB can record its current position. It wouldn't give you any waypoints the drone hasn't visited yet though.

Finally, there's the naive solution: Have a third remote with the reverse order already put in ops:

 

I think I may have figured it out. I'm still writing the code as we speak. I'm not doing any exception handling work yet as I'm trying to just get to proof of concept.

Edit: I have it figured out and it works. The bad news is that when using two or remotes on the same grid, it generates a bug where you lose control of autopilot for the other remotes permanently. The terminal buttons get stuck and greyed out. Though this wasn't a problem in 1.129... hmmph...

Code:

List<Vector3D> breadCrumbs = new List <Vector3D>();


void Main(string argument)
{
 var remoteMain = GridTerminalSystem.GetBlockWithName ("Remote Control - [Main]") as IMyRemoteControl;
 var remoteAux = GridTerminalSystem.GetBlockWithName ("Remote Control - [Aux]") as IMyRemoteControl;
 var remoteAttack = GridTerminalSystem.GetBlockWithName ("Remote Control - [Attack]") as IMyRemoteControl;
 var timerWaitLong = GridTerminalSystem.GetBlockWithName ("TB [Wait Long]") as IMyTimerBlock;
 var timerHuntEnemy = GridTerminalSystem.GetBlockWithName ("TB [Hunt]") as IMyTimerBlock;
 string waypointName = "";
 Vector3D origin = new Vector3D(0, 0, 0); 
 var debug = GridTerminalSystem.GetBlockWithName ("Debug") as IMyTextPanel;
 
 switch (argument)
 {
 case "StorePath":

 origin = Me.GetPosition();
 breadCrumbs.Add(origin);
 break;
 
 case "ReturnPath":
 
 breadCrumbs.Reverse();

 remoteAux.ClearWaypoints();
 
 
 for (int i=0; i< breadCrumbs.Count; i++)
 {
 waypointName = "Return " + i.ToString();

 remoteAux.AddWaypoint(breadCrumbs[i], waypointName); 
 }
 breadCrumbs.Clear();
 remoteAttack.SetAutoPilotEnabled(false);
 remoteMain.SetAutoPilotEnabled(false);
 remoteAux.SetAutoPilotEnabled(true);
 timerWaitLong.ApplyAction("Start");
 timerHuntEnemy.ApplyAction("Stop"); 
 break;
 
 case "AvoidCollision":
 origin = Me.GetPosition();
 remoteAux.ClearWaypoints();
 remoteAux.AddWaypoint(origin, "Waiting Here");
 break;
 
 case "StopRemotes":
 remoteAttack.SetAutoPilotEnabled(false);
 remoteMain.SetAutoPilotEnabled(false);
 remoteAux.SetAutoPilotEnabled(false);
 break;
 }
 
 
}

 

The waypoints added by scripts are NOT in the users's GPS coordinates list.

When the user adds waypoints in the UI from the UI's GPS list, it is COPIED into the remote control's list. If the user changes the GPS waypoint, it does NOT change the waypoint in the remote control.

Scripts do not have any access to the users GPS list.

If the user opens a text panel (ex, ''edit public text') with text formatted in GPS format, then the system will have those GPS coordinates show in the users GPS list.

Here is a video (from almost a year ago... agh!) showing how to get the scripted waypoints from a text panel into the user's GPS list:

 

Exception handling will break your script, I'm afraid.

 

@Ronin1973 I'm afraid I have figured out why no waypoint manipulation system has been added yet. As we already know, waypoints aren't just points and names, they also contain actions to be performed when a waypoint is reached. The problem is this: Currently there is no way to represent these actions in an ingame script, which means that these actions will be lost when trying to change the waypoint they're associated with, which again - most likely - would result in any PR with this in mind getting rejected.

I'm still trying to come up with a workable solution, so don't give up just yet.

 

Well, if anyone has the skill and technique...

Though the biggest issue I'm facing right now is the auto-pilot not obeying waypoint actions, specifically the command to shut itself off. I suspect in stabilizing the autopilot vs gyro problem, they are quickly cycling the autopilot on and off once reaching the waypoint after running the waypoint actions. So the autopilot overrides any commands to turn itself off at a waypoint... making it very difficult to reliably dock a ship to a connector with autopilot

 

why not just forget about these actions for a while? just make a access first.
if add new it will be without action as default one.

 

Because the original request was to be able to move them around.

 

So you wrap the returned waypoint in an interface that knows but doesn't expose the Action (and anything else in there you don't want those in-game scripters getting their grubby unwashed fingers on)…?