Thanks for feedback. Using different symbols for different things is on my agenda but I have to map the IDs of the multiple cockpit/generator/thruster/etc. types to a corresponding symbol which is cumbersome. The idea comes from Space Engineers where you have very sophisticated damage monitoring scripts like this one: https://steamcommunity.com/sharedfiles/filedetails/?id=716048498
That look's awesome. I actually own SE but haven't fire it up in years, didn't realise it had programable blocks in it now or anything like that. I think the last time I played it the blockset was about the same as EGS, but there were little control panels with 4 buttons that could be linked to different things per button for airlocks and such. Will have to go back and check it out if they now have actual programming implemented. Definitely looks more advanced than what we have here given the limitations of the API that ASTIC has to work with Setting up all the ids I agree would be cumbersome. Perhaps once persistent data is implemented you can keep it off to a separate file that's just used for various configs/setup, but even so you'd still need to manually write an entry per ID or fuzzy match on names (which are rarely consistent in game anyway) Putting aside the 'Damage' aspect of it, if you were aiming to do a floorplan type display like that SE one you could possibly use the {{getcolor}} / {{gettexture}} and look at the top of each block. Paint/texture all the walkable areas within a BA/CV and your display would be able to pick up any hollow areas for the next layer up - even if the colour itself was barely any different (e.g if you had 'white' floors using #FEFEFE in the colour picker - looks the same but has a unique value that can be detected), then combining with the next y-level up to fill in walls/devices would produce a 'map' type display like the SE one.
The thing with SE is that, while you can build incredible contraptions with automation and all stuff (there are i.e. guided missile systems where the missiles are build with blocks and they have a scripted guidance system), all this is of little use, as the world is basically dead and so there is no real use for all your cool stuff. The scripting in SE is also a PITA as the scripting API is allmoest open-heart C# stuff with a complex class hierarchy and the editing as allmost as basic as in the Empyrion LCDs. Therefore, Visual Studio is used for this by most scripters but this also adds to the complexity. ASTICs approach with handlebars is brilliant in my opinion as this makes the scripting very accessible with little effort. Is the "top" of a block in Empyrion always the same, or does it change with rotation?
That is a very good question that I can't answer, I've not really touched on the colour/texture options yet so that would definetly be the first question. I suppose if you were using a unique colour(s) for 'Walkable areas' you and the 'top' of a block is relative to it's rotation you'd need an extra step of looping all the possible sides and if any of them match your "I can stand here" colour you assume the block above is 'empty', regardless of if it is the 'top' of a block or not. Not an insurmountable problem but worth knowing The only point I played with the colour/texture options was to try and make a "stealth mode" for an SV - same kind of principle, having a 'unique' colour for any outside armor of the ship such as very slightly off-white that I wasn't using anywhere else, then changing all of that colour to a different unique colour (e.g. 1 point off black) or back to it's original colour. The main difficulty I hit was looping every block at once as there is no equivalent to 'for' in handlebars as there is in C# I did have a quick skim over the SE workshop and saw a few of the examples you mentioned, it does look like the programming is both more powerful and a lot more complicated which is a bit of a double edge sword. I agree I like ASTICs approach with handlebars keeping it reasonably simple but with enough access to do (almost) everything you can do with a more open language. I actually find the main things i'm missing are the more 'basic' constructs rather rather than more bespoke functionality (most of which is limited by the API anyway), a lot of which you've already mentioned - global variables, for/while iterators, shorthand variables, array functionality (which we now have) etc. I do keep meaning to pick up the C# scripts to move on from handlebars at some point - most of my background is in high level languages like PHP or older "classic" languages, C, Pascal, Delphi etc. I'd never come across handlebars until now so started with teaching myself that before ASTIC added the option to use C# directly by which point I already had dozens of half finished scripts that I said i'd complete first - and just end up starting more Admittedly part of the appeal for me with this mod over SE was that no one was really using it when I first looked - like all programmers I'm lazy so if it was like SE where every script you could think of had already been done, and likely better than I could have done while learning it, I'd most likely have just used that rather than writing from scratch. Having essentially a blank slate where I get an idea for a script and no one has done it yet then pushes me to work it out and learn enough to put those ideas together, which is a lot of fun in itself. On the other hand, it's also great now other players like yourself are putting their own ideas and scripts out there, and having people to bounce ideas/problems off of
How would I retrieve this information / those values? Asking for myself and probably alot others who are not so deep into coding Also, does that resemble the actual ship design? If so, just WOW!!!
You can retrieve the values by typing di in the console (ö key on german keyboard). Then you can point on a block and get its coordinates. And yes, that are the actual designs of the Dart/Titan (the stock blueprint ones). It is not the whole ship but one of the vertical layers. The script iterates through the layers in a 1sec intervall and shows them. You only have to configure the dimensions (and it works only with admin cores or after modifying the permissions of the scripting mod at the moment but hopefully ASTIC will permit the persistence stuff for normal player scripts). It might also be necessary to change the font size/spacing.
Scripts like the floor plan are very interesting. I will see that I provide an infrastructure that makes such scripts easily scalable so that they do not overload the server (this is one of the main problems of scripts in SE)
Sure, modify it as you like. As for the persisted data: there should be a separate version for player scripts that only persists per entity and not globally. Also, I might support you on developing the scripting mod, if you like.
An update on my damage monitoring script: I am working on a v2 version that has automatic bounding box calculation has memorization of blocks (damage will be detected even if a block was completely destroyed) has config mode for re-memorization if a structure was changed after the last memorization is density based. It will no longer iterate through the layer but will display a ghosty shape for one side (top, side, front) of the ship. If two sides are displayed (i.e. top and side) damge will be exactly locatable. will show if a shield is installed on the ship and if it is powered up (idea: as an penataxid colored outline around the ships shape) can set a "condition red" signal to automatically power up shield/weapons (I have to check if this is doable) of the structure takes any damage What gives me some headache at the moment is, that I am not sure if this is feasible is the first place because of the performace. Especialy the bounding box calculation takes quite some time. Maybe there is some room for optimazation within the mod (@ASTIC offered to look int this). A cool thing would be if the position of players within a structure would be available. This would allow to show the players postions in the plan. Update: This is how it currently looks like (MS Titan again): Structure bounding box calulcation is already working as it the top/side/front-projection. Also the densitiy is already calculated and I am currently working on how to transform the density to a useful gradient so that the internal structure (walls etc.) is better visible.
I reached the maximum character count for the lcd screens with my script and cannot go on... Update: I worked around this by using an additional screen (splitting scripts for initialization and output).
Yep, maybe of you and other players ask in the forums for a better script block (maybe a modified computer deco console) without limitations - the devs noticed it and implement such tiny little thing.
I made such a suggestion already. For now, I will obfuscate my code a bit to conserve characters. I hate that.
I feel your pain, it feels like almost every script I write ends up hitting the character limit and ends up having to be chopped down. I need to do some more testing on it, but I believe the screen itself can hold more characters and its the in-game editor itself that blocks you from entering more. I think it was possible to have multiple 'install' scripts and then an installer that merges them together while bypassing the editors limits. I just did an extremely quick test of the concept (its in handlebars and I know you're using C#, but hopefully the same concept applies) Code: {{~devices @root.E.S 'Script:Install1'}} {{setblock 'text'}} {{@root.data.text}} {{gettext ../0}} {{#if .}} {{.}} {{else}} {{set 'abort' 1}} {{/if}} {{/gettext}} {{/setblock}} {{/devices}} {{~devices @root.E.S 'Script:Install2'}} {{setblock 'text'}} {{@root.data.text}} {{gettext ../0}} {{#if .}} {{.}} {{else}} {{set 'abort' 1}} {{/if}} {{/gettext}} {{/setblock}} {{/devices}} {{#if @root.data.abort}} Install script missing {{else}} {{split @root.ScriptId '/'}} {{set 'self' .1}} {{~devices @root.E.S @root.data.self}} {{settextblock .0}} {{@root.data.text}} {{/settextblock}} {{/devices}} {{/split}} {{/if}} So this goes as the 'installer', and reads from 2 source LCDs then rebuilds itself with the merged code - once its built the 2 source screens can be removed, but opening the merged LCD will cut off anything past the content limit and re-save itself, so you cant open the script-screen in game without it breaking. I've tried it with some basic handlebars scripts and it seems to work, as all of the code ends up in 1 screen theres no problem with variables passing between them etc, it functions as a single long script that bypasses the normal limit. I've tested with 2 screens at about ~2,500 chars worth of gibberish and the resulting 5,000 char script seems to run ok, but probably needs more testing first. This would likely need some cleaning up / error handling before it's usable - it's literally thrown together in 5 minutes as I'd had the idea for a while and someone else having the same problem I always hit prompted me to try it @ASTIC I've asked for a computer / higher limit text block several times as well, so the suggestion is out there and just have to hope someone is listening. If we got that as well as some more flexibility in the API I'm sure some very impressive scripts would come out of the community given what people have accomplished already
You are certainly right with this. Otherwise the floor plans of the Titan would not fit into the screen with all the formatting tags. I am now using two scripts to work around this: One that initializes the monitoring for a structure and one that does the output, but this is quite inconvenient. Why the heck does Eleon put so many artificial limits into this game?
I came to that realisation in the same way - I think it was the fuel graph script where I had it outputting ~100 bar graphs, so opening the output screen would suddenly cut the display in half where it only saved 2,000 or so characters, but when the content is added via script it works fine. A 2nd script for doing the necessary calculations and one for the main display was going to be my alternate suggestion for you, but you beat me to it already. I really have no idea why the screens have an artificial limit on them - if they literally couldn't save any more text no matter the method I'd have said it was a database limitation and the endpoint the content saves to can't hold any more, but that is demonstrably false, and the limit is in the editor itself. I'm actually loathe to point it out to the developers as I think it's just as likely they patch the loophole for storing text over the limit, as they are to just increase the limit. In the name of 'performance' of course
I have contact @Hummel-o-War directly and hope he can offer a solution for this. May be a computer block or a tab in the control panel...
This would be the best solution as it fits best into the current other machanics (like signals). It would be cool if you could manage here: List of available scripts Triggers, Intervall, Activation Mode Somehow like this (hastily mockup, by no way well thought): Means to set scripttype or to define where to output text are missing here...
Love it! For my 2 cents worth, I don't think the 'Activiation' parameters are particularly needed given we can read signals within the script itself, which allows greater freedom to have only specific parts of a script running - see @Sephrajin's scripts for refueling etc where the display is constant but the action is dependent on a signal (extending the API so we can read ALL tx signals rather than just those from the control panel or a physical switch would be helpful with that - allow reading the named result of an AND or OR). You could possibly have a generic 'Run' / 'Pause' per script instead for debugging, but the use cases for that would be limited given the script itself can just reference a switch. Including in that middle panel with an 'Output' field like you say would be useful, maybe as a dropdown/select list of available LCDs and projectors on the current structure. I'd also include a 'debug' pane that gives you the output of the current script (same as the resulting LCD) to save having to close and run off to find the screen you've output to when debugging errors. I think at this point we're unlikely to get anything too complicated with the devs gearing up for release, much less anything with a dedicated interface that only works with a mod installed (though I'd support it being part of the base game 1000%), best case scenario they export the ability to add new CP tabs to modders and some very clever people like ASTIC can create this interface themselves, but I think the devs are unlikely to do it . I'd quite happily settle for the text limit being removed from LCDs as a minimum requirement, with a variant of the current LCD that allows for multiple text fields (with or without display, e.g. a computer block that just shows the current editor screen with tabs for multiple inputs) as a nice to have bonus. Hell, just exposing the character-limit in the config files so we can change it ourselves would be enough to get us started.
Yeah, but I want to be able to execute a (not yet running) script when a signal is emitted (maybe only once every time a signal fires). What you say needs an already running script in which to do decisions on signals (this should also be possible). Event based (me) vs. polling (you).
