Makes sense, and more options are always welcome. I guess it makes sense for the things you're working on with a one-off "build the config" type examples, that would be useful to trigger once from a switch and then not run again. Ideally to complete the setup you'd need a button device as opposed to a switch that only sends the signal once rather than switch being constantly on, although it's possible to handle with the script polling for a switch-signal and then setting that switch back to 'off' once it's done (and given lag/synchronisation issues in the base game I'm not sure I'd trust the script to have actually run from a button-signal that only lasts a split second) On an unrelated note I was hoping to get your feedback on an idea I've got - as the stuff you're working on is extremely impressive and I'd like to get the opinion of someone also working on complex scripts before I get too far: I've nearly completed the 'Cockpit HUD' system I've been working on recently, which is currently made up of 5 separate screens positioned inside an SV cockpit - and that means having 5 script: LCDs also stashed away somewhere in the ship. I'd been considering using the 'installer' script I threw together yesterday to try and build a single projector that handles all of the code across all 5 cockpit screens - as space is at a premium in an SV and finding space to add 10 projectors is going to be difficult, but hopefully 6 are a little more manageable. It would make any changes/maintenance a lot more difficult overall - you'd need to add in the 5 original 'script' screens with the separate code, then 'reinstall' the master script after making any changes, likewise for the initial setup having to setup multiple screens in an exact order then running a one off script (My hope would be to publish a blueprint in the workshop with just a cockpit and the screens already installed). On the plus side, once it's set up once it shouldn't need any changes, it cuts down the total number of projectors needed for a ship to just the ones needed for display + a single massive script that generates code for all of them, and also reduces the limitation on character limit as even a single script can be spread across multiple inputs. I noted you'd gone a different way with your damage-map script, keeping the 2 scripts you need separate with multiple projectors - obviously a different use-case as i'm working with an SV while you're on a CV so space is less of an issue. I can't quite decide which way I want to go with it and if the pros outweigh the cons of making it more complex for the sake of saving space, so thought i'd go for an outside opinion and to check there are no gaps in my logic that someone else can spot before I start reworking all the code i've got so far
A few questions to verify that I understood you correctly: You use 5 scripts screens + 5 output screens with your current implementation You have developed a script that can compile the contents from multiple screens into one screen with a configurable order You want to use the script from 2. to merge the 5 scripts from 1. into a single script The single script from 3. is able to serve the different information originally provided by the 5 scripts from 1. to the 5 output screens After the merge process described in 3. you can remove the screen containing the merge script which leaves you with a single script screen and the 5 output screens Does this correctly reflect what you have/want to achieve?
Yes that's all correct. 5 Outputs + 5 Scripts, for example "Script:HUD-Topleft", "HUD-Topleft", "Script:BottomRight", "BottomRight" The compiler reads through each "Script:" screen in order, storing their contents to a variable and after the last screen rewrites itself to be the content of all 5 "Script:" screens The compiled contents I can make output to the 5 output screens as before - each individual script uses {{settext}} to output to a preset screen name, rather than using the name of output+script having the same name Once the scripts are compiled into a single screen, all of the input screens are no longer needed So in effect I would place 5 temporary scripts, have them merge into a single script that is capable of outputting to multiple screens at the same time. Something like: Script:Install1 Script:Install2 Script:Install3 Script:HUD-System (outputs) HUD1, HUD2,HUD3 etc After putting all of the individual code blocks in the Install* scripts, add the install script into "Script:HUD-System" which reads each script in turn and then overwrites itself with the merged content. "HUD-System" then outputs to each of the HUD[n] screens from a single source script - but opening that merged script will break the entire system as the game will trim it to fit within the character limit, so it would have to be compiled and then never touched afterwards. The downside is ease of installation - having to setup the 'Install[n]' screens and add the code, then merge them to a single screen, then remove them afterwards. The benefit comes from being able to bypass the character limit for any screen (If my code gets too long I can just add an extra install screen and compile both halves into a single working script) and being able to reduce the number of individual projectors that need to be installed on a ship to give the desired effect. My other consideration was performance, which I know you hit issues with when performing a lot of calculations within a single script. I'm hoping I wont run into this even while running 5 separate screens from a single source as they are all fairly basic information displays and don't need to be updated quickly, but I wont know if its an issue or not until I try it
My main concern with what your approach is the complexity to get it running. Also, the maintainability isn' that great. There are, however, no alternatives to this with current limitations. Regarding performance: for my script the initialization is what costs most here. The bounding box algorithm is brute force at the moment as I scan through 250^3 blocks and check if there is something for a structure. Also, the density calculation is a bit costly. But this only has to be done once.
Die min/Max einer Struktur bekommen wir direkt von der API. Ich würde das am WE einbauen das man das auch aus den Scripten erreichen kann. Ebenso ein Cache Dictionary in denen man Dinge über einen Script Lauf speichern kann. (Cache deswegen weil z.B. bei einem Playfieldwechsel auch der Prozess wechselt und ich das nicht auf Platte o.ä. Speichern möchte)
Inspired by DamageView, I am currently in the process of creating an automatic floor plan more ... comming soon ;-)
A single layer from the position of the LCD display or projector. So another display on a different position show another plan.
Ah, okay. I am working on a density based approach that shows the whole ship in top/side/front view. Rooms become visible there as they have a lower density than walls. The damage monitoring will still be included. I just have not enough time because of family affairs. Usually only a few hours in the evening.
The density calculation is a bit tricky and still needs calibration, but it will look something like this: The blue outline is the plan for the current floor. PS: I really need those additional lines in the LCD or another solution. I increasingly becomes a PITA to write this thing (but it is fun at the same time).
Die "Spielerposition" ist einfach die Position des LCDs für die das generiert wird. Mit den "Stufen" sieht das auch gut aus was du da gemacht hast --- gute Idee!! Eine Menge Zeichen sparst du ein wenn du die Farbe nur setzt wenn diese sich ändert PS: Da ich mit dem Script leider auch schon wieder an die Zeichengenze stoße :-( werde ich das in ein SaveGameScript auslagern.
I've been using this as a temporary workaround to create longer scripts: Code: {{set 'Output' 'Script:HUD-System'}} {{set 'SourceScripts' 'Install1,Install2,Install3,Install4,Install5'}} {{split @root.Data.SourceScripts ","}} {{#each .}} {{~devices @root.E.S .}} {{setblock 'text'}} {{@root.data.text}} {{gettext ../0}} {{#if .}} {{.}} {{/if}} {{/gettext}} {{/setblock}} {{/devices}} {{/each}} {{/split}} {{~devices @root.E.S @root.data.Output}} {{settextblock .0}} {{@root.data.text}} {{/settextblock}} {{/devices}} This outputs the combined contents on Install1 - Install5, in order, to "Script:HUD-System", which then runs as normal. As soon as Script:HUD-System has its contents populated I can remove the other screens (all InstallN and Script:Compiler) and it continues to work. My current test SV I'm up to 12 separate install screens feeding a single script, about 20,000 characters long and haven't hit any problems so far, so it should in theory also work for you and split your script across 2+ LCDs which runs as normal and outputs to the display screen
I think I'll go with savegame scripts as @ASTIC suggested, for now. Cool thing here is that you can write your script I an editor and your screens update when you save the script. If you have two screens (in RL) you can develop your script on one screen and directly see the results on the other one. No copy and paste anymore, yay!
I'm using a combination of the two methods at this point - now I have a way to bypass the char-limit entirely in game I write the majority of the script as a save-game file to avoid too much copy/pasting (and to avoid working with the in-game editor) and then as each section is completed, moving the code 1 2000-char-block at a time into my 'Install' screens which are compiled as a single script in a screen. That way I've got all the benefit of working with save-game-scripts (proper editor, no char limit) but will also be able to use that blueprint in MP or on the workshop where I wouldn't have access to add files to the server.
Forgot to say, both @tachyon and @ASTIC these floor plan/damage scripts look incredible and very impressive
Floorplan (1.0) https://github.com/GitHub-TC/EmpyrionScripting-Collection/blob/master/Scripts/Floorplan-ReadMe.md https://github.com/GitHub-TC/EmpyrionScripting-Collection/blob/master/Scripts/Floorplan.cs Here in my Polaris:
Do you mean it's only showing steel plates + erestrum gel (but missing other materials), or that you've got the list of materials and would instead like to show something else e.g. Ores? If the former then that's likely a bug, might be easiest if you send me a screenshot of what you can see and the code if it's any different to the original. If the latter, the list of items shown is defined by the list of IDs on line 4 Code: {{~set 'IDs' '2265,2295,2255-2264,2267,2282,2283,2286,2290-2292,2326,2327,2309,2329-2333'}} You can probably also use the pre-defined lists that ASTIC added after I'd first published that script - the lists Sephrajin suggested are a few pages back in this thread https://empyriononline.com/threads/mod-ext-empyrion-scripting-scripts.92458/page-4#post-406668 So using a pre-defined list should just be a case of Code: {{~set 'IDs' @root.Ids.Ore}} or if you wanted 2 or more lists Code: {{~set 'IDs' (concat @root.Ids.Ore "," @root.Ids.Ingot)}} (I've not actually tried that in game yet, but in theory that is correct) You can still enter Id numbers manually for a custom list, or using the predefined ones - whatever is fed into that IDs variable is the list of items to be shown including if any are zero, across the entire structure/ship/base. If it still isn't working let me know and I'll see if I can help
