You basically just need an AI that isn't going to do anything to interfere with ship behaviour once it's initialised - nullAI should be fine for that.
If the code isn't working it'll be because something in the script initialisation isn't working. Possibly shipSpawned() is too early to be calling ship.performScriptedAI() - as I said, it's been a while since I worked on any of this.
Try the following as an AI: call it "DebugControl.js" or something (yes, js not plist - but this one does go in the AI folder)
That should be sufficient for now to permanently hand-off control to the ship script and debug console, and stop any other AI behaviour interfering.
(DumbAI will indeed cause the ship to rotate in place - but that's just because that's what it does)
I tried to follow your suggestion, and for the first time an Adder started slowly flying a big circle. So there is definitiely some progress.
When I ran `ship.AI`it said nullAI.plist, despite the fact that I had created the file as you suggested and modified my shipdata.plist like so:
{
"aitest_adder" = {
like_ship = "adder";
is_external_dependency = yes;
roles = "aitest";
script = "RemoteControlled.js"; // or whatever you called the file from my previous post
ai_type = "DebugControl.js";
};
}
But nevertheless, this concept seems to work in some stage or another. So now I would focus on the flight controls. I am not interested setting a virtual joystick like
but more in copying one player ship's position, orientation and velocity via the network into the other Ooniverse.
Can you confirm I just need to read/write these properties on player.ship to the other's ship?
You basically just need an AI that isn't going to do anything to interfere with ship behaviour once it's initialised - nullAI should be fine for that.
If the code isn't working it'll be because something in the script initialisation isn't working. Possibly shipSpawned() is too early to be calling ship.performScriptedAI() - as I said, it's been a while since I worked on any of this.
Try the following as an AI: call it "DebugControl.js" or something (yes, js not plist - but this one does go in the AI folder)
That should be sufficient for now to permanently hand-off control to the ship script and debug console, and stop any other AI behaviour interfering.
(DumbAI will indeed cause the ship to rotate in place - but that's just because that's what it does)
I tried to follow your suggestion, and for the first time an Adder started slowly flying a big circle. So there is definitiely some progress.
When I ran `ship.AI`it said nullAI.plist, despite the fact that I had created the file as you suggested and modified my shipdata.plist like so:
{
"aitest_adder" = {
like_ship = "adder";
is_external_dependency = yes;
roles = "aitest";
script = "RemoteControlled.js"; // or whatever you called the file from my previous post
ai_type = "DebugControl.js";
};
}
But nevertheless, this concept seems to work in some stage or another. So now I would focus on the flight controls. I am not interested setting a virtual joystick like
but more in copying one player ship's position, orientation and velocity via the network into the other Ooniverse.
Can you confirm I just need to read/write these properties on player.ship to the other's ship?
Yes - ship.AI points to the plist AI (and all ships have one) - while ship.AIScript points to the JS AI (and again all ships have one) - whichever one isn't in use is automatically set to the null file for that type so that it doesn't interfere.
Can you confirm I just need to read/write these properties on player.ship to the other's ship?
Position and orientation, yes.
Writing to velocity is tricky, however - the ship in its home instance of the game will generally have non-inertial velocity, but if you write directly to velocity you'll give the ship in the away instance inertial velocity instead, which doesn't behave the same way (though if you set the away instance ship to have ship.thrust = 0 then it'll be closer).
That's why I recommended the virtual joystick - you can set the turn rates and speed of the ship that way (reading from ship.roll, ship.pitch, ship.yaw and with a bit of calculation ship.thrustVector), so that it keeps doing things on frames where there's no update from the network rather than just drifting inertially in a straight line.
Yes - ship.AI points to the plist AI (and all ships have one) - while ship.AIScript points to the JS AI (and again all ships have one) - whichever one isn't in use is automatically set to the null file for that type so that it doesn't interfere.
Can you confirm I just need to read/write these properties on player.ship to the other's ship?
Position and orientation, yes.
Writing to velocity is tricky, however - the ship in its home instance of the game will generally have non-inertial velocity, but if you write directly to velocity you'll give the ship in the away instance inertial velocity instead, which doesn't behave the same way (though if you set the away instance ship to have ship.thrust = 0 then it'll be closer).
That's why I recommended the virtual joystick - you can set the turn rates and speed of the ship that way (reading from ship.roll, ship.pitch, ship.yaw and with a bit of calculation ship.thrustVector), so that it keeps doing things on frames where there's no update from the network rather than just drifting inertially in a straight line.
That's it, we are getting somewhere:
- My first try will just be to update position and orientation. It should look ugly, it is allowed to look ugly.
- Next I will go for the first derivation and add velocity.
- Finally I will add the second derivation, which should be the joystick position.
By then we have a number of variables but should end up with some smooth movement if, yes if we would not hard update positions but instead guide the ship to follow a bezier to the correct position...