You may honestly be better off rewriting the majority of either of those scripts - particularly the Container display one was done before ASTIC very kindly added the ability to look up the volume of an item direct from the config, so has a horrendous workaround of storing all of the volumes separately and then trying to look up each one in turn. It's on my todo list to rewrite using all the new options, which will cut it down from the current huge mess into just a few lines and allow for much better formatting within the current character limits. The same goes for the 'sorter' script - in its current form it seems rather hit and miss when used online, which I think is a symptom of trying to do too much all in 1 go (all the bits about overflow containers etc) and ends up tripping over itself, as it's constantly trying to both read and write from its own config all the time to keep the contents up to date. I'm halfway through a newer version of it that should be much simpler, starting with a 'Reload' script based on one of @Sephrajin's, used on reloading a docked SV. So each SV has it's own screen that on pushing a button does a 1 time log of what is in all of it's containers (and shows that on a screen), and when docking to a CV/BA the parent structure can read out from that config file, removing anything that isn't logged in the config (Seph's 'auto unload') and at the same time refill anything in the config that has less than when it was logged (The auto reload part). Once i've got the display issues worked out on that the next step was to extend it to a generalised sorter system using the same "Push to log config" idea, where 1 screen shows a 'map' of where each item is supposed to go and the 2nd screen shows the actual log of items being moved, which would hopefully entirely replace the old 'Sorting system' script without all the messy code and bugs (I hope!)
That is... extremely weird... Off the top of my head I can't think of anything in that script (or any for that matter) that should be able to impact a server like that. I've used that script a few times in online games, both adding it in to a complete ship and spawning one from a blueprint with it already in place (with at least 3 copies of it for fuel, pent and o2) without any issues. It shouldn't be a case of overloading the server as the scripts only run once per second at most anyway, and in the case of that one it's actually running LESS frequently - when it runs each second "normally" only the first few lines of code are executed unless the current counter is evenly divisible by 120 (so once every 2 min), at which point the rest of the screen runs (and even then only outputs a line of characters) - none of which should have very much load impact. My only thought is the character limit of the screen itself - so normal screen you can't type past 2,000 characters, but if its content is being set by a script you can exceed that limit. In this case, if you had a full "log" where you have 60+ lines each made up of dozens of block characters, plus all the styling/formatting content you end up way past the character limit of what you could enter to the screen 'normally' - but even so, its far from the only script that generates a massive amount of content and I've not had that kind of impact when spawning in a ship in the past (also doesn't make sense that it would only happen on spawning in a blueprint, and only online, if that was the case) I can have a look at the blueprint if you like although I doubt I can offer any more insight than your server admin if they can't see any logs etc. I assume you've already cut down the ship to the bare minimum in order to pinpoint it to that script and it's not part of some huge size class 100 CV - if not might be worth trying a blueprint of the most basic CV possible with just the screens for the script, generator and fuel tank and seeing if it still does it with everything else removed. If it does then that is truly bizarre and I honestly have no idea how it could cause that
It happened with a class 31 CV as well as with a class 4 SV. As a matter of fact, sorry to say, I started by removing those scripts I could live without the best... and those were the first. You cant do anything about it, I just thought I'd share my experience when I spawned it in MP. -> So you could add a 'warning', that if they want to use this script in MP, they should 'apply' it while beeing online, and not save it to the blueprint they want to throw in the MP factory. Again, fun fact is that we added the scripts in MP - Jenago was watching - and it worked well - no hickups even after server restarts. Best I'd come up with would be a kind of 'stack overflow' - like you described, but why that would disconnect everybody from the playfield (just in MP) is beyond my imagination as well. But yes, can do, in about 2 weeks when the servers go on again.. Until then I'll work on my AutoMove-Suite.
I'm not advanced enough to rewrite the scripts yet; my last 'programming' language was BASIC, and not even the visual kind. That said, I was capable enough to change a few names here and there to suit my container naming preferences, and a few numeric values to adjust to my playstyle preferences. I intend at some point to dive further into @ASTIC's documentation and see if I can make more sense of the scripting language. Regarding the sorter script, I did finally manage to get it working. It seems your assumption about the unnamed containers is true in more ways than your one post implied. Not only does the original version not like any unnamed cargo containers (boxes or controllers), it also does not like decoration devices that function as storage, which cannot be renamed via the device panel. If/when you do get around to re-writing the dynamic transfer script, is there any possibility you could also allow it to dump into ammo boxes and fridges (which can be renamed, lol)? I'm actually using @Sephrajin's Auto-Move script in combination with your dynamic transfer; the usage being we (my wife and I play together) have a CV we dock our HV/SV's to as we go from planet to planet. So I simply adjusted the name of the output container in Seph's script to match the input container in the transfer script, and now, we can use our SV/HV's to mine/raid, come back and dock, and have all the loot auto-moved into the CV's storage. Which is a fantastic level of automation, minor implementation caveats aside. I'm also using his Auto-Fill script successfully now, as well as @Ephoie's initally posted Ship Stats (though I assume the damage implementation is no longer working, which is a bummer), and his 'Docked Ships and Passengers', though I broke that into two separate script instances/displays. Oh yeah, also managed to get your 'nearby' Ship List script working and resized, though I did have to play with the formatting a LOT, lol. To everyone who I've mentioned, who's scripts I'm utilizing in my save, thank you so much. These add so much to the base game. And a huge thank you to @ASTIC for making this all possible with his mod. (Now I gotta figure out if I can at least get the passenger mod working in A12, lol, but that'll be another thread/post than this if needed)
So I keep promising to show the new scripts I'm working on and never seem to get around to it, so here's what I've got so far bugs and all This is the start of an integrated HUD system made up of 5 projectors positioned inside an SV cockpit, so you can see (i hope) everything while flying in first-person. What I've got so far Top left: Fuel, O2 and Pentaxid metres. These use a custom setup mimicking what {{bar}} does, but to produce a vertical graph instead of horizontal. Each bar also fades through a gradient of green -> red, although I've added a bit of blue into the mix to make it a touch paler Without the blue added in - cant decide what looks better Middle: Based on one of the designs in Vermillions LCD Archive thread, but adding in active information with scripts. This ones still a work in progress so currently only had shield status (on/off) and the ship name populating in. Eventual plan is to have ammo counters for up to 8 weapons, XYZ coordinates and possibly some "warning" type messages for things like low fuel or a weapon being out of ammo. Top Right: Shows a list of all signals (far right in P menu) and switches stylised the same as the main control panel. I seem to get a bug here where using {{getswitches E.S '*'}} returns duplicates of any levers, whereas searching on an actual name like 'Lever*' only gives a single result. Possibly a bug but needs more investigation before I report it Bottom Right: This script generates a config within itself of the current loadout in each container on the ship, when you change the name of the script to 'Script:Config[set=true]'. Changing it back to 'set=false' then enables the display which reads from a stored config within the screen itself (inside <size=0> tags). Everything is colour coded between 'full', 'partial', 'empty' and 'surplus' based on that initial config. So as you remove items or add in loot the display changes to reflect that. (Health packs are no longer full, detox kit is missing entirely and there are now "loot" pentaxid crystals) Other ships can also read from the same config by looking at the output, so there is a counterpart script for a CV/BA which reads whats missing/extra from this and refills or removes as necessary (with a LOT of bugs currently) Still need to add in the borders on this one, possibly tweak the size a bit as its a little hard to read and a few issues with where newlines are added in sometimes creating a blank row that I just can't find whats causing it Bottom left: Haven't started yet but intending to be basic ship info - passenger/seat info, playfield name+coordinates, maybe a 'Core systems' damage overview or anything else I can think to jam in there. So far this is just where ive got a backup copy of the code im using to generate the borders around other content. So far i've managed to keep everything within the limits of what can be entered to a screen directly and haven't had to resort to using server-side scripts (which would be so much easier), with the eventual goal being to publish to the workshop a very basic SV with just a cockpit and the LCD projectors already positioned and setup with these scripts to use as a starting point to build a ship around So that's where I'm at so far - if anyone's got any ideas for improvement or suggestions for things to add to fill in the gaps let me know and i'll see whats possible. And yes - it does look completely ridiculous from the outside with the screens poking out the top of the canopy - the only way I can get them to fit inside is to be so small that they are completely unreadable. But at least it looks nice-ish from the inside
I am now working on an alternative, more visual apraoch for damage monitoring. Here is a sneak preview of this: It is flipped, because we are looking at the front... I have, however, some issues with the C#-Scripting: Are floating point types not allowed for normal scripts? I get an error message that i have to use savegame scripts if I emplay float/double variables I ran out of memory after the script ran for maybe 15 Minutes
@shadowiviper The stuff you're doing with these LCD's is so cool! Can't wait to see all the finishes results. And if you're asking, I think the one with the blue tinge looks a lot better....less jarring colours.
You could put them to the left and right so that you actually have to turn your head to see all your instruments.
Thanks for the feedback, always appreciated I'm hoping to finish the whole project sometime this week although my game time is often quite sporadic, and I should probably actually start playing A12 at some point as well as soon far i've managed to always get distracted coding every time I log on
I did actually try that initially - having a centre screen and then 2 on the left / 2 on the right. Unfortunately due to the way EGS handles angles, because the side screens are 45 degrees rotated, once you have 2 side by side they no longer line up nicely. The first screen to the left/right lots in quite nicely with the 'flat' centre screen, but the outer screens either clip through the first screen or through the back of the cockpit, so doesn't seem to be any good way to position them. Of course if you do have any better luck positioning the screens you can always share me a blueprint and I can add in the scripts / modify them to fit the right dimensions. For the initial setup I added the 5 LCD projectors around the cockpit and assigned each of them a different background colour (now that we can do that in A12) then nudged their position around until they fit as well as they could, using the different colours as a reference to which screen was moving / how they overlapped / spotting any gaps. Once they were all in position the backgrounds get changed to black and I add in the code to create a border across the whole screen and then start adding the content to the middle. I'll try and come back to this one once I've got all the code complete and fitting with the screens I've already got, and see if there's any room for 'alternate layout' cockpits with the screens in different positions (as the code will probably need to be tweaked if any of the sizes changes, although should at least just be config values within each script I hope)
You could help yourself a bit if you rotate the projectors themselves. But you are right: aligning the screens is a PITA. I also ran into some difficulties with my damagemonitoring stuff. The multi-block-sized components - like HV/SV cockpits - occupy only a single coordinate in the structure... Update: It is even worse. All the coordinetes of a multi-block-sized component have the same Id but only a single coordinate has the correct damage value. All other return 0 damage...
Yea the rotating the screen trick was the one I used for the previous 'Fuel over time' gauge, which I'd initially avoided as there's no way to rotate individual sections of text (when i was planning to include the numeric % alongside the graphic). Making the bars vertical doesn't actually add much overhead to doing them horizontally, most of the code is for the gradient colour schemes - although having them horizontal/rotated would mean it could output each bar one at a time (do all of Fuel, then do all of O2 etc) which would simplify things. If I took out the colours / made them horizontal it would be pretty much the standard bar graphs like in ASTICs original example blueprint, and I wanted to take on something a bit more challenging / outside the norm. That does sound like a pain with your damage monitor, and would certainly be difficult to work around. I've not really done anything with the new C# scripting yet (on my todo list to learn it) so I apologies in advance for my ignorance while I spitball; You've obviously managed a way of looping through all blocks on the ship - I'm presuming like my previous suggestion a 3-way nested 'for' and just cycling every possible XYZ coordinate and outputting to a grid. While it would mean losing the 'graphical' idea of it, you could instead show a list of components plus a general "armor" value - so as you do now loop through every set of coordinates, and if a device is damaged displaying it in a list (maybe sorted by most damaged to the top?). If the block at those coordinates has an ID of one of the structural/armor blocks add its current hitpoints / total hitpoints to a running total and at the end you can show a bar / numbers for general "Armor damage", as well as a list of damaged components. The main downside to doing it that way - which I assume would also apply to your current method - is once a block/device is destroyed it's not going to be picked up at all anymore. So on the first hit your armor rating goes to 4950 / 5000, then on the 2nd hit when the block is destroyed you go to 4900/4900 with the 'total' reducing. You might be able to do something similar to what I'm attempting with the cargo container config - have a "set" mode for the script where it writes out all the values for a 'perfect' ship to a config file, and then rather than looping every block in real time you refer back to your config, pretty much like the in-game 'Save template' works. So when in 'config mode' you output the XYZ + device ID of everything found, and then when you go back to 'normal mode' you work through that list to check for damage. If a set of coordinates that previously had a device returns null you know its been destroyed and can flag it in your output. Same again for 'Total hitpoints' which can be stored as a one-off and then you only need a running tally of current hitpoints', knowing the total wont be changing. Wouldn't be as nice as your current graphical overview - but as you said trying to create a 'map' of a ship when dealing with multi-block devices means that isn't particularly feasible without ending up with gaps/duplicates
I reported this as a bug now. The Id is correctly returned for the whole cockpit while the damage is only returned correctly for the coordinate shown in the debug info. I want to go the visual approach, as having a visual damage monitor would be really helpful to be able to find all the damaged blocks when no repair bay is available...
Yea that makes sense and the visual method would be a lot more useful assuming they fix the bug with the API (good luck!). I assume the ID you're getting back is the generic block id rather than something for that specific instance, e.g. all 'Thurster M' show id 1234 rather than each having their own ID so it's not even like you could store the damage of a specific ID somewhere, and then any 'empty' spaces which also return that ID could read from that as a fail over. If the id is just for the block type you then end up in a complete mess of checking on ID AND checking for nearby blocks which when you're looking in 3 dimensions is going to get complicated. Was still an awesome idea tho and hopefully something you can get working eventually
Yes exactly as you say, it is the generic id, unfortunately. And there is also no other mean for identifying the instance. That is not ASTICs fault. The ModAPI itself does not provide it.
Just a little mini script I've been playing around with - take the contents of a screen and display it with a border around the edge. Code: {{~set 'target' 'CargoConfig'}} {{~set 'top' 46}} {{~set 'right' 93}} {{~set 'height' 43}} {{~set 'margin' 4}} {{~set 'fontsize' 4}} {{~set 'l' '<line-height=0.53em><cspace=-0.1em><size=5>'}} {{~set 'E' (concat '</pos>' @root.data.l '<pos=' @root.data.right '>║</pos> <pos=0>║</pos></size></cspace></line-height><pos=' @root.data.margin '>')}} {{~devices @root.E.S @root.data.target}} {{gettext .0}} {{[email protected]}}╔{{~bar 1 0 1 @root.data.top '═'}}╗</size></cspace> <size=5><pos=0>║</pos></size><size={{@root.data.fontsize}}>{{~split . "\n"}} {{~#test (calc .Length '*' 2) geq @root.data.height}} {{~#scroll @root.data.height 1}}{{~#each .}}{{~.}}{{@root.Data.E~}}{{@root.Data.E~}}{{@root.Data.E~}}{{/each}}{{/scroll}} {{~else}} {{~#each .}}{{~.}}{{@root.Data.E~}}{{@root.Data.E~}}{{@root.Data.E~}}{{/each}} {{~/test}}{{/split}}</size> {{~/gettext}} {{~/devices}} {{@root.data.E~}} {{@root.data.E~}} {{[email protected]}}<pos={{@root.data.right}}>║</pos> ╚{{~bar 1 0 1 @root.data.top '═'}}╝ I've only used it in a couple of instances so far so no guarantees it will work in all cases, and will likely need refining before it will work with any output but putting it out there so if anyone does use it I can see how/if it works. Depending on the size of the screen you'll probably need to tweak the initial settings to nudge the borders around, but should be easy enough to configure. By default the borders are the 'double line' variant with the correct corner pieces, and use the default colour of the screen. Any sizes/positioning/colours in the targer screen should be unaffected but any unclosed tags may spill through to the borders e.g. if you open a <color> tag and don't close it the borders will be affected once it hits that line. Example screenshot - the screen on the left is pulling the content from the right (which is in turn generated by a script) and displaying it with a border
An update for the damage monitoring: Setup: LCD Input Name: C#MGMon LCD Output Name: DMGMon LCD Dimensions: >=0.5x0.5 Last Updated: 2020/07/24/23:42 (be carefull with those persistent data as it shared for all entities) LCD Input Script: Code: //<noparse> //set xmin and xmax dimensions here int xmin = -20, xmax = 20; //set ymin and ymax dimensions here int ymin = 123, ymax = 140; //set zmin and zmax dimensions here int zmin = -70, zmax = 12; var pd = GetPersistendData(); var dictKey = $"{E.Id}.dmg.y_layer"; int y = (int)pd.GetOrAdd(dictKey, ymax); Console.WriteLine($"<size=120%>Damage Top (Layer {ymax - y})"); Console.Write("<mspace=3.8m><size=50%>"); Console.Write("<line-height=70%>"); if(y > ymax) y = ymax; if(y < ymin) y = ymax; for(int x = xmin; x <= xmax; ++x) { for(int z = zmin; z <= zmax; ++z) { var b = CsRoot.Block(E.S, x,y,z); if(b.Id == 0) { Console.Write(" "); } else { int hp = b.HitPoints; var dmg = b.Damage; var col="<color=green>"; if(dmg > 0){col = "<color=yellow>";} if(dmg > (hp/2)){col = "<color=#552200>";} if(dmg > (hp*9/10)){col = "<color=red>";} Console.Write(col); Console.Write("■"); } } Console.WriteLine(); } pd[dictKey]=y-1; //</noparse> Set [xmin,xmax], [ymin,ymax] and [zmin,zmax] according to your structure. The script cycles through the vertical layers and show the damage in each of them. This needs an admin core to be used as the GetPersistendData method requires this (can be modified within DefaultCsCompilerConfiguration.json of the Mod enable this for players alternativly). It is still ugly but I am doing the scripting stuff only for 4 days, now. Still more a proof-of-concept as there is still the issue that the damage of multi-block-sized components is only returned correctly for a single coordinate. I used the "Blue Dart" blueprint to test this... @ASTIC: I tried to utilize object.GetHashCode() to find out if blocks of a multi-block-sized component belong together (I had to permit it in DefaultCsCompilerConfiguration.json) but the IBlockData instances are generated on the fly, everytime CSRoot.Block() is called and so the values do not help. Maybe it is possible to forward the HashCodes of the IBlock implementation instances from the ModAPI. Also it would be nice if the update rate could be modified to some degree. The layers of the Dart (with projectors attached): Here one layer of the MS Titan after using a plasma rifle...
Very impressive and I think it's looking great. Random thought - could you define specific IDs to use a different symbol than the full square? So keep the colour coding as is, but the square where you have a generator is shown as a "⚡", or the ones for cockpit being the blocked circle instead of a square. As long as you know what it was roughly meant to represent, it would help to orient you as to where in the ship you're looking, front/back/left/right etc if you can see that this section is the cocking, this bit is a thruster etc In terms of design, making the green a little darker or possibly more transparent would help the yellow stand out. At the zoom level in your screenshots it's easy enough to see but looks like it may get a bit washed out when glancing over the screen at a distance
