Someone opened a discussion topic asking a question about whether it's possible to convert a ship to a station and vice versa using this. I don't think it is but I don't know for sure. Here's the topic:
https://steamhost.cn/steamcommunity_com/workshop/filedetails/discussion/694296356/591773365282308220/?tscn=1749219135

@FantazeR
You're welcome :)

im using this script for over a year now and i love it, ty for you work <3

ymmd. Thank you so much :)

@Kethor
Use the "Number of" to reference the number of blocks with a specific name that are present. check the variable to see if it doesn't = 0 and then do your logic.

See the guide for how to use "Number of"

Hey Coren, I got another challenge. If a ships connector is connected, is it somehow possible to check what connector you are connected to or to see if a block exists?
I want to run a programable block on another grid, but that of course only works if EA can find the block. I can’t find anything in the actions or properties that could help me here. I even tried reading the text of an lcd panel (MMasters Automatic LCDs has a docked command) but that didn’t work. It would already be enough if your script would just continue a code block when a run command cannot be executed. Any ideas? I take every workaround you got :)

@miked9999
is the ownership on all the blocks the same? Programmable blocks can not affect other blocks if they have a different ownership.

Hi Coren and Jack Schitt. My apologies I should have read the 'Variables" section better .

Yeah I created a second LCD called "output_LCD", copied all the code to that as well , executed "debug LCD(Lower_Drill) and still no text on output_LCD.

The guide does say "debug LCD" and to output properties and actions it works.

@miked9999
If you want to write to a screen, it should not be to the Debug LCD. The Debug LCD is for looking at block properties and actions or for receiving errors if your code fails.

It would be good to use another lcd that is not named debug LCD.

Variables in EA aren't really variables, they are references.
Please see the variables section of the guide to understand how they work in EA.
you need to define them in the Variables Codeblock, EA does not understand setting variables outside this Codeblock.

Hi miked9999,
Everything with EA is case sensitive. Is the physical LCD you want to clear named "debug LCD"?
It is "debug_LCD" by default. The underscore is missing.

Hi Coren, I'm having problems here and I don't know why. I have a code block that retracts a vertical piston, the intention being it lowers a drill to the ground to start drilling. This code block calls another code block "Lower drill" . After having major problems making anything write variables to the debug LCD screen, I made "Lower_Drill" as simple as possible to see if it would execute at all. It does not and I don't know why. Here's the code;
...

Retract SRM_Piston_Drill_V1

*Start SRM_Drill_Lower_Timer
Run Lower_Drill
}

@Lower_Drill{
Clear debug LCD
Write to debug LCD = "Starting Lower_Drill code block"

*CurrentPosition = Current position of SRM_Piston_Drill_V1
*WriteNew to debug LCD = "Current position of SRM_Piston_Drill_V1 is \CurrentPosition"

}

The LCD will not clear, and "Starting Lower_Drill code block" text will not appear on the debug LCD screen

Any help is greatly appreciated :)

Coren is there a way to sum up the charged amount of a group of batteries or will it just return the first block of things? in general i supposed that could go for tanks and other things as well with the amount they are filled.

@Kethor
If you are already checking the power state of the merge block and the only time the merge block doesn't have a Status in the detailed info is when the merge block doesn't have power, then you are almost there. Just check for Status within your logic that checks for power. This way it will only check for status when status is present/the merge block is powered...

Unless that is what you are already doing and I just didn't get the full picture. :)

The Merge Block needs to be powered on to have something shown in the detailed section. The messages I can get are: Satus: Merged. and Status: Idle.
It's ok if it doesn't work. Just wanted to check if the problem is between the ears :p
I use a workaround now by checking the power state of the merge block. Not that accurate but it does job. Thanks for responding so quickly even after years of publishing the script. Really appreciate it.

@Kethor
hmm, you probably aren't doing anything wrong. Merge Blocks can be tricky because they take 2 grids and turn them into one and during that merge some funky stuff can happen with programs that are running during the merge.

Also the part that says "Status: Merged." may not always be present in the detailed info of the merge block and if you are checking it when there is no "Status:" present then it will throw this error.

Is there any time where it says something like "Status: Not Merged" or does it just disappear?

Yes, I know it's in the guide. I've read it a couple of times. That's why I ask here because it doesn't work, I think. The Detailed Info of the merge block says exactly Status: Merged.
I tried it with capital letters at the beginning. Also with the dot at the end. Unfortuatenly I always get the message: Small Merge Block does not have a "Status" value
So what am I doing wrong?

@Kethor
At the bottom of the "Who's who of what you can do" section of the guide, you can find info on how EA2 deals with grabbing info from the "detailed info" section of the K Menu.

EA2 is not set up to grab info from this field if it is not in the correct format of
"name of value: value"

Hey Coren, first of all, again big thank you for this awesome script. I literally run everything with this in SE. Hope you will also be on SE2, once the workshop is active :)

Now my question: Is there a way to read the Special Merge Block properties like you can do with a connecter? I can see in the K Menu the status (Idle or Merged) but your script says the Merge Block doesn`t have such value.

Looking for something like this:

@Merge Block{
if status of Merge Block = merged
{
do something
}
}

Thanks in advance

@Syngathar
I would avoid this type of thing for code that runs every frame though because writing strings can get expensive when done rapidly.

if it is a "one and done" like this example, it is no problem.

@Syngathar
Try to use names that do not have operators like the minus sign in them "-" they may cause problems. Don't know if this is the case here but it's just a good practice.

Variables are not set up to hold references to blocks, just references to values that blocks contain. So trying to swap blocks around with EA variables is not possible...

Not Directly at least.

if you want to use Dynamic Variables as well as mess around with code that writes new code as it runs, you could try this.

On DroneLCD

@Variables{
Projector = "ProjectorS01" *1
}

@Activate{
CustomWriteNew of DroneLCD2 = "
@Activate2{
OnOff \Projector
}"

@DroneLCD2(Activate2)
}

Then have a second LCD Named DroneLCD2 that the code in the DroneLCD is writing to and running. When you run DroneLCD(Activate("ProjectorS02")) the new code that is written will be for the block named ProjectorS02.

Back with a new question, I did a lot of trial and error, but cant seem to work out my issues. I have 4 buttons, each one is set to S01, S02 etc.

In the variables, I am trying to select which Projector I want turned on, each is named Projector - S01 etc..

I have tried S01 = S01 thinking the *1 only does the last word
I have tried S01 = Projector - S01 in case the *1 does everything after the toggle on

in all cases when I do the line

Drone LCD(Activate(S01)) I get an error saying (Drone LCD(Activate(S01)$1) is not valid.

I have also tried it with the *, S01 and S01, * in the activator.

So 4 Variables, 4 buttons and 4 Projectors. Any help would be greatly appreciated

I am sure its something simple I am missing, but after staring at it for this long, figured best to ask :)

@Coren Hey i couldnt remember but i know i had a few issues before with this. was there an issue comparing a time value to "Time to trigger" in a timer block? for some reason ive been having problems. that as well as another problem i cant seem to figure out but it may be mod related. i was trying to compare "Required Input" from the detailed info to a specific amount. problem doesnt seem to be the coed tho. it instead returns the "Max Required Input" value. not sure if there is really a way to fix that but it basically makes what i was trying to do improbable and not really a good work around.

@Coren Thanks for the clarification. I have it all working perfectly now, and I think the problems was actually a bug within SE, rather than with the script. I was trying to reset, and recompile the Programmable Block, but it wasn't working (as in having no effect.) I now believe that was because I was accessing the PB from another component. When I went to and accessed the physical PB with the EA2 script running, I ran the Reset argument, and it worked as expected. Now the looped script is working on a separate PB.

@Desert Ice
Yes, if you want a Codeblock to repeat, it is a good idea to have it on a separate programmable block. When you have a looping Codeblock it is also a good idea to give it a condition to continue looping. That way if you have it loop if a light is on, you just need to turn the light off and the Codeblock will stop looping.

If you have a Codeblock that is looping infinitely without a stop condition, then you will need to recompile the programmable block to get it to stop.

Hi, I was hoping you could advise me regarding the function of EA2 where other programs are running, or where the Codeblock is running a repeating code. I have created an elevator that is using the AAECS elevator script, and I wanted to have a rotating light that would turn on while the elevator is moving and turn off once it reaches a floor. I achieved what I wanted by making the Codeblock repeating, but from your instructions, I see that the other Codeblocks I have in the script will not work now, because the rotating lights Codeblock is on repeat? I felt that the obvious solution would be to install EA2 on a second programmable block and run it from there. When I did that, I found that the rotating lights Codeblock was still running on the first EA2 programmable block! How can I stop it doing that, and then just run it from the second programmable block? Is that possible and will it stop interfering with the activation of the other Codeblocks? Should I be doing something else?

Update:
Took out the variables and used direct reference to properties
Removed sub commands and placed their code in the main command blocks
Works now.

I wrote script to allow a single LCD screen to page through different systems. It works either periodically via a timer or manually via buttons. I tested the script as a pile of spaghetti code and it worked. But when I rewrote structured it tells me I'm missing an of in an if or when statement. After a couple of hours I decided to call for help. I'm going to try and attach the script.

Nope too long. what is the best way to show you? Google doc?

I want to make a query to see if this script solves my problem, I have a cabin with four screens and I want the information on each screen to change with the button corresponding to each screen, on screen number 1 I want the application to change, for example, from the time to the level of Oxygen and Hydrogen, on the third screen I want the personalized data to change, that is, if line 1 says Surface3 = Cargo, change it to Surface3 = Weight without modifying line 2, which belongs to another script that controls screen 4.

Coren I could use your help here soon with implementing this script.
Trying to make a "strandbeest" type walker and I need the powered rotors to stay synced together in a way.

Hi,
Why can't I have access for example to the property "JumpDistanceMeters" of a jump drive ?
As I can understand the code, properties and actions are limited to those in ITerminalProperty ? If yes, why ?
LKS

Another thing that should be useful, instead of:
if ...
{
<dosomething>
}
else if ...
{
<dothesame>
}
why not to have:
if ...
or if ...
{
<dosomething>
}

to avoid that ton of {}
thus, also:
and if ...

LKS

Thus to have a more consistent syntax I suggest:
<@mycomponent> @mycodeblock <args>...
In absence of @mycomponent, the default is the component where the code resides itself
- this should apply also (same syntax thus) to the run argument again for more consitency
- also and very important for me: IF the PB running EA2 has a default argument it executes that argument AT START ... no need to trigger it thru a sensor or whatever ... this is requiered to have some EA2 scripts that work in loop AND start without any external action when the game launches
LKS

Just few ideas ...
- real variables that can be modified, tested etc
- a more consistent syntax fe:
Color of <mylight> = <mycolor>
(aka variables recognized in any place in a statement)
- a more consistent way to put comments:
*something (with no space) can cause troubles you have to put a space ... why ?
and also you cannot write:
something ... *this is a comment
- a better way to pass arguments to code blocks like this:
@mycode{
something *1 = something *2
}
that you can call with:
@mycode <arg1> <arg2>
(instead of having to prefix with the @blockcontainingthecode( stuff ...)
- so change the * in something else for comments or arguments to avoid confusion

Not sure how much larger this could get and still run in SE :-)

@Coren ... do you think about a v3.0 ?
I"ve a ton of improvement proposals ;)
Ok, forget about that ;)
LKS

@Coren that's what I'm doing with FontSize but yes you can use other specific components values ;)
LKS

@LukeStrike
If you want to store numbers you can use the values in blocks as storage, Like the brightness of a light. Then you just use that value to set other values as you like

Example:

@Variables{
Value = Brightness of StorageLight
}

@StoreValue{
Brightness of StorageLight = 100
}

@SetRotor{
Rotation of MyRotor = Value
}

This is also described at the end of the Variables section of the steam guide.

@Coren THANKS !!! :)
I've splited my code between 2 PBs and now it "compiles"
I already had those 2 PBs, the first one running EA2 in loop and the second one responsible of single commands so I transfered a part of the second one code who was crashing into the first one lets says as a "library" ... so each code is now +/-300 lines and does not crash.
I must say that the possibility to store code in anything that has a custom data is GREAT ! That means that you can have a huge code stored everywhere (lcds but also and why not in gyrocopes ?) ... infinite libraries/databanks, I like that :)
LKS

@Code Digits & @Jack Schitt
Nope, "variables" are in reality CONSTANTS ... you cannot use them to store something.
Ex:
@Variables{
#ColorHunting = 64:106:128
}
I can use #ColorHunting everywhere in my code (so I can easily change it in its declaration) but I cannot set it to another value (snirf)
For "storing values" the only way I've found at this moment is to use the FontSize of anything having at least one display panel.
Ex:
@Variables{
#StateHunting = 0.1
#StateWarning = 0.2
}
...
If FontSize of VY Programmable [XVY] = #StateHunting
{
@_doWarning
FontSize of VY Programmable [XVY] = #StateWarning
}
LKS

@Code Digits: Variables may be what you're looking for. We can also store full codeblocks either in the same block the code looks for or in another block's custom data and run them from another script (codeblock) by simply calling it with @ or running it with or without an argument .

Hey, i'm just learning the script but something that would be really helpful is the ability to store data for later, i know in going through the documentation there's no storage, could the custom data location on the programming block be leveraged as a long term storage?

@LukeStrike
As for the Script color issue I would need to create a special case for it as it does not seem to be covered under the catch all method that EA uses provide access to functionality which Space Engineers provides.

@LukeStrike
You may be able to avoid the "script too complex" issue by splitting some of your code onto other screens and having the original script run those as per the "Referencing other code blocks" section of the guide. This should split the load of compiling your code into different game frames so it does not try to do it all at once.

@LukeStrike
The compiler I wrote for EA is probably running into the instruction limit when attempting to parse your EA Code due to your code being long. I wrote EA before they implemented the instruction limit on scripts and didn't account for the PB parsing out the compiling between game frames. So an infrastructure designed to save processing during run time runs into problems with the initial load when preparing to run in the beginning when the script is to large.

@Coren just a small *résumé*:
Accessing those values is not a problem BUT when changing them (on a multiscreen device) ...
Works:
FontSize of PB = #StateFSize01
Does nothing:
FontColor of PB = #StateColor01
BackgroundColor of PB = #StateColor01
Provoque parsing error:
ScriptForegroundColor of PB = #StateColor01
ScriptBackgroundColor of PB = #StateColor01
LKS

@Coren +/- 450 lines because there is a TON of lines just for if else else if ... (thus many {})
LKS

@LukeStrike
how large is your script?

@Coren new: I've an error "script too complex" ... I've changed maxInstructions then recompile but got the same error :/
LKS

@Coren for any obcure reason I cannot set the ScriptForegroundColor/ScriptBackgroundColor of f.e a PB ... I can get the value and even write it (a little bit tricky but it works) but any kind of syntax I've tried to set it provoque a parsing error :/
I's like to use that for storing some kind of "state" if possible ?
LKS

Add: It should be very nice to have that kind of control *per screen* on any multiscreen device ...
LKS