AutoPillock is finally released. Sample control module, two drones, and the Building guide is ready.
https://steamcommunity.com/sharedfiles/filedetails/?id=2900108843

Hello do this drones works on planets?

Just wait a bit for a full release, it's hopefully coming soon.

Hey, I was wondering if you could help me with my ship please... I would like to make my drone also autonomous but it does not work...

Awesome, and hilarious on that last drone. I can definitely design a carrier around a system like this, or even adapt one of my existing ones or drones to fit better with it.

https://www.youtube.com/watch?v=4wBrTSN41wo

My drones are too PCU heavy for spamming so I'd like to have them back if they survive lol

Yeah, I agree. On the other hand, while it is interesting to implement from a research point of view, it's not a big deal. Deployment of drones is a tiny fraction of their lifetime, and they are usually disposable and aren't meant to return (at least in PvP rather than roleplay).

Once again, more excited for this than Grid AI. I don't think anyone's tried having a drone be able to know when it's inside the carrier versus outside before. That could make a world of difference.

I don't plan to support any mods yet, at least not in the upcoming release. So yeah, if the modded weapon implements the same IMyUserControllableGun interface, then it would trigger without need for timer (velocity, range and precision can be set via group tags). Otherwise, you can add a timer to that group.

I've just spend a few hours building a HighFleet-themed carrier for proper testing. Navigation works good (the A* search itself) but I realized that I need a different kinds of nodes - normal and "external", the latter represent entry points for world-carrier transition. Otherwise, the drone just picks the closest path node and goes straight for it through carrier wall. In general, it looks promising.

That looks incredible. I'm pretty sure I can design a carrier that works with the nav mesh if it's THAT precise. The speed shouldn't even be an issue.

As long as AP can aim a fixed weapon that's attached via a hinge/rotor, I should be good. Well maybe: Can modded fixed weapons be fired by AP or will I need timer blocks? There are two kinds of drones I'm trying to make, so this isn't related to the docking stuff.

This is how it looks atm: https://www.reddit.com/r/spaceengineers/comments/ynqt0o/autopillock_docking_navigation_using_carrierbound/

It just needs some locking so drones won't collide at shared path.

Regarding angled weapons on a hinge, it's an interesting idea. I did not specifically test that, but it should work since it uses actual gun orientation to define "weapon face direction" - probably I just have to loosen the filter that compares weapon direction to normal vector.

Yeah it's not to control the rotor/hinge/whatever the weapon's on like a CTC, but just to aim based on the weapon's current angle. As long as AP can do that, then some fun and possibly complicated drone designs are possible.

The corridor navigation could still work if I'm understanding you right, the carrier itself just has to be designed with it in mind. A drone shouldn't have to be inches away from a collision just docking/launching, it just needs to not bump into corners or approach an opening facing the wrong direction. That said having both modes can't hurt, either. I like more natural looking flight, too.

If you mean fixed weapon on a fixed subgrid, then yes. It can detect and use weapons like gatlings on large grids via rotor/hinge mount. Anything in the "coaxial-weapons"group of the same construct. It won't control rotors until I merge that code from HudDog, and I'm not sure about that.

Idk about corridor navigation. I record rotation matrix at every point but the navigation behavior currently just aims the drone towards next waypoint and it works well enough imo. The problem here is that if you want super careful navigation it would require waiting for a drone to align before proceeding, and it gives a drone that stupid robotic look, like it's ran by vanilla autopilot or other drone scripts that can fly only forward. I like them aligning while flying, although I understand that it can be dangerous. Maybe I'll add two types of nodes, normal and precise, to control that behavior.

Well at least with orientation recorded we can getting through corridors properly and whatnot. That might be good enough, honestly.

Oh and I forgot to ask regarding the 6 direction fixed weapons feature. Is it possible for Autopillock to aim a fixed weapon on a subgrid? I have really terrible ideas I want to try when this goes live.

It records orientation, but I doubt about speed limit. I think it's better to leave speed limit as a custom override if needed.

It sounds like noNav carriers would have drones sitting on external docks only. How precise is the rwp:rec going to be in the next version? Can it record orientation or set speed limits too, because that might help with a few things for internal carriers at least.

I think I'd stick up with a simpler solution based on nav graf. There would be two cases:

- the carrier does not have nav path attached - drones would launch all at once, having one immediate relative waypoint N meters above connector;
- the carrier has nav path, then drones would launch one after another, going through the path, notifying carrier when finished.

Rules would apply both ways - dock and depart.

Nav points would be created by positioning a drone and running command, similar to current rwp:rec.

The only issue is to dispatch drones after they launch somehow without collisions, and gather them when recalling. Currently people workaround this by using "force-wp:follow formation" as an intermediate point, but whether they collide depends on formation type and docks layout.

The drones liked to be about 2 large blocks above the LCDs to have space when they reach the connectors. The example drones from the videos are basically pocket fighters, so that's probably the intended drone type. (I will continue to use 70ft long drones come hell or high water)

That's also a good point. I wasn't thinking about setup in survival.

When I experimented with navigation graph for docking, I used tagged blocks to add nodes (making block pillars to precisely place block that would represent a node, read their positions when ready, then remove that scaffolding). This is OK for creative, but I did not like the idea for having to place blocks just for that. Placing screens, if I understood correctly, is an interesting idea, but I don't want to make assumptions about drone size. I guess fleet command assumes some height offset for those nodes (2d, as you said).

Docking - As for docking, if you've tied the pathing info to the carrier, then it's already pretty convenient (for me at least). Even if you had to implement something a bit complicated, at least we'd only have to set it up the one time for that carrier.

The old Fleet Command scripts had some precise pathing back when they still worked. They used LCDs on the carrier and their orientation for direction. The AI would follow those until they were right over the connector and then dock. I don't know if that's a useful method to take inspiration from, but if you're trying to make the setup easier, that was a pretty easy one (only two-dimensional though iirc). It also meant you had to be careful where you put LCDs in the hangars.

A strafing drone would definitely need thrust in all directions or it'll only work in space. I'm just curious about what maneuvers are baked in and what can be spoofed with some slight tweaks. One thing that's practical over strafing runs is long range 'fire and crank' maneuvers. That way the drone doesn't necessarily have to risk return fire.

On that note, I'm pretty sure AP could have large ships try to fight facing broadside, thanks to the fixed weapon referencing. That will look amazing.

Honestly, I find a bit silly when fighters space games do a strafing runs, like in Avorion, X4, etc. Maybe it makes sense for games where side thrust is heavily constrained, and you have to quickly escape enemy weapons envelope using your high velocity. But in SE it's far more efficient to keep at max range and evade shots. I have planned BombingTask where an agent would do a run dropping a block-made bomb, but now I think it's just an existing Jab task from Draugr with extra steps. Why flying further and taking more enemy fire, when you can just reverse, drop another one, repeat? That would be fine for role-playing purposes and cinematic action though, but not really practical.

Yeah, docking gets completely redone. I'm still in a search for the best way for user to set it up. In the current new implementation docking approach path is tied to the carrier ship rather than drones, and it sends that path do a drone during docking or departure task.

Thanks!

At the moment it's just for missiles. There is a setting in an each task class that defines if this task is allowed for a single-thrust entity. The reason is that it replaces the aimpoint with another direction, because it needs rotation to change velocity vector. Thus it can't shoot at targets, because it rotates to control its' flight trajectory rather than to aim at interception point.

I can probably make a hybrid task where the APck would fly this way most of the time, but temporarily switches its' Aiming behavior to point at the target when it's close. Although I doubt it would work out well. Planes have aerodynamic lift that allows them to point at a target and still not lose altitude, while such single-thrust grid would instantly start falling.

Are you going to make a multilingual chatbot while you're at it? Kidding aside, that's amazing. I'm looking forward to what you're doing even more than the Grid AI update now.

Also, you mentioned 'SingleDirectionalThrust'. Is that just for missiles or could that be adapted to planes? I'm basically wondering if there would be a way to have drones do strafing runs instead of always fighting like helicopters.

One other question if it's alright: Is the setup for docking paths going to be difficult because of how waypoints are recorded, or is there more to it? Honestly, I could live with whatever the setup is as long as I don't have to fly/record the route with each drone separately. Data sharing is life.

Ability to have fixed weapons facing all 6 directions and switch them on the fly, support for complex weapons like rotor cannon, piston jolt, etc. Ripple fire for slower guns (like in HudDog) where they are cycled and aimed individually.

New thrust strategies, like SingleDirectionalThrust, that was missed for cheap missiles (when you build a missile with a single thruster), and maybe even wheel controller if I have time.

More flexible formation building based on ranks (where you can have drone rank 3 to be a leader of rank 4 drones, and rank 2 would lead rank 3). In current version it's very difficult to make more than one "host", so in the future version it would be possible to have entire tree of subordination.

Navigation mesh for docking, where you can define multiple paths how to approach/depart from connectors (not sure about this one though, did not find a convenient way for a user to set this up).

It would be roughly the same, but entirely rewritten from the ground up for better flexibility. Most core parts are renewed, like largely improved aiming speed and precision, better thrust handling, better weapons management, all thanks to HudDog and SCAM scripts evolution.

One big thing is serializable task interface that allows controlling drone from external script, copying task orders from drone to drone, doing auto-repeat command sequences, etc. A lot of new order types, like wait N seconds, wait for signal, ability to queue up targets for attack, etc.

Also, an option to have many drones or missiles be controlled by a single PB (without antenna, optionally using reference exploit). That allows drone to launch missiles on its' own (and missiles are controlled by the same PB).

*laughs in drone carrier*
Also, are there a ton of new features coming for AP or something? The old one works well enough aside from a few landing issues I always have.

I'm working towards AutoPillock and Command GUI scripts no matter what Grid AI brings (I post progress updates on reddit).

Hey Cheerkin, I was wondering if the upcoming grid AI update's affecting your plans at all.

After they connect to the host, that link should persist until server restart.

@Siker_7 not in this version, I'm going to improve that in the future release. You can work around this in several ways by preventing other controllers from replying to drone handshake:
- by having them farther that max antenna range (lower it temporarily)
- by disabling all host controllers except one and recompiling all drones to ensure that they would reconnect to that particular one

The controllers will be on separate ships, so that's not a worry.

Is there a way to have different controllers assigned to different groups of drones? I'm in a situation where I'm going to have multiple attack groups owned by the same person really close to one another, and I was wondering if I could stop the controllers from interfering with each other.

A long time ago I was trying to pair that docking script (which works perfectly on its own) with the fleet command carrier/fighter setup. I never finished testing it though.

I might give this a shot once I get around to drone testing again.

I used two remotes tho. One for pre programmed GPS patrol routes then one to send them to a spot in front of docks and that way point once they reach it they enable the auto dock. They bounce about a lil bit trying to get to the coordinates but usually in short order one at a time they hit the coordinates exactly and enable docking.

may wanna just consider allowing an outside docking program handle docking for the script somehow such as this one? Its fabulously well done and can dock to moving ships.

I simply set remote to avoid collision and enabled precision mode and I have 4 drones using https://steamcommunity.com/sharedfiles/filedetails/?id=2146371052&searchtext=auto+docking with https://steamcommunity.com/sharedfiles/filedetails/?id=2441200245&searchtext=shart for button commands remotely and my drones have no issue going to same way points or docking

I've tried recording waypoints in relatively 'safe' paths near the docks and even docking drones one at a time. My best results were 3/4 undamaged landings.

I'll probably just wait for the release version to come out since I'm not actively working on drones right now. I'm just curious if any of the changes can help solve some of the issues I've had.

The way I used them long time ago - before docking I forced them to go into follow-formation, that ensured that they would get in line slightly up and left-right from the carrier, and then force docking.

Ah, I see. I already work on docking. There is a tree graph that allows simple relative pathing during docking and departure, but I'm yet to figure out a way of conveniently setting those waypoints for a user.

In the version you have, maybe you could work around those issues using rwp waypoints. Those relative waypoints are set against a host connector, but not specific one - they are aligned to the one that drone was assigned to during docking. Best bet would be making all connectors on one side of the host ship, and then making one RWP really far away up from connectors. This way they would still collide, but only if they happen to be from the opposite side of the docking area.

Specific drones on specific docks, yeah, but having them consistently pick the nearest connector to them might be just as good. I've tried all sorts of things, even recording waypoints, and my drones still tend to pick the connector that will ensure a collision on approach.

I'm just looking for ways to make docking/launching reliable.

How would this be useful? You mean like "this type of drone goes to that dock group", or literally "this specific drone is bound to this single connector"?

"Sub-units"? Maybe, just maybe Moebius Zero will rise again.

By the way, cheerkin, is there going to be a way to manually assign docks to specific drones/subunits at some point?

It also has a concept of "sub-units" - when many instances of autopillock core are ran by a single programmable block. In this case all sub-units are subordinates of the parent unit.

This version has quite simple host-drone system, intended for using a single host. Release version going to have more flexible way, something called tactical graph, where you can have whole hierarchy of subordination (based on "size rank" of the drone).

Here is a demo (I had a main big ship which had a few subordinates of lower rank, each having own smaller rank drones):
https://www.youtube.com/watch?v=C-nN-mCVh0o

So I got to use a different docking program with your script then my little drones well they can just follow the host drone on a pre-programmed GPS route and we're set. Makes you wonder though, might be a better way this could be done?

What initially brought my attention to all this is like I have a bunch of little drones right and a host drone so I'm using your build but due to your you know script design if I try to tell them to doc all the little drones aren't going to dock in her station dock they're going to try to talk on the host.

It's almost painful to see all the typos my phone puts on my messages lol but I think you get the point I still think you've done fabulous work just offering a suggestion something I've noticed about it. It's still easily the best combat drone script available for people out there.

I'm not sure what your focus is for 2.0 version of The script but I think the script would do well with a station or a mother ship version for the controller. Right the way the script is wrote and designed you really don't want to use it on your station because you're not going to have your drones circling around your station properly if it's on a planet for example so I think it would be better if the station or mother ship controls such as formation flying, versus the pilot drone telling the other drones what to do? I mean if you designed it right you can still have your host drone setup but it wouldn't be mandatory I guess it's just what I'm thinking. You could use this on a station now I'm assuming you just can only use some of the commands for it.