I have an idea, and it kinda defeats the purpose, via oversimplification, but it is why we have GUIs now instead of PCs that run solely on DOS. Anyway, you can have the receiving script translate the incoming code and display the translation on another screen. It could tell the observer that [Gerfaso] has (landed at PAM), or (is flying), etc... You get the point. Take an incoming frequency and break down the code to tell the observer what is occurring. Also, for the whole "2 ships overlapping codes" you could also just add a queue system, so if another code is received within X ticks after receiving a code, it is queued and "accepted" after the first code has run. It's how real life Operating Systems handle overlapping incoming data.
For the codes, I wish I could queue them but since its using the action relays and those work only via "pings", there is no way for the receiver to differentiate which ship is sending those pings. The only way to queue a code is to tell the ship to hold off sending it until the "channel" is clear.
@@AndrewmanGaming In my work we deal with alarm panels that transmit via standards, typically SIA or ContactID and the codes they transmit inclue an account number, a condition, and possibly comments. This system is really neat to me and I think I might consider using a simple dictionary of event codes, not unlike HTTP responses either. I'm most of the way through this episode, can't wait to see what happens in the next.
@@AndrewmanGaming Then when the channel is "active", couldn't you just have requests queued up by the program, and then start sending signals from the queue? (Maybe with a random delay, or a manually set delay for each Relay Station to prevent overlap out of the queue?)
3 months late but maybe cool for a future system: you can greatly expand this idea by also using bit fields / bit masks! You essentially make predefined code-numbers (that do stuff) that are the power of two, then you can combine those into a single number that contains many pieces of data being sent/received at once! Example: 1: Alarms on 2: Alarms off 4: Sirens on 8: Sirens off 16: Weapons on 32: Weapons off ... etc ... Then you can send for example "21" (1+4+16) to turn alarms sirens and weapons on, or "17" (1+16) for alarms and weapons on (but no change to sirens) or "42" (2+8+32) for alarms sirens and weapons off, "10" (2+8) for alarms and sirens off (no change to weapons), etc etc On the receiving end you simply go through the same list but in reverse, using the above example, 32 was the highest number, so you check "can i subtract 32 from the number i received without going below 0? okay then i need to turn weapons off!", followed by "can i subtract 16? then turn weapons on!" etc etc all the way back to 1 And then you could always make it even wilder by combining this with what you have, you could use bit fields / bit masks to "select multiple things" but then send another separate number to define what all those selected things should do, so for example you just have 1: Alarms 2: Sirens 4: Weapons And then the second number is just 0 for off or 1 for on, so sending "7 1" turns everything on and sending "5 0" turns alarms and weapons off I might've lost you already at this point hehe, but maybe i didn't and you'll try something like this, would love to see it in one of your future videos! TH-cam needs more "builder game channels" that are not afraid to dive into the programming "gates" a bit, i get why you don't show the trial and error of getting it together & working (i have that too lol) but still love that you include it & show off some code, keep it up! 👍
So lets say that hypothetically a cult started with the full financial, scientific and political support of every country on Earth with the single goal of creating a kaiju, how best would we accomplish goal? Rules: The creature must be, at least, semi aquatic. The creature must become, feasibly, at least 5 times its species average size and must be larger than a full grown adult man by the time it is that size. The creature must be capable of killing an adult human. The methods used in the creation of the kaiju must be feasibly developed with current technology. The process to male the kuiju must be completed before a hundred theoretical years are up. My proposal: I propose that the best candidate for kuijuification would be the lobster. Specifically the eropean lobster Homarus gammarus for two reasons. It is already a long lived species that we have been farming for centuries meaning we know almost every disease and condition it may develop. The second is that loom pretty cool, which is important for a kaiju. Now we have our new god, how do we make them a kaiju? We'll step one is the tank. We will need a massive pool so that little Orthox the destroyer can have plenty of room to run around it, so we re-purpose the NASA Nutral Buoyancy Labrotory as Orthax's new home. We PH and salt balance the water, as well as set the temp just right and plop him(because male lobsters grow larger) in! Now we have a lobster in a pool. Worrying but not terrifying. So step two, growth hormones. In the wild Eropean lobster grow about one pound a year, so for Orthax to get to the mighty size we need it would take TO DAMN LONG. We need our God sooner than a century so we are going to stack some growth hormones in his diet. Now normally these might double the size growth of a lobster but those are usually limited in order to ensure the taste remains pleasant, well we aren't eating our god so we could easily add two to three pounds a year! Great, he is now growing like crazy... new issue, he is melting like crazy. More than a normal lobster would. Not the bighest deal but we will have divers around him at all times to ensure his molts are complete as any leftover shell material could cause shellrot or a host of many other horrible diseases. Now we reach the bigger issue, bigness. Bigness is a huge issue in biology, just imagine how much air it takes just to sustain you, amd yiur lungs are active, imagine having passive stack lungs like a lobster. Thankfully we chose a lobster as god and a good thing too. Because lobsters are weirdly okay with their insides being exposed. Now we can't just go cutting holes in Orthax, that won't work. But several surgeries in order to put microscopic tubing through his body in order to facilitate oxygen exchange is more than within our capabilities, scale up the amount of oxygen as he grows and we are golden. We will hit a O2 limit at some point, probably around 30-40%, but he will be plenty big by the time we do that. Finally the last process is keeping Orthax young for as long as he lives, and I do mean young for his life. Unlike most animals lobsters continously emit telomerase well into adulthood. This helps repair the ends of DNA strands, onenof the only signs of aging in a lobster. Now we can't inject it into humans to become immortal sadly... however if we too adult, or young depending on Orthax's mood, lobsters and squeezed the youth juice from them we could easily incorporate it into Orthax, effectively making him immortal. ... Immortal to a point. Look, I'm no marine biologist, just a cult member of the church of Orthox. There are a million things that could go wrong and probably would eventually. At the end of all this we are left with, given we start with an average lobster after 100 years we a lobster that is around 30ft long from head to tail. A true monster of the deep, and I feel worthy of the title of Kuiju. If he could move under his own weight... still of you got in his claw he could crush you hard enough to cause internal bleeding, so fits the requirements!
You could also add one more Relay to receive a "halt" or "end receiving" signal, instead of it having a time period in which it receives. Or, have a "Dot" signal, where you can send a full address code, and then a "Dot", to register a separate "action code" so you don't have to cannibalize the first 2-3 digits of your code as the identifier. Another suggestion- have the program not allow sending signals while another program is sending signals. ie, you're sending signals from a minor, and when the programs receive the first digit, receiving that first digit stops any other craft from sending a signal- might even be able to set up a buffer/queue system, with a random delay between the end of the last signal, and the start of another program being able to send a signal, so you don't get an issue of two ships trying to send a signal at exactly the same time after 'queuing'. Also- could prefab using blueprints and welders "Relay Cores"- ie, a collection of small-grid timer blocks, programmable blocks, and (either one action relay if you just want a simple "transmitter" system, or the full digit system +1 if you want a full "Transceiver" setup so you can both send and receive action codes) attached to a Rotor Head that you can then simply slot onto other ships, so you don't have to set up all the digit action relays and everything for another ship, or copy over the program onto the programmable block, and instead just focus on setting up the timer blocks.
Ive always wanted to leard how to write scripts for se. Even simple ones like you've done for the solar towers and watching you be able to write a code that identifies ships and their status blows my mind. Great video btw
You can absolutely do it! There are a few good tutorials out there that can get you started on for instance writing to an LCD or opening a door via script. Once you can do that, you can go from there!
hey buddy, if you google examples of C# while loops, if statements, functions for the main part, understanding how data is stored in integers, aka numbers, floats aka decimal numbers and strings eg anydata199, Once you get an idea for that you will realize all a program or script is just asking if condition is true or false and or if another condition is true or false and do x else do y many times, I haven't played around with the scripting system in SE so i dont know what kind of limitations on syntax if any it would have but you can do it, look up free code camp on youtube they got some excellent material which i wished was around when i was learning
@AndrewmanGaming So lets say that hypothetically a cult started with the full financial, scientific and political support of every country on Earth with the single goal of creating a kaiju, how best would we accomplish goal? Rules: The creature must be, at least, semi aquatic. The creature must become, feasibly, at least 5 times its species average size and must be larger than a full grown adult man by the time it is that size. The creature must be capable of killing an adult human. The methods used in the creation of the kaiju must be feasibly developed with current technology. The process to male the kuiju must be completed before a hundred theoretical years are up. My proposal: I propose that the best candidate for kuijuification would be the lobster. Specifically the eropean lobster Homarus gammarus for two reasons. It is already a long lived species that we have been farming for centuries meaning we know almost every disease and condition it may develop. The second is that loom pretty cool, which is important for a kaiju. Now we have our new god, how do we make them a kaiju? We'll step one is the tank. We will need a massive pool so that little Orthox the destroyer can have plenty of room to run around it, so we re-purpose the NASA Nutral Buoyancy Labrotory as Orthax's new home. We PH and salt balance the water, as well as set the temp just right and plop him(because male lobsters grow larger) in! Now we have a lobster in a pool. Worrying but not terrifying. So step two, growth hormones. In the wild Eropean lobster grow about one pound a year, so for Orthax to get to the mighty size we need it would take TO DAMN LONG. We need our God sooner than a century so we are going to stack some growth hormones in his diet. Now normally these might double the size growth of a lobster but those are usually limited in order to ensure the taste remains pleasant, well we aren't eating our god so we could easily add two to three pounds a year! Great, he is now growing like crazy... new issue, he is melting like crazy. More than a normal lobster would. Not the bighest deal but we will have divers around him at all times to ensure his molts are complete as any leftover shell material could cause shellrot or a host of many other horrible diseases. Now we reach the bigger issue, bigness. Bigness is a huge issue in biology, just imagine how much air it takes just to sustain you, amd yiur lungs are active, imagine having passive stack lungs like a lobster. Thankfully we chose a lobster as god and a good thing too. Because lobsters are weirdly okay with their insides being exposed. Now we can't just go cutting holes in Orthax, that won't work. But several surgeries in order to put microscopic tubing through his body in order to facilitate oxygen exchange is more than within our capabilities, scale up the amount of oxygen as he grows and we are golden. We will hit a O2 limit at some point, probably around 30-40%, but he will be plenty big by the time we do that. Finally the last process is keeping Orthax young for as long as he lives, and I do mean young for his life. Unlike most animals lobsters continously emit telomerase well into adulthood. This helps repair the ends of DNA strands, onenof the only signs of aging in a lobster. Now we can't inject it into humans to become immortal sadly... however if we too adult, or young depending on Orthax's mood, lobsters and squeezed the youth juice from them we could easily incorporate it into Orthax, effectively making him immortal. ... Immortal to a point. Look, I'm no marine biologist, just a cult member of the church of Orthox. There are a million things that could go wrong and probably would eventually. At the end of all this we are left with, given we start with an average lobster after 100 years we a lobster that is around 30ft long from head to tail. A true monster of the deep, and I feel worthy of the title of Kuiju. If he could move under his own weight... still of you got in his claw he could crush you hard enough to cause internal bleeding, so fits the requirements!
Wow... This 6-digits system is truly awesome. That a really great way to increase the number of codes. Maybe I'll learn one day to write scripts (and the SE scenario tool).
In reference to the @DizzyDJW comment and @AndrewmanGaming reply, I'm guessing that "overlapping signals" would only be an occasional issue since the drones aren't doing the exact same things, at the exact same distances, and waiting the exact same time to load/offload/recharge. The likelihood of them sending signals at the same time would be rare. Having separate screens for each mining drone and displaying their last signal sent would make it easier to see what each is up to without having to wait for their next signal to send if you didn't see it. If you can configure a scrolling text screen that displays the last X number of signals received, it could all be on one big LCD. If you ever set up patrol drones, just 1 screen for monitoring their signals would probably be enough, if you chose to monitor them. Having a display for each base/outpost (moon or asteroid) to monitor if they run low on power, get attacked, have full cargo capacity, etc, would be a nice addition to this signaling system you've designed. Here's an idea to mull over. Would it be possible to send signals to the drone?, In other words, over-ride their programming remotely as if you had pressed the physical buttons to go to PAM or back to BASE? If under attack, you could remotely tell them to return to Main Base, or wait at PAM til a "resume" signal is sent, etc.
just a thought, if an outpost broadcasts that it is full.... it can do so, so if you set each outpost to broadcast on say channel 1 "cargo collection needed" for example that should only broadcast that particular request for that outpost... example is outpost 1 = Iron outpost 2 = uranium outpost 3 = ice outpost 4 = gold each on channel 1, but they will only broadcast the request IF they met the requirements that was needed to trigger the signal then Channel 100 for - "under attack, requesting support" not sure if the receiving block will be able to switch though or if you'd need a new signal block per channel request intended to receive but having a timed broadcast for whichever is broadcasting and have them do so in a different colour might help also have a set of lights in each of your main areas which has a different LCD or Light to indicate whether it's a distress signal, or a logistics request
I love the light idea as visual indicators! For base requests, I think I could handle that with my current code system. If I give the base an ID code (like "200" for PAM base), and then assign a status code for requests (like "3") and use the other two digits to indicate the type of request ("01" for iron ore, "02" silicon, etc), I could get away with making those requests with just my normal codes. With that, "200301" would mean "PAM base requests iron ore". I think it could work!
Would you be able to condense the ship side timers to use less by using the hot bars in the timer blocks? Timers do the actions in sequential order from slot 1-9 in each hot bar before chasing hot bars. So you could use 6 different hot bars to send the signals. That way you would only need 1 timer for each status
Thats pretty clever, ur a pretty clever dude huh, my brain turned to jelly watching u with the timer blocks, got flash backs on things ive tried to do in the past, like ahh yeah i only need 3 more of em, oh wait 4, oh wait 6... awesome result tho, program blocks are so powerful if u actually know coding
Hahahaha Ikr timer blocks are like that. Take the number of timers you think you'll need for a project and double it. Then double that again and you might be in the ball park for the number you'll need!
It might be interesting if you put a window on the back wall of the top floor of the control roon looking into the ice. Maybe with a bit of lighting behind it to catch the ice in a blue light or something really lean into the underground glacial look. I usually do underground windows looking onto rock ever since mass effect 1 gave me the idea. But I've never tried it in an ice base before
I really need to. I bought a decent battery but it's not meant to be a UPS so I need to go back to the drawing board on that one. That would be awesome to not have to worry about power outages though!
The messaging relay stuff you coded looks like your custom assembler code with a message bus and microcode. Maybe watching videos of @BenEater - especially his series about a 8bit breadboard computer - will help you understand better what you want to do.
Perhaps reduce your code to 2 digits - Ship 00-99, Status (00-99) Location (00-99) Then do ship codes Starting 00-09 As combat SHips, 10-19 Drillers, 20-29 Haulers. Status 00 (Stopped), 10 (Moving), 20 (Charging). Location gives you 99 locations (Main Base, Docking Bays, Orbitals, Outposts...). Now, if you could have the LCD be able to have translated the codes to text you could see (Gerfaso Moving PAM) .....Later on the Ship ID in the program does that have to be numeric or can it be text? ShipID="Gervaso" ? For control consoles could you have 1 per cargo hauler showing status and cargo onboard.? Same for base/refinery container storages.
This is awesome! Given the number of ships involved and distances involved I would think risk of overlapping signals would be very small. What would you think of using a portion of the first three digits to designate bases (maybe 900xxx-999xxx), maybe attack alerts for example?
That's a great idea! I could do the first digit as the "home" base designation of the ship or even the build location. Then the next two as the ID. Finally the last three digits are the status with the first being the actual status code and the other two being extra info (like the base ID that it's flying to). If I make more than 9 bases, all I need to do is expand the code to have an extra digit!
A git repo is a good way to share code/resources. You can version scripts so we can see history, etc. Send me a message if you want to chat about that idea. Happy to demo and talk through it if you're not familiar with Git
Things break! I'm not thinking that's gonna be a big issue right now as they would have to send the messages within the same like 7 "ticks" but if it happens, either the control room just wouldn't recognize the incoming code or the jumbled message from the two ships would trick the control into thinking some other code was occurring. If it actually becomes a problem, I do have a few possible solutions I could implement. The easiest would probably be a "busy" signal that gets sent out whenever a ship tries to transmit while the receiver is in use. That would allow the sending ship to hold on to it's message and just try again in a second or two. Option two would be setting up another set of action relays ranging from 80-89. Then if the receiver is in use, it still sends back that busy signal, but the ships can then try to transmit on the backup frequency (80-89). For now though, it's probably fine, and I'll cross that bridge if I come to it!
@@AndrewmanGaming An elegant way would be to send a transmission request (REQ) code, and the base PB replies with an ACK code if it's currently free to receive, at which point it will ignore all other REQ codes until it's processed the current message. The senders are set up to wait for either an ACK, or timeout and retry. This would allow for a large number of transmitters to be processed seamlessly.
Oh, Idea. Once you get a functional small grid module working why don't you bluprint it. Then, every new ship you wanna include the system on the only set up is changing the values and outputs of the timer blocks.
Overcomplicated is the name of the game in SE, but seriously 1000 digits how many ships are you expecting at your base? I think lower antenna range could let you get by with the hundred signals. Also event controller when connector is connected will do a lot. Event control on base activating action on ship might even do it all.
Will this be later used for a multiplayer journey later on? If so, I can't wait to see that and how you all plan to play it together and make it a series.
The reason I think it gets stuck is the final waypoint, you didn't set this back up I bet. You can see you fixed it last ep for PAM side but didnt do base side. th-cam.com/video/tybwHhQULCI/w-d-xo.html
I wish you'd do a 1 or 2 episode of how to do programming in se. The 2 ways I found was 1, stuff depreciated. and 2 ways too complicated to set up and does work and so old... both so old tbh. The one I tried years ago does not work anymore. and for me it would be worth a patronship
Idea publish the script to the workshop so that others can use it and that way you wont have to struggle with youtube and the software you use for scripts
Hi, I am having issues on building a ship like yours that uses AI blocks to move in earthlike planet. Its speed doesn't go higher than 5 m/s even seting the maximum speed to 100m/s does anyone have any clue what might be ? Also your videos are great! I really enjoy watching them.
![Space Engineers Survival (Episode 28) - Automatic Drone Status Displayed! [2024]](http://i.ytimg.com/vi/2DVGpl8-eJo/mqdefault.jpg)
![Space Engineers Survival (Episode 28) - Automatic Drone Status Displayed! [2024]](/img/tr.png)
![Space Engineers Survival (Episode 30) - Automatic Transport Ship! [2024]](http://i.ytimg.com/vi/EJF0HGtxq2U/mqdefault.jpg)
Man, your ad lib singing riffs are so hilarious! They always crack me up. You should put together a super clip of all of them!
I have an idea, and it kinda defeats the purpose, via oversimplification, but it is why we have GUIs now instead of PCs that run solely on DOS.
Anyway, you can have the receiving script translate the incoming code and display the translation on another screen.
It could tell the observer that [Gerfaso] has (landed at PAM), or (is flying), etc... You get the point. Take an incoming frequency and break down the code to tell the observer what is occurring.
Also, for the whole "2 ships overlapping codes" you could also just add a queue system, so if another code is received within X ticks after receiving a code, it is queued and "accepted" after the first code has run. It's how real life Operating Systems handle overlapping incoming data.
Great idea!! I just finished recording the first half of the next episode and I think you'll like what we end up doing :)
For the codes, I wish I could queue them but since its using the action relays and those work only via "pings", there is no way for the receiver to differentiate which ship is sending those pings. The only way to queue a code is to tell the ship to hold off sending it until the "channel" is clear.
yeah or we could emulate an 8bit serial but i dunno how SE will deal with that
@@AndrewmanGaming In my work we deal with alarm panels that transmit via standards, typically SIA or ContactID and the codes they transmit inclue an account number, a condition, and possibly comments. This system is really neat to me and I think I might consider using a simple dictionary of event codes, not unlike HTTP responses either. I'm most of the way through this episode, can't wait to see what happens in the next.
@@AndrewmanGaming Then when the channel is "active", couldn't you just have requests queued up by the program, and then start sending signals from the queue? (Maybe with a random delay, or a manually set delay for each Relay Station to prevent overlap out of the queue?)
3 months late but maybe cool for a future system: you can greatly expand this idea by also using bit fields / bit masks!
You essentially make predefined code-numbers (that do stuff) that are the power of two, then you can combine those into a single number that contains many pieces of data being sent/received at once!
Example:
1: Alarms on
2: Alarms off
4: Sirens on
8: Sirens off
16: Weapons on
32: Weapons off
... etc ...
Then you can send for example "21" (1+4+16) to turn alarms sirens and weapons on, or "17" (1+16) for alarms and weapons on (but no change to sirens) or "42" (2+8+32) for alarms sirens and weapons off, "10" (2+8) for alarms and sirens off (no change to weapons), etc etc
On the receiving end you simply go through the same list but in reverse, using the above example, 32 was the highest number, so you check "can i subtract 32 from the number i received without going below 0? okay then i need to turn weapons off!", followed by "can i subtract 16? then turn weapons on!" etc etc all the way back to 1
And then you could always make it even wilder by combining this with what you have, you could use bit fields / bit masks to "select multiple things" but then send another separate number to define what all those selected things should do, so for example you just have
1: Alarms
2: Sirens
4: Weapons
And then the second number is just 0 for off or 1 for on, so sending "7 1" turns everything on and sending "5 0" turns alarms and weapons off
I might've lost you already at this point hehe, but maybe i didn't and you'll try something like this, would love to see it in one of your future videos! TH-cam needs more "builder game channels" that are not afraid to dive into the programming "gates" a bit, i get why you don't show the trial and error of getting it together & working (i have that too lol) but still love that you include it & show off some code, keep it up! 👍
I come for the SE gameplay, and stay for the bangin' tunes.
🛡 Spoiler Shield 🛡
So lets say that hypothetically a cult started with the full financial, scientific and political support of every country on Earth with the single goal of creating a kaiju, how best would we accomplish goal?
Rules:
The creature must be, at least, semi aquatic.
The creature must become, feasibly, at least 5 times its species average size and must be larger than a full grown adult man by the time it is that size.
The creature must be capable of killing an adult human.
The methods used in the creation of the kaiju must be feasibly developed with current technology.
The process to male the kuiju must be completed before a hundred theoretical years are up.
My proposal:
I propose that the best candidate for kuijuification would be the lobster. Specifically the eropean lobster Homarus gammarus for two reasons. It is already a long lived species that we have been farming for centuries meaning we know almost every disease and condition it may develop. The second is that loom pretty cool, which is important for a kaiju.
Now we have our new god, how do we make them a kaiju? We'll step one is the tank. We will need a massive pool so that little Orthox the destroyer can have plenty of room to run around it, so we re-purpose the NASA Nutral Buoyancy Labrotory as Orthax's new home. We PH and salt balance the water, as well as set the temp just right and plop him(because male lobsters grow larger) in!
Now we have a lobster in a pool. Worrying but not terrifying. So step two, growth hormones. In the wild Eropean lobster grow about one pound a year, so for Orthax to get to the mighty size we need it would take TO DAMN LONG. We need our God sooner than a century so we are going to stack some growth hormones in his diet. Now normally these might double the size growth of a lobster but those are usually limited in order to ensure the taste remains pleasant, well we aren't eating our god so we could easily add two to three pounds a year!
Great, he is now growing like crazy... new issue, he is melting like crazy. More than a normal lobster would. Not the bighest deal but we will have divers around him at all times to ensure his molts are complete as any leftover shell material could cause shellrot or a host of many other horrible diseases.
Now we reach the bigger issue, bigness. Bigness is a huge issue in biology, just imagine how much air it takes just to sustain you, amd yiur lungs are active, imagine having passive stack lungs like a lobster. Thankfully we chose a lobster as god and a good thing too. Because lobsters are weirdly okay with their insides being exposed. Now we can't just go cutting holes in Orthax, that won't work. But several surgeries in order to put microscopic tubing through his body in order to facilitate oxygen exchange is more than within our capabilities, scale up the amount of oxygen as he grows and we are golden. We will hit a O2 limit at some point, probably around 30-40%, but he will be plenty big by the time we do that.
Finally the last process is keeping Orthax young for as long as he lives, and I do mean young for his life. Unlike most animals lobsters continously emit telomerase well into adulthood. This helps repair the ends of DNA strands, onenof the only signs of aging in a lobster. Now we can't inject it into humans to become immortal sadly... however if we too adult, or young depending on Orthax's mood, lobsters and squeezed the youth juice from them we could easily incorporate it into Orthax, effectively making him immortal.
... Immortal to a point. Look, I'm no marine biologist, just a cult member of the church of Orthox. There are a million things that could go wrong and probably would eventually. At the end of all this we are left with, given we start with an average lobster after 100 years we a lobster that is around 30ft long from head to tail. A true monster of the deep, and I feel worthy of the title of Kuiju. If he could move under his own weight... still of you got in his claw he could crush you hard enough to cause internal bleeding, so fits the requirements!
You could also add one more Relay to receive a "halt" or "end receiving" signal, instead of it having a time period in which it receives. Or, have a "Dot" signal, where you can send a full address code, and then a "Dot", to register a separate "action code" so you don't have to cannibalize the first 2-3 digits of your code as the identifier.
Another suggestion- have the program not allow sending signals while another program is sending signals. ie, you're sending signals from a minor, and when the programs receive the first digit, receiving that first digit stops any other craft from sending a signal- might even be able to set up a buffer/queue system, with a random delay between the end of the last signal, and the start of another program being able to send a signal, so you don't get an issue of two ships trying to send a signal at exactly the same time after 'queuing'.
Also- could prefab using blueprints and welders "Relay Cores"- ie, a collection of small-grid timer blocks, programmable blocks, and (either one action relay if you just want a simple "transmitter" system, or the full digit system +1 if you want a full "Transceiver" setup so you can both send and receive action codes) attached to a Rotor Head that you can then simply slot onto other ships, so you don't have to set up all the digit action relays and everything for another ship, or copy over the program onto the programmable block, and instead just focus on setting up the timer blocks.
Ive always wanted to leard how to write scripts for se. Even simple ones like you've done for the solar towers and watching you be able to write a code that identifies ships and their status blows my mind.
Great video btw
You can absolutely do it! There are a few good tutorials out there that can get you started on for instance writing to an LCD or opening a door via script. Once you can do that, you can go from there!
hey buddy, if you google examples of C# while loops, if statements, functions for the main part, understanding how data is stored in integers, aka numbers, floats aka decimal numbers and strings eg anydata199, Once you get an idea for that you will realize all a program or script is just asking if condition is true or false and or if another condition is true or false and do x else do y many times, I haven't played around with the scripting system in SE so i dont know what kind of limitations on syntax if any it would have but you can do it, look up free code camp on youtube they got some excellent material which i wished was around when i was learning
Hey, finally learned how signals work. Making your way up the tech tree I see.
Yessss, but "Klang drives" still scare me.
@AndrewmanGaming So lets say that hypothetically a cult started with the full financial, scientific and political support of every country on Earth with the single goal of creating a kaiju, how best would we accomplish goal?
Rules:
The creature must be, at least, semi aquatic.
The creature must become, feasibly, at least 5 times its species average size and must be larger than a full grown adult man by the time it is that size.
The creature must be capable of killing an adult human.
The methods used in the creation of the kaiju must be feasibly developed with current technology.
The process to male the kuiju must be completed before a hundred theoretical years are up.
My proposal:
I propose that the best candidate for kuijuification would be the lobster. Specifically the eropean lobster Homarus gammarus for two reasons. It is already a long lived species that we have been farming for centuries meaning we know almost every disease and condition it may develop. The second is that loom pretty cool, which is important for a kaiju.
Now we have our new god, how do we make them a kaiju? We'll step one is the tank. We will need a massive pool so that little Orthox the destroyer can have plenty of room to run around it, so we re-purpose the NASA Nutral Buoyancy Labrotory as Orthax's new home. We PH and salt balance the water, as well as set the temp just right and plop him(because male lobsters grow larger) in!
Now we have a lobster in a pool. Worrying but not terrifying. So step two, growth hormones. In the wild Eropean lobster grow about one pound a year, so for Orthax to get to the mighty size we need it would take TO DAMN LONG. We need our God sooner than a century so we are going to stack some growth hormones in his diet. Now normally these might double the size growth of a lobster but those are usually limited in order to ensure the taste remains pleasant, well we aren't eating our god so we could easily add two to three pounds a year!
Great, he is now growing like crazy... new issue, he is melting like crazy. More than a normal lobster would. Not the bighest deal but we will have divers around him at all times to ensure his molts are complete as any leftover shell material could cause shellrot or a host of many other horrible diseases.
Now we reach the bigger issue, bigness. Bigness is a huge issue in biology, just imagine how much air it takes just to sustain you, amd yiur lungs are active, imagine having passive stack lungs like a lobster. Thankfully we chose a lobster as god and a good thing too. Because lobsters are weirdly okay with their insides being exposed. Now we can't just go cutting holes in Orthax, that won't work. But several surgeries in order to put microscopic tubing through his body in order to facilitate oxygen exchange is more than within our capabilities, scale up the amount of oxygen as he grows and we are golden. We will hit a O2 limit at some point, probably around 30-40%, but he will be plenty big by the time we do that.
Finally the last process is keeping Orthax young for as long as he lives, and I do mean young for his life. Unlike most animals lobsters continously emit telomerase well into adulthood. This helps repair the ends of DNA strands, onenof the only signs of aging in a lobster. Now we can't inject it into humans to become immortal sadly... however if we too adult, or young depending on Orthax's mood, lobsters and squeezed the youth juice from them we could easily incorporate it into Orthax, effectively making him immortal.
... Immortal to a point. Look, I'm no marine biologist, just a cult member of the church of Orthox. There are a million things that could go wrong and probably would eventually. At the end of all this we are left with, given we start with an average lobster after 100 years we a lobster that is around 30ft long from head to tail. A true monster of the deep, and I feel worthy of the title of Kuiju. If he could move under his own weight... still of you got in his claw he could crush you hard enough to cause internal bleeding, so fits the requirements!
Wow... This 6-digits system is truly awesome. That a really great way to increase the number of codes. Maybe I'll learn one day to write scripts (and the SE scenario tool).
In reference to the @DizzyDJW comment and @AndrewmanGaming reply, I'm guessing that "overlapping signals" would only be an occasional issue since the drones aren't doing the exact same things, at the exact same distances, and waiting the exact same time to load/offload/recharge. The likelihood of them sending signals at the same time would be rare.
Having separate screens for each mining drone and displaying their last signal sent would make it easier to see what each is up to without having to wait for their next signal to send if you didn't see it.
If you can configure a scrolling text screen that displays the last X number of signals received, it could all be on one big LCD.
If you ever set up patrol drones, just 1 screen for monitoring their signals would probably be enough, if you chose to monitor them.
Having a display for each base/outpost (moon or asteroid) to monitor if they run low on power, get attacked, have full cargo capacity, etc, would be a nice addition to this signaling system you've designed.
Here's an idea to mull over.
Would it be possible to send signals to the drone?,
In other words, over-ride their programming remotely as if you had pressed the physical buttons to go to PAM or back to BASE?
If under attack, you could remotely tell them to return to Main Base, or wait at PAM til a "resume" signal is sent, etc.
that relay system is very impressive!
"if it pressurizes the planet for me...", your dad should have felt a disturbance when you said that.
Is his dad a Jedi?
just a thought,
if an outpost broadcasts that it is full.... it can do so, so if you set each outpost to broadcast on say channel 1 "cargo collection needed" for example that should only broadcast that particular request for that outpost...
example is
outpost 1 = Iron
outpost 2 = uranium
outpost 3 = ice
outpost 4 = gold
each on channel 1, but they will only broadcast the request IF they met the requirements that was needed to trigger the signal
then Channel 100 for - "under attack, requesting support"
not sure if the receiving block will be able to switch though or if you'd need a new signal block per channel request intended to receive but having a timed broadcast for whichever is broadcasting and have them do so in a different colour might help
also have a set of lights in each of your main areas which has a different LCD or Light to indicate whether it's a distress signal, or a logistics request
I love the light idea as visual indicators! For base requests, I think I could handle that with my current code system. If I give the base an ID code (like "200" for PAM base), and then assign a status code for requests (like "3") and use the other two digits to indicate the type of request ("01" for iron ore, "02" silicon, etc), I could get away with making those requests with just my normal codes.
With that, "200301" would mean "PAM base requests iron ore".
I think it could work!
@@AndrewmanGaming would definitely make it work just gotta remember what code means what when things get intense
Not long started a fresh map of Space Engineers! Some great inspiration in the series
4 Non Blondes concert in Space Engineers - WHEN? 🤪🤯
Would you be able to condense the ship side timers to use less by using the hot bars in the timer blocks? Timers do the actions in sequential order from slot 1-9 in each hot bar before chasing hot bars. So you could use 6 different hot bars to send the signals. That way you would only need 1 timer for each status
Thats pretty clever, ur a pretty clever dude huh, my brain turned to jelly watching u with the timer blocks, got flash backs on things ive tried to do in the past, like ahh yeah i only need 3 more of em, oh wait 4, oh wait 6... awesome result tho, program blocks are so powerful if u actually know coding
Hahahaha Ikr timer blocks are like that. Take the number of timers you think you'll need for a project and double it. Then double that again and you might be in the ball park for the number you'll need!
It might be interesting if you put a window on the back wall of the top floor of the control roon looking into the ice.
Maybe with a bit of lighting behind it to catch the ice in a blue light or something really lean into the underground glacial look.
I usually do underground windows looking onto rock ever since mass effect 1 gave me the idea. But I've never tried it in an ice base before
Would have been good to have the small hangar directly below the control room and the same size. The relay station could have been part of the hangar
you could also get an backup battery so the power outages don't interfear with your recordings and home
I really need to. I bought a decent battery but it's not meant to be a UPS so I need to go back to the drawing board on that one. That would be awesome to not have to worry about power outages though!
You can upload scripts from SE itself, much like you can with blueprints.
It's why non-coders like me can download them :)
The messaging relay stuff you coded looks like your custom assembler code with a message bus and microcode. Maybe watching videos of @BenEater - especially his series about a 8bit breadboard computer - will help you understand better what you want to do.
UPS ✋
Warfare Battery 👈
Great video, even if I only understood about 1/3 of it
Perhaps reduce your code to 2 digits - Ship 00-99, Status (00-99) Location (00-99) Then do ship codes Starting 00-09 As combat SHips, 10-19 Drillers, 20-29 Haulers. Status 00 (Stopped), 10 (Moving), 20 (Charging). Location gives you 99 locations (Main Base, Docking Bays, Orbitals, Outposts...). Now, if you could have the LCD be able to have translated the codes to text you could see (Gerfaso Moving PAM) .....Later on the Ship ID in the program does that have to be numeric or can it be text? ShipID="Gervaso" ? For control consoles could you have 1 per cargo hauler showing status and cargo onboard.? Same for base/refinery container storages.
You should upgrade the welder ship you have and have it as a MK1 With 4 welders and 2 large cargo containers and more weaponry for its defense
hi good job on the video.
This is awesome! Given the number of ships involved and distances involved I would think risk of overlapping signals would be very small.
What would you think of using a portion of the first three digits to designate bases (maybe 900xxx-999xxx), maybe attack alerts for example?
That's a great idea! I could do the first digit as the "home" base designation of the ship or even the build location. Then the next two as the ID. Finally the last three digits are the status with the first being the actual status code and the other two being extra info (like the base ID that it's flying to). If I make more than 9 bases, all I need to do is expand the code to have an extra digit!
to share the scripts you could poste a pastebin on your discord?!!
You could run the codes on binary, would require more code work but less timers and signals
A git repo is a good way to share code/resources. You can version scripts so we can see history, etc.
Send me a message if you want to chat about that idea. Happy to demo and talk through it if you're not familiar with Git
What happens if two ships send messages at the same time?
Things break! I'm not thinking that's gonna be a big issue right now as they would have to send the messages within the same like 7 "ticks" but if it happens, either the control room just wouldn't recognize the incoming code or the jumbled message from the two ships would trick the control into thinking some other code was occurring. If it actually becomes a problem, I do have a few possible solutions I could implement.
The easiest would probably be a "busy" signal that gets sent out whenever a ship tries to transmit while the receiver is in use. That would allow the sending ship to hold on to it's message and just try again in a second or two.
Option two would be setting up another set of action relays ranging from 80-89. Then if the receiver is in use, it still sends back that busy signal, but the ships can then try to transmit on the backup frequency (80-89).
For now though, it's probably fine, and I'll cross that bridge if I come to it!
@@AndrewmanGaming An elegant way would be to send a transmission request (REQ) code, and the base PB replies with an ACK code if it's currently free to receive, at which point it will ignore all other REQ codes until it's processed the current message. The senders are set up to wait for either an ACK, or timeout and retry. This would allow for a large number of transmitters to be processed seamlessly.
Curious to see how the game handles all this in the background while your off fighting or minning etc. Good work tho!
I hope it can handle it! I guess we'll find out next time we go up to the asteroid base!
Oh, Idea. Once you get a functional small grid module working why don't you bluprint it. Then, every new ship you wanna include the system on the only set up is changing the values and outputs of the timer blocks.
Overcomplicated is the name of the game in SE, but seriously 1000 digits how many ships are you expecting at your base? I think lower antenna range could let you get by with the hundred signals. Also event controller when connector is connected will do a lot. Event control on base activating action on ship might even do it all.
20:03 you want to make a phone in SE
Will this be later used for a multiplayer journey later on? If so, I can't wait to see that and how you all plan to play it together and make it a series.
Please rebuild the transport ship from Pam’s to the main base a large small cargo would mean fewer flights and more materials in the main base
Just wondering what code are you writing these scripts in, C# or Python?
It's in C# using the in game programmable blocks
The reason I think it gets stuck is the final waypoint, you didn't set this back up I bet. You can see you fixed it last ep for PAM side but didnt do base side.
th-cam.com/video/tybwHhQULCI/w-d-xo.html
Not sure if you saw this
I fucking love you!
I wish you'd do a 1 or 2 episode of how to do programming in se. The 2 ways I found was 1, stuff depreciated. and 2 ways too complicated to set up and does work and so old... both so old tbh. The one I tried years ago does not work anymore. and for me it would be worth a patronship
Idea publish the script to the workshop so that others can use it and that way you wont have to struggle with youtube and the software you use for scripts
Try seperating the grid with connectors so that it isnt massive and lagsor breaks the game as seen in the moon bridge vid when the grid got too big
I don't think it's *too* long right now, but if we get major problems, we might do that to separate the solar towers with a connector.
Can you work on the AMG Sandstorm more?
yeah, when are you going to do a vid that's just about the AMG Snowstorm
Hi, I am having issues on building a ship like yours that uses AI blocks to move in earthlike planet. Its speed doesn't go higher than 5 m/s even seting the maximum speed to 100m/s does anyone have any clue what might be ? Also your videos are great! I really enjoy watching them.
Are you using the AI recorder? It could be that your waypoints are too close together and it's crawling from waypoint to waypoint.
Yes I am, but only 3 wayponts after disconnected in a distance of 1km each waypoint
You should try to make missiles to defend against reavers and if you want to send the missiles you have to put a code
Why cant you show the programming
Why are you constantly telling us you are “going to go ahead and” ????