question is it meant to deleted the set nodes if you recomp the PB or do they need to be saved with a command?

No they are persisted in PB Storage automatically. Wait a few hours, I'm making a video about setting it up on a real ship. The blueprint also gets an update to make adding nodes a bit easier.

Ok thx

good work so far

I've found two issues so far:

1. Minor, broken behavior(?):
Executing "dock all" (command:w:command:request-docking) from the carrier, while drones are docked, results in all drones undocking and re-docking again to the carrier.

2. I sended all 5 drones to engage a pirate ship, 3 of them got damaged to the point where they couldn't go back to the formation but remained in active antenna range. Other 2 returned.
Upon selecting "Disengage to formation" and trying to dock the drones they stayed in the formation.

Drone log
0: defs: 59
0: subset: 59
0: PBs: 2
0: added MyObjectBuilder_SmallGatlingGun/
0: added MyObjectBuilder_SmallMissileLauncherReload/SmallBlockMediumCalibreGun
0: added MyObjectBuilder_SmallMissileLauncherReload/SmallRocketLauncherReload
0: Group Light ballistic: 12
0: Group Heavy ballistic S: 4
0: Group Rocket: 2
0: Added and activated maintenance, total: 1
0: Starting task maintenance-1
0: Found 59/59 core blocks
1: Q tgp.global.gridsense.update enable, refs: 1
1: IgcListener 'tgp.local.gridsense.update--listener' kill
1: Model changed: Light ballistic
1: CeiseFire invoked
150: Q apck.ntv.update enable, refs: 1
3000: Parsing task: command:create-task:wingman
3000: Added wingman, total: 2
3000: wingman: forcing depart
3000: Added and activated wait-60-t, total: 3
3000: Starting task wait-60-t-3
3060: TFin wait-60-t-3
3060: OtherConnector undick wait complete
3060: Waiting for depart dpath
3060: Added and activated wait-for-condition, total: 3
3060: Starting task wait-for-condition-4
3910: Added and activated dpath, total: 3
3910: Starting task dpath-5
3910: Q apck-position enable, refs: 1
3910: Q apck.ntv.update enable, refs: 2
4348: TFin dpath-5
4348: Q apck-position disable, refs: 0
4348: Q apck-position kill
4348: IgcListener 'apck-position--listener' kill
4348: Q apck.ntv.update disable, refs: 1
4348: IgcListener 'docking' kill
4348: Resuming task wait-for-condition-4
4349: TFin wait-for-condition-4
4349: Starting task wingman-2
11673: Parsing task: command:create-task:attack:Name=atata
11673: Added atata, total: 2
11673: Starting task attack-6
11673: Q tgp.global.gridsense.update enable, refs: 2
0: defs: 59
0: subset: 59
0: PBs: 2
0: added MyObjectBuilder_SmallGatlingGun/
0: added MyObjectBuilder_SmallMissileLauncherReload/SmallBlockMediumCalibreGun
0: added MyObjectBuilder_SmallMissileLauncherReload/SmallRocketLauncherReload
0: Group Light ballistic: 12
0: Group Heavy ballistic S: 4
0: Group Rocket: 2
0: Found 59/59 core blocks
0: Model changed: Light ballistic
0: CeiseFire invoked
1: Q tgp.global.gridsense.update enable, refs: 1
1: IgcListener 'tgp.local.gridsense.update--listener' kill
150: Q apck.ntv.update enable, refs: 1
341: Parsing task: command:create-task:wingman
341: Added wingman, total: 1
341: Starting task wingman-1
1143: Parsing task: command:create-task:attack:Name=atata
1143: Added atata, total: 2
1143: Starting task attack-2
1143: Q tgp.global.gridsense.update enable, refs: 2
2596: Parsing task: command:create-task:attack:Name=atata:537940.571094209:-948958.319162806:6893192.6861368
2596: Added atata, total: 2
2812: Parsing task: command:create-task:cruise-fw
2812: Added cruise-fw, total: 3
11471: Parsing task: command:create-task:wingman
11471: Added wingman, total: 4
0: defs: 59
0: subset: 59
0: PBs: 2
0: added MyObjectBuilder_SmallGatlingGun/
0: added MyObjectBuilder_SmallMissileLauncherReload/SmallBlockMediumCalibreGun
0: added MyObjectBuilder_SmallMissileLauncherReload/SmallRocketLauncherReload
0: Group Light ballistic: 12
0: Group Heavy ballistic S: 4
0: Group Rocket: 2
0: Found 59/59 core blocks
0: Model changed: Light ballistic
0: CeiseFire invoked
1: Q tgp.global.gridsense.update enable, refs: 1
1: IgcListener 'tgp.local.gridsense.update--listener' kill
150: Q apck.ntv.update enable, refs: 1
665: Parsing task: command:create-task:wingman
665: Added wingman, total: 1
665: Starting task wingman-1
1966: Parsing task: command:create-task:attack:Name=atata:537940.571094209:-948958.319162806:6893192.6861368
1966: Added atata, total: 2
1966: Starting task attack-2
1966: Model changed: Heavy ballistic S
1966: CeiseFire invoked
1967: Model changed: Rocket
1967: CeiseFire invoked
1968: Model changed: Light ballistic
1968: CeiseFire invoked
1969: Model changed: Heavy ballistic S
1969: CeiseFire invoked
...
3973: Setting ripple fire (1/2) of Rocket
3974: IncrementRipple, new index: 0
39

One more thing I noticed is that the drones engage very close to eachother. Is that specific behavior for Attack point;command:w-send-task:attack:Name=atata ?

Originally posted by pro100tv:

I sended all 5 drones to engage a pirate ship, 3 of them got damaged to the point where they couldn't go back to the formation but remained in active antenna range. Other 2 returned.

It's hard to tell what happened from this log. I see you pasted 3 logs, one drone got cruse-fw command, others have not, some had attack command with no actual point in place, some had it.
I think there may be issue with issuing attack command when you have no known point to attack - they will accept task and decide that they should listen to datalink for a certain targetId, which was not provided too.
In that case they get stuck in attack task waiting for data, and subsequent task just sit in the queue. So to make them go, you need to issue command:next (it is used in Break-Off TMC alias so you can just spam this one several times).

Originally posted by pro100tv:

One more thing I noticed is that the drones engage very close to eachother. Is that specific behavior for Attack point;command:w-send-task:attack:Name=atata ?

Response-induced attacks and point attacks have different flight behavior. IIRC first uses old-one, and point attack uses more precise orbiting behavior, which has a drawback of having drones make very similar trajectories. I'm considering ways to improve this.

Originally posted by pro100tv:

I've found two issues so far:
1. Minor, broken behavior(?):
Executing "dock all" (command:w:command:request-docking) from the carrier, while drones are docked, results in all drones undocking and re-docking again to the carrier.

Yeah, that's possible. The thing is you can actually tell drones to dock to another carrier with just one click - they would undock automatically and dock to other ship. The issue is that to check if we are trying to dock to the same ship we are already at is not easy, yeah I know it sounds strange. I'll think about it more.

Thanks for feedback!

No problem! I kept testing today and I accidentally looped the drones upon docking (they docked and undocked couple of times in a row).

Is every command given from the carrier unit placed into the queue?

Also how complex the installation procedure of the final script is going to be? Is it possible to simplify it to be similar to TMC installation? (E.g. just group the components and go)

Any task-type commands end up in the queue. As usual, you can run them directly on a PB, via TMC remote mode, or broadcasting ("bc", "w", etc) through carrier.

I'm afraid it's impossible to simplify installation because of the level of flexibility it has.
"Just group the components and go" won't work, imagine drones/missiles connected or even merged to the main ship, how would all APck units sort out their respective blocks?

The only simplification would be having non-tagged remote instead of autopillock-remcon.

Forward-gyro is needed to be specified explicitly, because it's the orientation block.

"docka" the same, since we don't want the carrier to dock to other ship with just any connector, and user may want to have non-apck connectors too, hence the "dock-host" tag.

Instead of grouping, there would be a "design mode" where you disconnect you grid from everything irrelevant and build it, then "save", and after that the APck would ignore any block changes on the grid.

would it be possible to make it that you have a "drone helper/designer" PB to run on the drone that than writes data into something like a merge or remote control so the drone "Brain" knows what it can use on the same grid?


idk how well that would work but that is how Artemis PMW missile script finds missile parts


idk how that works

Originally posted by AN Marc Appledash:

writes data into something like a merge or remote control so the drone "Brain" knows what it can use on the same grid?

Yes, it uses the same approach. I did that for possibility of having merged missiles/drones ran by the same PB as the main unit.

nice

Force attack and any form of attack command not working. It just makes the drones circle around the target at high speed. This only happened to me on a modded server.

Server's creative world link: https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=2862105342
Mods used by the server: https://steamhost.cn/steamcommunity_com/workshop/filedetails/?id=2360308845

Would appreciate to know which mod caused such behavior

Weapon core

it messes with any vanilla script that has turret targeting or uses cams for raycast

vanilla it works fine

if you add Weapon core it behaves weird

that is what i noticed in my test





just tested it again and it does work with WC just has some problems(cruise forwards does not stop if turrets would be in range) that are related to Weapon core targeting and the fact that this script is made for Vanilla not WC