Thank you for considering adding support for WeaponCore. Whether you end up adding support or not, thank you for the consideration. If I had any programming experience I would absolutely try and help!

NP! I just want to make sure everything works for vanilla before messing up with WC, including other related scripts that I'm making ready for release -ThrustProvider, TGP (targeting script with raycast, tracker turret, etc), and most importantly - Command script for RTS-like GUI to control any APck-managed grid conveniently (this is a tough one).

Would it be possible to add support for antennas that are on a drone/escort's subgrid? This is mostly a convenience thing for design since the large grid antenna is huge and looks bad on some builds when it's placed normally.

Antenna is optional and is directly used by code only for showing drone current state in its' name. Everything would work if you have any sort of connection - laser antenna, subgrid antenna, anything, just same rules as for you having remote access to those grids (not required to be in unit definitions). Adding subgrid support would heavily complicate sub-unit initialization so I doubt it's worth it.

I did some testing before and I just couldn't get my ship to accept any commands (from the parent ship) until I added an antenna on the main grid, so thought I'd ask.

There must've been another reason. I've used small antenna on a hinge for my large grid H2 missiles tests, so I can confirm it works.

I'll keep trying with the previous design then and try to figure out what's wrong then.

When Asteroid Detection gets added maybe add a mode to scout the surroundings for ore deposits and make gps markers for them.

It is impossible for the current game version. The script can't detect ore unfortunately, and I doubt Keen ever make this happen due to how ore detector block works.

I would like to suggest to include rotor-docking.

Reason for that is that on multiplayer server connectors at times make problems when more than 2 grids are connected via connectors to each other. Rotors have other issues, but with careful docking procedures those at least could be avoided while avoiding those problems of connectors is only to be solved by avoiding them alltogether. This might ofcause depend on server configuration, but even if so, having additional flexibility can't hurt.

Thank you for this suggestion. It is reasonable, but no promises that I would implement it in the near future, because I have to consider the amount of code the feature takes with the value it adds. The script is near the 100K limit after minifier, unfortunately. I totally agree that flexibility won't hurt, but as this isn't a couple lines of code change, I don't see it being more important than other features I have planned to stuff in. I'll add it to the list of features to consider.

I did not know that connectors cause such problems in MP. I'll check again, maybe with some refactoring adding rotor-dock support won't take up too much space.

Would you consider making the un-minified source available? I'm curious about interacting with apck at the API level, and just curious in general

Yeah, I'll do that at some point, when the architecture would be more finalized. I'm reworking it a lot at the moment and most related scripts would be updated with breaking changes.