Hi, is it possible to ask for access to the uncompressed version of the code? I would really like to parse it for learning purposes. It might be useful for me in understanding how other people solve similar problems, since I write scripts myself.

Hi Hellbent,

I appreciate your interest in getting into the nuts and bolts of Mother OS. One of the project goals was to provide a scripting framework that made automating the game more approachable for players. When I started scripting in the programmable block, I found there were very limited resources for some of the "simple" use cases. A dependable system clock, structured communications protocols, and a situational awareness for my ships just weren't out there as a baseline. The scripts I was writing/downloading were never consistent in their approach to a "core".

A major constraint is keeping the character count at an absolute minimum (below 100,000). I am trying to fit it together in a way that leaves developers room to grow their wacky ideas, on top of this missing core. Though, I intend to release Mother in the open source format eventually. I have a few more kinks to correct, and dev tools to test. In the meantime, I'm happy to explain how a module works in more detail, and if you think there is info that would be/ should be in the documentation, I would love your input!

Thanks :)

Is there possibility for Mother OS to manage stuff like magnetic plates? I Tend to stabilize subgrids in their default resting spot with them so it's more stable during travel.

Originally posted by Liliathe:

Is there possibility for Mother OS to manage stuff like magnetic plates? I Tend to stabilize subgrids in their default resting spot with them so it's more stable during travel.

I'll happily look into this, and I don't see why not!

Originally posted by Liliathe:

Is there possibility for Mother OS to manage stuff like magnetic plates? I Tend to stabilize subgrids in their default resting spot with them so it's more stable during travel.

Hi Liliathe,

Update 0.2.2 has landing gear (and mag plates) as well as commands for oxygen and hydrogen tanks :) The block/on and block/off commands should let you control their power as well. Enjoy!

It's going to be tricky because of the weird bug in MP, but it would be great if the Mother gave us a feature where we could use a single sound block with multiple different sounds.

Another request is that maybe there is "when" or(and) "if" conditions.

Thanks for this great script.

Originally posted by zayza:

It's going to be tricky because of the weird bug in MP, but it would be great if the Mother gave us a feature where we could use a single sound block with multiple different sounds.

Another request is that maybe there is "when" or(and) "if" conditions.

Thanks for this great script.

Very intriguing! I haven’t gotten to sound blocks yet but perhaps the time is now :)

As for logical operations - I haven’t quite nailed how I want them to work, but it’s something I’m experimenting with and hope to have progress on soon. Another idea I’m playing with is allowing players to set commands based on block-level “callbacks”. For example, a door would have an “OnOpen” and “OnClose” command the player could use to access those events via the block’s CustomData vs. requiring an event block. OnLock, OnDetect, OnStop, etc.

Thanks for your feedback and support!!

Hi, can you add Jump Drives as a manageable block? The current PAM script cannot use Jump drives due to the human confirmation being needed on initiating the jump. If your flight plans could know when to engage a jump drive as an action, what waypoint was the target and overcome the human confirmation required that would allow ships to be automated over far bigger distances. Automated interplanetary hauling!

After reading the documentation and saw the "Upcoming Features" > Autodocking
You could make it work with the SAM V2 autopilot script ? Since its already have this feature

Originally posted by 5UP3R TH30 B4G:

After reading the documentation and saw the "Upcoming Features" > Autodocking
You could make it work with the SAM V2 autopilot script ? Since its already have this feature

I can certainly take a look at the implementation! I’d love to get to a point where you can use a single command to dock with a grid, and have the option to identify a specific connector. Mother can get all of the position info via her communication with other grids. Hoping to make meaningful progress on this soon :)

Originally posted by KraziYeti:

Hi, can you add Jump Drives as a manageable block? The current PAM script cannot use Jump drives due to the human confirmation being needed on initiating the jump. If your flight plans could know when to engage a jump drive as an action, what waypoint was the target and overcome the human confirmation required that would allow ships to be automated over far bigger distances. Automated interplanetary hauling!

Sadly the jump drive can’t be activated by a programmable block. It’s a really unfortunate limitation but was actually a huge inspiration for Mother’s 1.0 test case - a hauler than can go from a to b in space and dock automatically. The compromise is that it will still take 5, 10, 50 hours to fly, but if it’s automated, that desire to go fast goes down. I wish it were an option, but at least the default is a good dose of realism that highlights to opportunity for greater automation tools like Mother.

One thing that many autopilot or automation scripts suffer with in combat settings is correctly implemented formation flight. I glanced over the documentation but i'm unsure if it's possible with Mother OS

Being able to have drones attempt to fly at set (or randomized within a set range) offsets to a 'mothership' (until a combat ai block takes them over) is something that I have been on a quest to find for almost a year, in my many attempts to build a drone-spawning mothership build that works in the current pvp meta.

Existing widely used scripts like AutoPillock either operate very buggily due to shoddy implementation of relative flight systems, especially when you integrate things like gravity drives into them, or don't support them at all and only allow pre-set gps based operation.

---

Seperately, is it possible to use beacons (assuming the beacon is in range) instead of GPS coordinates?

Originally posted by Prince Lumine:

One thing that many autopilot or automation scripts suffer with in combat settings is correctly implemented formation flight. I glanced over the documentation but i'm unsure if it's possible with Mother OS

Being able to have drones attempt to fly at set (or randomized within a set range) offsets to a 'mothership' (until a combat ai block takes them over) is something that I have been on a quest to find for almost a year, in my many attempts to build a drone-spawning mothership build that works in the current pvp meta.

Existing widely used scripts like AutoPillock either operate very buggily due to shoddy implementation of relative flight systems, especially when you integrate things like gravity drives into them, or don't support them at all and only allow pre-set gps based operation.

---

Seperately, is it possible to use beacons (assuming the beacon is in range) instead of GPS coordinates?

Formation flight is very close to my heart as a former aviator! In principle, the auto-docking feature under development would work in a similar way, as Mother allows grids to continuously share data (ie. their current px) and command each other. Under the hood, Mother kinda hacks the remote control block's GPS system - I wish the newer AI blocks could be hacked in a similar way, but so far this isn't possible via scripts. I can look into beacons for sure and I assume this is most interesting to you because of their relative positioning system? Though admittedly, Mother's real time position sharing means it doesn't care if a grid is moving or static.

if you haven't yet, hop on to the Discord server and we can go through this in more detail!

https://discord.gg/PrrmBujmXQ

A specific function for pistons could be added which I believe to be potentially very advantageous as it simplifies the steps and calculation required to perform a task.

In the current state of the script, to make a group of two pistons called "PistonsGroup" extend a total distance of 5 meters with an overall speed of 0.2m/s you need to set the command like this:

This can be inconvenient for complex operations involving many steps because it forces the user to perform the correct calculations each time to achieve the desired effect.
I thought it would be very useful to insert commands based on "relative" values.

To give an example:

If you add commands called "rspeed" and "rdistance" (where "r" stands for relative) and the script applies a distance and speed relative to the number of pistons in the group, you simplify the process a lot because you would only need to enter


I hope I've explained myself decently, thanks anyway for the magnificent work, your script has enormous potential and is one of the best works seen in all the years that I have been following this game!

I understand that this is a game, but it's too bold of you to claim that this script supports security in the form of encryption. I don't mean to be rude, but this can hardly be called encryption :)
In most cases, your algorithm can be broken in less than [Edited. I was a little hasty, but after double-checking the algorithm, I can say for sure that a regular search by key bytes * number of ASCII characters will give a result in about an evening] brute force attempts. Go to sleep knowing that you are no longer safe on any server, HAHAHAHAHA. (I know at least 5 people who won't be too lazy to do this on servers, so I'm rewriting BIgInteger myself so that it can run in the script. The rest of the TLS logic is already ready. I'll be sure to share it and let you know when I'm done. (If you need it)).