space engineers lcd panel no panels found quotation
Unfortunately there is not enough space in description of the steam workshop page to fit full guide. Well.. there was, but thanks to your suggestions I added more commands and more cool stuff and it doesn"t fit there anymore. So I made this ultimate guide to answer all your questions! ;-)
This guide will give you full insight into how to use all the features of Automatic LCDs 2. You will find out what are the commands, what are the arguments of the commands and how to use them. It also contains full list of all commands with detailed description along with examples of use.
What is block?Block is every machine, button, cockpit, everything on your ship that is accessible through control panel. Armors are not blocks. Script only works with blocks.
Note: When you subscribe to this you will not see it in the list of mods in game, because it is not a mod. It is in-game script that works in vanilla game without any mods. So don"t worry if you don"t see it in list of mods - if you subscribed to it just follow this guide.
Programmable blocks and in-game scripts are now in "Experimental mode" in game that you need to turn on in game options. Also don"t forget to enable in-game scripts in advanced world settings.
I highly recommend touching the programmable block now and then to update the script if there were any new features added or bugs fixed. Look at "How to update" section to learn how to update scripts in your programmable blocks.
Script cannot update itself inside your programmable blocks. You need to load new version of script to your programmable block to overwrite the old one. You can do that in exactly the same way as when you first loaded the script into programmable block.
Open your programmable block, click Edit, click Browse Workshop, select Automatic LCDs 2, click OK, Check code, Click Ok. Done. Your script is now updated.
Note: If you are experiencing errors on translated version of script please write to the script page of author of that translation. I can"t update translations.
Your commands are too long to fit on single line?You can use a \ to tell the script to continue the command on the next line, just make sure there is nothing after the \ not even a space.
As you know almost every command has first argument used for name filtering which can be used to filter blocks by block name or block group name. This name filter now supports more than that. You can use it to tell the script to only look for blocks which are part of the same grid as the one where the programmable block is.
This is very useful if you connect ships to your station or ship and you don"t want to see blocks of the connected ships on station LCDs. You can also use this script on multiple ships that connect together without worries that they will conflict once connected.
Script now only updates LCDs which are part of the same grid as programmable block. If you would like to change this please take look at What is LCD_TAG? section to learn how to change LCD_TAG.
What is the grid?Simplest way to describe the grid is to say that it is single ship. However this is not always true. Blocks connected by pistons, rotors or connectors are not on the same grid!
LCDs that are connected using rotors, pistons or connectors are not updating?By default the script only updates LCDs that are part of the same grid as programmable block.
LCD_TAG is used to tell the script which LCDs are managed by the script. As all of you know the script looks for LCDs that have [LCD] in their name by default.
You can however change this to whatever you like. You can tell the script to manage LCDs in certain group or even tell it to manage all LCDs regardless of name.
How to change the LCD_TAG?You can change the LCD_TAG by editing the Custom Data of programmable block that runs the script. Let"s explain it by example:
Note: If you already use Custom Data to display stuff on Programmable block screens (check "How to use with cockpits?" section of the guide to understand how):
How to tell the script to manage all LCDs regardless of name?LCD_TAG follows the same name filtering rules as commands. So you can set the Custom Data to:
You also can"t change the LCD_TAG during run. You need to recompile the script every time you change the LCD_TAG otherwise the script will still look for old tag.
It is now possible to join multiple LCDs together so they will look and work like single panel. Because of the limitations of text alignment it is only possible to join LCDs up and down. Not left to right. So the widest LCD you can have is Wide LCD. But you can have many of them under each other to form single big one.
NUMBER is position of LCD in array of LCDs. It doesn"t matter what number you choose. They just need to go one after another. So the topmost LCD will have the lowest number. For example 1. LCD under it will have 2, etc.
You can use this script on cockpit screens as well as screens of other blocks. In order to do that you have to mark the cockpit (or other block) with the LCD_TAG as you did with LCDs. So by default you add [LCD] to the name of the cockpit in order for the cockpit to be recognized by the script.
As soon as you do that the first screen on the cockpit will be controlled by the Automatic LCDs 2 and should display the usual message that you should write commands to custom data of the panel. If you need only this screen, you can write commands to Custom Data of the cockpit just as you do with LCDs.
Where
Easy way to know the index of the screen is when you look at the control panel of the cockpit, find the list of the LCD panels and pick one. For example "Keyboard" screen is 4th in the list of the LCD panels which means its index is 3 (because first one is 0). So if you would want to write only to the Keyboard screen your custom data would look like this:
You can use this on any block that has LCD panel screens. Script will not touch screens that you haven"t specified so you can use this with other scripts too. Read "Compatibility with other scripts" if you want to know how Automatic LCDs can share Custom Data with other scripts.
If you want to dock or merge a ship that is using this script with another ship or station that is also using this script you can run into some problems which can be easily prevented if you know how.
Script now only updates LCDs which are part of the same gridThis means that LCDs which are connected using connectors, pistons or rotors will not be updated to prevent conflicts between docked ships. This does not apply when ships are connected using merge block because in that case they behave like single ship in game.
LCDs are updating much slower when more ships are docked using merge blockIf there are more ships using this script docked together using merge block then the programmable blocks will not split the work efficently automatically.
I recommend using different LCD_TAG for each ship and station. Look at Tips and Tricks section of this guide to learn how to do that. This will ensure that programmable blocks always update only LCDs on the ship/station they are intended for.
LCDs are showing items, power, cargo, etc of all docked shipsThis will happen if you use no arguments to commands or if you use * or if you use same names for groups / blocks on both ships. Make sure you read Same ship blocks filtering section to learn how to filter only blocks of the same ship.
If you follow this convention for all your ships and stations then you should have no problems with docking or merging ships together. Never use * or no argument if you plan to dock the ship and you don"t want to see things from other ships when docked.
Displays inventory summary for certain item types. It automatically adds 0 items lines for vanilla game items. Script will automatically display even modded items if they are in the inventories, but it will not report missing modded items.
If you don"t want to display missing items (0 items lines) use InventoryX instead of Inventory (good for displaying contents of container). This will also disregard default quotas so unless you set quota yourself it will be 0 and no visual bar will be shown.
Advanced: If you know something about how items in SE internals work, you can translate or add modded items to be reported when 0 of them is in the inventory. Look into Modded Items discussion on the Steam Workshop page for more info.
Automatically separates reactors, engines, solar panels, wind turbines and batteries. Works with modded blocks. It shows maximum achievable power output for solar panels. That means that if there is no sun shining on solar panels then the maximum is 0 W.
Custom TitlesThis command by default writes "Reactors:", "Engines:", "Turbines:", "Batteries:" and "Solars:" in the output. Now you can override that by using second argument like this:
NOTE (Bug): the game reports power usage of all thrusters on single thruster and all other thrusters report no power use - because of this it is not possible to separate thrusters and all of them except for one will report 0 power use and that single thruster will report power usage of all thrusters.
NOTE: in-game scripts have very limitted access to things which are needed to estimate power time. I"ve done everything I could think of to estimate the time with as much precision as possible, but it is not perfect. It is just an estimation. On the other side, during my testing I found it to be more precise than the Fuel Time displayed on game HUD in some situations.
Note: This is just estimated time by script. It will probably not be exactly correct and it is possible that it will jump up and down, because of how in-game scripting works and because of the fact that the game doesn"t expose such information without dirty hacks and the script has to calculate it itself.
Displays damaged and partially built ship/station blocks. Script only has access to blocks which are visible in control panel so no armor blocks, conveyor tubes, etc are considered.
You can now also use word NoC (No Contruction) which will make Damage commands display only damaged blocks and not show blocks that were grinded / not fully constructed.
Doesn"t show connectors that are not connected unless you use DockedE variant in which case it will show "-" when the connector is not connected to anything.
It may not work for some localized games, but working command for battery now shows batteries charge state as (+) 100.0% or (-) 55.5% .. (+) meaning battery is charging (-) meaning its not charging. The number of percent is portion of full capacity filled.
Eg: OnOff, Open, ShowOnHUD, Depressurize, slaveMode, UseConveyor, ControlThrusters, ControlWheels, DampenersOverride, HandBrake, HorizonIndicator, MainCockpit, DrainAll, AnyoneCanUse, Force weld, ShareInertiaTensor, Override, Autolock, EnableIdleMovement, Shoot, TargetCharacter, TargetLargeShips, TargetMeteors, TargetMissiles, TargetNeutrals, TargetSmallShips, TargetStations, isPerm, SetFaction, TakeOwnership, Auto-Refill, Stockpile, AutoDeploy, etc.
They are case sensitive! Make sure you enter them exactly without any spaces before or after them. e.g. use {AutoDeploy} not {Auto Deploy} nor { AutoDeploy } nor {autodeploy}.
There are a lot of properties for many different blocks and listing them all here along with what they do would take a lot of space so I"m leaving that up to you to try.
Due to game limitations some blocks do NOT automatically update the details text until you look at them in control panel. This is VERY important as you always need to look at the block in control panel if you want the LCD to show updated text. This does not apply to all blocks!
The command above will get the details text from block My Block and if it finds "Text to look for:" in the details text it will display it and any text after that otherwise if the text is not found the output will be empty.
The command above will get the details text from block My Block and if it finds "Text to look for:" in the details text it will display it and any text after that until it displays 2 lines, it will not display any line after that (for that block).
The command above will get the details text from block My Block and if it finds "Text to look for:" in the details text it will display it and any text after that until it finds line that contains "Text to stop" - it will NOT display this line or any line after it (for that block).
Note: If you would like to display only leaking air vents you can use Working command and filter only LCDs that show LEAK using filtering described in Working command.
Note: This is not exactly true. It uses the name of the type of gas that is in the tank, but there is no easy way to find that out in the game (creator of the gas mod can tell you what it is).
This is very useful when using different mods / scripts that write something to Custom Data of block and you would like to append it to your Automatic LCDs displays.
This is very useful when using different mods / scripts that type something on LCD and you would like to append it to your Automatic LCDs displays. This way you can have one LCD hidden that will be used by your mod / script and use TextLCD command to read that text and write it to one of the Automatic LCDs. Example: TextLCD {Other LCD} will append contents of first LCD named Other LCD.
So how to get around it? You can use special character to mark what is not supposed to be replaced. So if we would like to fix our previous example we would do this:
So first is hours in 24-hour format then : then minutes with a leading zero then space then day of month then . then month number then . and then full year
You can also add this to button panel and setup action on button to Run the programmable block with argument. It needs to be the same programmable block that runs the script that shows the text on the screen on that particular LCD.
If you use custom font scroll down to the bottom of script, then scroll a bit up until you find AddCharsSize lines. Monospace font name and size definition is above those.
LCD clear functionWhen you Run the programmable block with argument "clear" (without quotes) it will clear all LCDs. You can use this to turn off your LCDs without having to actually turn them off where they would say "OFFLINE".
LCDs boot screensUnfortunately there is no easy way to find out that you turned off/on your ship so the script doesn"t automatically display boot screens after turn the power sources off and on. You can however use the LCD clear function to reset the LCDs when you turn on your ship/station. There is also special "boot" argument to start the boot sequence whenever you need it. Just Run the programmable block with "boot" (without quotes) as argument.
Automatic LCDs 2 is not a mod so you don"t need to do anything in dedicated server setup to use it except for having enabled in-game scripts in your world.
It is now possible to easily translate the script to your own language. You need to only translate item names and messages at the bottom of the script.
You can change the second string on the line to equivalent in your language, but do NOT change the first string. I also recommend you keep the text as short as possible.
Note: If you are experiencing errors on translated version of script please write to the script page of author of that translation. I can"t update translations.
How to use LCDs that are connected using rotors, pistons or connectors?By default the script only updates LCDs that are part of the same grid as programmable block. First, I do recommend reading about "Same grid filtering" in separate section of this guide.
How to stop the script from changing Content Type of the panels?You can add line "SKIP_CONTENT_TYPE = true" (without quotes) to Custom Data of the programmable block to disable automatic panel content type change.
Do you want to change some text that the script says?You need script to not show "Total Output" but only "Total"? Or is there anything else that doesn"t fit your needs? You can change anything the script says at the bottom of the script. Look at "How to Translate?" section to learn how to make the script say what you need.
Keen has added MyIni format that scripters can use to parse Custom Data. This was added explicitly to make life easier for scripters when they need to use Custom Data and share it with other scripts. This was written by Malware (the creator of MDK framework for Space Engineers in-game scripting and father of Programmable Block) and I"ve been discussing with him how to make it compatible with Automatic LCDs without people having to learn new syntax so he came up with great solution.
If people also want to write Automatic LCDs commands to the same block where the Custom Data is already used by script that uses MyIni format then they can simply add 3 dashes on its own line and continue with Automatic LCDs commands like this:
Anything under the --- is ignored by the MyIni parser that other scripts use. Anything before the --- is completely ignored by the Automatic LCDs so this way Automatic LCDs can share Custom Data with other scripts and coexist peacefully :)
NOTE: Some scripts overwrite the Custom Data and if you already have some Automatic LCDs commands there they will remove them. If those scripts support the MyIni format then you can write your commands like this to make them not remove the commands (or set them up first and then use the format like explained above):
This script doesn"t work like other scripts on the workshop. Script updates dynamically as it needs and time between updates of most of the commands is several seconds depending on complexity of the command. There is not a single update time you can modify because the script doesn"t work that way. The script automatically limits itself and spreads the calculations over time to have minimal impact on the game performance. That"s why the more commands you use the longer it will take to update all of them. Unfortunately even if I figured out some way to let you configure update rates, I just can"t leave the update rates configurable for people, because the script would have very bad impact on game with high refresh rates and many people would not realize that - trust me, we"ve been there.
I will always try to make sure that the script performs as well as possible while giving you good enough refresh rates. Unfortunately it can"t be completely real time, because the impact would be just too huge.
READ THIS: Programmable blocks and in-game scripts are now in "Experimental mode" in game that you need to turn on in game options. Also don"t forget to enable in-game scripts in advanced world settings.
*** Check your ownership ***Always make sure that the programmable block and LCDs have the same ownership as the blocks you want to show on the LCDs. I highly recommend you own all the blocks unless you know how ownership works. Just open the control panel, select one of the blocks on your ship, press CTRL+A and change the ownership on the right side to "Me".
Script limiter is unreliable and dependent on things outside of the game (like other processes eating the CPU etc). Admins use it because its the only way to stop scripts from slowing down the server unfortunately in the process it kills even innocent scripts when the server is overloaded.
Technical details: Script limiter counts real time it took script to execute. Because of how computers and operating systems work the real time it takes to execute some code is dependent on other things running on the computer. So if one thing is using a lot of CPU then other things will take longer to complete. This is why even scripts that do almost nothing can take a lot of time to complete if the computer is overloaded by for example doing backups, scanning for viruses, calculating the answer to ultimate question, etc. Because the scripts get less CPU time it takes much longer to complete even simple tasks. This is why its almost impossible to make the script survive script limiter actions if the server is overloaded from doing other stuff many times even outside of the SE game itself.
1. If your LCDs are on separate grid (behind rotor, piston, connector) they will not be updated. Read LCDs that are connected using rotors, pistons or connectors are not updating? section of Troubleshooting section of the guide.
4. Make sure you carefully read the command description in this guide and that you understand what it is saying. If you don"t understand what it is saying please let me know and I will modify it to be more clear.
Programmable block reports "Exception".If programmable block control panel shows "Exception" please report it in he "BUG REPORTS" discussion on main script page.
LCDs that are connected using rotors, pistons or connectors are not updating?By default the script only updates LCDs that are part of the same grid as programmable block. First, I do recommend reading about "Same grid filtering" in separate section of this guide.
If some of your LCDs are sometimes offline:it"s probably a game bug and it"s happening to more people. Someone said that loading game, returning to main menu and loading again helps.
Does your LCD just say ONLINE instead of showing things?Make sure that you named your LCD so it contains [LCD] . If you did, you are most probably using german client which has problems with [] characters that you type in game. You can use copy-paste to overcome it or simply use alternate built-in tag I made for you !LCD!
It"s just blank screen?Your command is wrong or there is simply nothing to show. Check your command syntax in full guide, try examples. Make sure that there is nothing in front of the command in LCD Public Title (game sometimes likes to hide the "Public title" text). Always press Home before entering command to make sure there is no text at the beginning of LCD Public Title that you don"t want to have there.
Programmable block reports "Index out of bounds".Make sure that you updated the script to latest version with all the fixes. Check that script has permissions to write to LCDs!
I need to see what assembler/refinery is producing like on your screenshotIt is not possible to find out what assembler or refinery is doing from the script. What you see on screenshot are names of assemblers and refineries. I use scripts Crafting Component Quotas and Selective Refining. Crafting Components Quotas can rename your assemblers like you see on screenshot.
It does not only affect texts that are created with the API, but according to my observations, also texts that are written normally via the editor in the terminal.
It does not only affect texts that are created with the API, but according to my observations, also texts that are written normally via the editor in the terminal.
For anyone curious following this. You can still use traditional LCD panels and the WriteText() method for your updating displays in dedicated servers.
For anyone curious following this. You can still use traditional LCD panels and the WriteText() method for your updating displays in dedicated servers.
I tried to put it on another ship but it gave me the same problem, the ships were all naturally less than 600 meters away, and I checked the requirements several times.
I tried to put it on another ship but it gave me the same problem, the ships were all naturally less than 600 meters away, and I checked the requirements several times.
Joined my friend"s game hosted by him. Non-dedicated server. I made a blueprint with a couple scripts loaded in, tested that everything worked in single player, but when we used it in multiplayer only the host could see the scripts update. The text doesn"t get sent to clients. It updates every detail of a panel but not the text. All LCDs, cockpit LCDs, programmable block LCDs, etc don"t update. Opening the panel shows there is no text but the host confirmed the panel is not blank and is updating for him.
Joined my friend"s game hosted by him. Non-dedicated server. I made a blueprint with a couple scripts loaded in, tested that everything worked in single player, but when we used it in multiplayer only the host could see the scripts update. The text doesn"t get sent to clients. It updates every detail of a panel but not the text. All LCDs, cockpit LCDs, programmable block LCDs, etc don"t update. Opening the panel shows there is no text but the host confirmed the panel is not blank and is updating for him.
Can confirm this bug. This bug seems to apply to both DS and Non-DS and the problem only happens for the connected clients, not the host (Networking issue?). The screen is updated for the host but not the client until the client reconnects where the current displayed image/text will be refreshed and stay that way until you reconnect again. Using "IMyTextSurface.GetText()" will return the correct text that is supposed to be displayed.
Can confirm this bug. This bug seems to apply to both DS and Non-DS and the problem only happens for the connected clients, not the host (Networking issue?). The screen is updated for the host but not the client until the client reconnects where the current displayed image/text will be refreshed and stay that way until you reconnect again. Using "IMyTextSurface.GetText()" will return the correct text that is supposed to be displayed.
It"s still not working for any of my scripts. Locally I can update the text on a cockpit display fine, but doing so on a dedicated server does not actually update the visible text. Am I doing this wrong, or was it marked as Solved when not actually Solved?
It"s still not working for any of my scripts. Locally I can update the text on a cockpit display fine, but doing so on a dedicated server does not actually update the visible text. Am I doing this wrong, or was it marked as Solved when not actually Solved?
yes. you can also see the resulting text if you try to manually edit the text. you just cannot see it on the outside surface. This is still an issue on my DS, but only after other players join the server. It works fine when I am alone on the server as the host.
yes. you can also see the resulting text if you try to manually edit the text. you just cannot see it on the outside surface. This is still an issue on my DS, but only after other players join the server. It works fine when I am alone on the server as the host.
It seems that the programmer block has a new bug, not important but PB screen cannot be set to anything, it stays on the "No Content" image event with simple text or image or script (ex: digital / analog clock).
It seems that the programmer block has a new bug, not important but PB screen cannot be set to anything, it stays on the "No Content" image event with simple text or image or script (ex: digital / analog clock).
As soon as someone else joins, I can no longer see the surface (it switches to the default blue symbol from when it was disabled) ....however, the client players can still see the text on those surfaces.
As soon as someone else joins, I can no longer see the surface (it switches to the default blue symbol from when it was disabled) ....however, the client players can still see the text on those surfaces.
But it will decrease the performance of the game - you need to have powerful GPU for that, as each screen is essentially another frame to render. Thus if your FPS is 40, with another camera-on-screen it might drop to 20 (if low FPS was caused by taxed GPU, not overloaded CPU). And it will incur some cost in CPU performance.
But it can be managed: in graphic settings there might be another slider: maximum of camera-to-screens, max distance of player to screen with screens nearer to player taking preference, plus if screen is LOD model it should be ignored.
But it will decrease the performance of the game - you need to have powerful GPU for that, as each screen is essentially another frame to render. Thus if your FPS is 40, with another camera-on-screen it might drop to 20 (if low FPS was caused by taxed GPU, not overloaded CPU). And it will incur some cost in CPU performance.
But it can be managed: in graphic settings there might be another slider: maximum of camera-to-screens, max distance of player to screen with screens nearer to player taking preference, plus if screen is LOD model it should be ignored.
The original mod worked fine, almost no performance impact whatsoever. It was well designed, didn"t do anything it didn"t need to, and used a dynamic pool of your available frames so that it literally couldn"t drag your FPS down. The worse your frames, the less the mod did. If you got over 60, it used those for even smoother displays. Xocliw showed it off on the community stream. He showed it directly to Marek, showed it working beautifully, while having none of the drawbacks it was claimed such a mod would have. And then Keen ignored the potential and changed a bunch of things and the mod died.
The original mod worked fine, almost no performance impact whatsoever. It was well designed, didn"t do anything it didn"t need to, and used a dynamic pool of your available frames so that it literally couldn"t drag your FPS down. The worse your frames, the less the mod did. If you got over 60, it used those for even smoother displays. Xocliw showed it off on the community stream. He showed it directly to Marek, showed it working beautifully, while having none of the drawbacks it was claimed such a mod would have. And then Keen ignored the potential and changed a bunch of things and the mod died.
It did have the drawbacks it was claimed such a mod would have... it"s just, it was showcased on powerful computers with enough frames to spare. The second you don"t have a powerful computer, you"ll see the drawbacks quickly. This is why it wasn"t made vanilla.
It did have the drawbacks it was claimed such a mod would have... it"s just, it was showcased on powerful computers with enough frames to spare. The second you don"t have a powerful computer, you"ll see the drawbacks quickly. This is why it wasn"t made vanilla.
Duke Nukem 3d had a camera view to screen feature in a game with user generated maps/layouts 22 years ago. Granted it wasn"t 1080p but I don"t think anyones expecting that from a Text panel. Unpossible!
Duke Nukem 3d had a camera view to screen feature in a game with user generated maps/layouts 22 years ago. Granted it wasn"t 1080p but I don"t think anyones expecting that from a Text panel. Unpossible!
glad to see this thread bumped i find it ridiculous that this isn"t already in the game. Surely you could implement this with some sort of anti-rastorization method where you just don"t render the parts of the ship eclipsed by the display just like if you gave dirt or whatever a transparent texture back in minceraft, that"s how rodina does it; and even without the fact that this method would be way more efficient, you would also end up with a better, more spacey, implementation "cause it would have perspective.
glad to see this thread bumped i find it ridiculous that this isn"t already in the game. Surely you could implement this with some sort of anti-rastorization method where you just don"t render the parts of the ship eclipsed by the display just like if you gave dirt or whatever a transparent texture back in minceraft, that"s how rodina does it; and even without the fact that this method would be way more efficient, you would also end up with a better, more spacey, implementation "cause it would have perspective.
Also, it"s not a matter of C# vs C++. It might be marginally faster if implemented correctly in C++, but it"s more a matter of the graphics card having to render 2 "screens" instead of 1.
It"s a fantastic feature that i"d love to have, with current technology (Not just SE), it"s just not really possible in a way that would be usable in game.
Also, it"s not a matter of C# vs C++. It might be marginally faster if implemented correctly in C++, but it"s more a matter of the graphics card having to render 2 "screens" instead of 1.
It"s a fantastic feature that i"d love to have, with current technology (Not just SE), it"s just not really possible in a way that would be usable in game.
@zooltan no, the camera monitors would show a display of the camera view after you look through it. Its framerate was like 1Hz and it only lasted for so long but considering I was playing it on a x486 (I think)...
@zooltan no, the camera monitors would show a display of the camera view after you look through it. Its framerate was like 1Hz and it only lasted for so long but considering I was playing it on a x486 (I think)...
Rendering a scene to a dynamic camera is something video games have always struggled with, especially if it"s a scene from an area wwith no players anywhere near by, you"re asking the server to keep up with scenes that could be across the map, or atleast across max antenna range.
Rendering a scene to a dynamic camera is something video games have always struggled with, especially if it"s a scene from an area wwith no players anywhere near by, you"re asking the server to keep up with scenes that could be across the map, or atleast across max antenna range.
While the actual rendering is client side, the camera can be several subgrids - maybe kilometers - away and see a different part of the universe. A camera would be like an additional player, spawning in local asteroids and streaming grid data from the server to be rendered on the remote camera feed. Or cameras are 100% local and intended for cameras in close proximity only, with no load on the server and very low PCU amount. (Maybe have separate server/client PCU?)
While the actual rendering is client side, the camera can be several subgrids - maybe kilometers - away and see a different part of the universe. A camera would be like an additional player, spawning in local asteroids and streaming grid data from the server to be rendered on the remote camera feed. Or cameras are 100% local and intended for cameras in close proximity only, with no load on the server and very low PCU amount. (Maybe have separate server/client PCU?)
It is possible, but that was never a simple mod; that entry on the Steam workshop was just to add the terminal controls, the actual code was in a plugin (Client Extender) that you had to install alongside the game.It allowed you to write frames to textures and had a priority queue system so it would never drain your FPS more than you allowed it, and you could give client-side priority to cameras; if you"re in a big battle with a bunch of different people who also use LCD feeds then, from your perspective, yours would be updated first and fastest regardless.
It is possible, but that was never a simple mod; that entry on the Steam workshop was just to add the terminal controls, the actual code was in a plugin (Client Extender) that you had to install alongside the game.It allowed you to write frames to textures and had a priority queue system so it would never drain your FPS more than you allowed it, and you could give client-side priority to cameras; if you"re in a big battle with a bunch of different people who also use LCD feeds then, from your perspective, yours would be updated first and fastest regardless.
I saw Camera, LCD, then it was obvious I could link a camera feed to one of cockpit LCD to have a view..... even at low resolution, and even with limitation numbers.
I saw Camera, LCD, then it was obvious I could link a camera feed to one of cockpit LCD to have a view..... even at low resolution, and even with limitation numbers.
In short, as many people out there, I really believe that this should"ve been in the vanilla game since the LCD"s were introduced and also believe that it would elevate the game play so much.
In short, as many people out there, I really believe that this should"ve been in the vanilla game since the LCD"s were introduced and also believe that it would elevate the game play so much.
In short, as many people out there, I really believe that this should"ve been in the vanilla game since the LCD"s were introduced and also believe that it would elevate the game play so much.
In short, as many people out there, I really believe that this should"ve been in the vanilla game since the LCD"s were introduced and also believe that it would elevate the game play so much.
In short, as many people out there, I really believe that this should"ve been in the vanilla game since the LCD"s were introduced and also believe that it would elevate the game play so much.
In short, as many people out there, I really believe that this should"ve been in the vanilla game since the LCD"s were introduced and also believe that it would elevate the game play so much.
Having the ability to view a camera image from an LCD in a basement - which is what I nearly always end up building in order to protect my gear from meteorites - would be a massive boon.
Also, displaying multiple camera images on LCDs means that a ship could have a decent bridge buried deep inside it and still have good visibility of the surrounding space, without needing to cycle through cameras while sitting in a control seat.
Having the ability to view a camera image from an LCD in a basement - which is what I nearly always end up building in order to protect my gear from meteorites - would be a massive boon.
Also, displaying multiple camera images on LCDs means that a ship could have a decent bridge buried deep inside it and still have good visibility of the surrounding space, without needing to cycle through cameras while sitting in a control seat.
I want this to very very badly I had a ship idea that had this involved with a script but I didn’t know that Scripps couldn’t allow this yet. I hope they Addison to the game I really really do!
I want this to very very badly I had a ship idea that had this involved with a script but I didn’t know that Scripps couldn’t allow this yet. I hope they Addison to the game I really really do!
The mod is smart about it and makes it so that the LCD can "share" frames instead. So it can update at 30 fps but it doubles the GPU Render Load, or all the way down to 1fps which divides evenly amongst other LCDs. So if you had the setting at 30fps they"d each run at 15fps, which would divide further as you added more.
The mod is smart about it and makes it so that the LCD can "share" frames instead. So it can update at 30 fps but it doubles the GPU Render Load, or all the way down to 1fps which divides evenly amongst other LCDs. So if you had the setting at 30fps they"d each run at 15fps, which would divide further as you added more.
I don"t know the limitations of this engine, but that what we ask for here, is used in many games like Portel or Prey (the old one) and is used, when some NPCs are in a monitor. For example, in Half Life 2, when Wallace Breen has his speeches on the monitors, the actual NPC is loaded in a separate room on the map, where the NPC gets recorded by a virtual camerajand is streamed directly to the ingame TVs and monitors, the player can see and they do it that way, because, according to the devs, tihs is much easier then make a actual video clip to play back on the screens. So it schouldn"t be wichcraft to make something like that. Except the engine really can"t cope with that.
The Mods we had, are more or less a collection of workarounds to make this feature somewhat functioning, but someone with unrestricted access to the source code, should be able to implement, at least the frame work, for such a function, without all too heavy performance impacts. Furthermore we are in an age, of ridiculously powerfull GPU like the Nvidia 30 Series and Space Engineers never was a casual game, requirement wise. And for those with a too weak system, we could make a tab in the world settings to disable this feature.
I don"t know the limitations of this engine, but that what we ask for here, is used in many games like Portel or Prey (the old one) and is used, when some NPCs are in a monitor. For example, in Half Life 2, when Wallace Breen has his speeches on the monitors, the actual NPC is loaded in a separate room on the map, where the NPC gets recorded by a virtual camerajand is streamed directly to the ingame TVs and monitors, the player can see and they do it that way, because, according to the devs, tihs is much easier then make a actual video clip to play back on the screens. So it schouldn"t be wichcraft to make something like that. Except the engine really can"t cope with that.
The Mods we had, are more or less a collection of workarounds to make this feature somewhat functioning, but someone with unrestricted access to the source code, should be able to implement, at least the frame work, for such a function, without all too heavy performance impacts. Furthermore we are in an age, of ridiculously powerfull GPU like the Nvidia 30 Series and Space Engineers never was a casual game, requirement wise. And for those with a too weak system, we could make a tab in the world settings to disable this feature.
The problem is, no matter the engine, rendering an extra camera will always cost a full extra render pass; which will scale for every camera you have active.
The problem is, no matter the engine, rendering an extra camera will always cost a full extra render pass; which will scale for every camera you have active.
i would make lcd refresh rate based on distance to closest player, that is looking at that lcd - so game would crank up lcd fps only when someone is actually looking at it and "freeze" display when nobody is around or looking on something else ....
i would make lcd refresh rate based on distance to closest player, that is looking at that lcd - so game would crank up lcd fps only when someone is actually looking at it and "freeze" display when nobody is around or looking on something else ....
I also find it very strange that this is so hard to implement... Duke Nukem 3D dynamically rendered security cameras onto display screens just fine 25 years ago (before even basic 3d graphics cards were even in most gamer"s PCs) along with a few N64 games, like Goldeneye. Not to mention more recent games like Half Life 2. There are a lot of ways to keep it performant on modern systems. Here"s a few suggestions that little old me can think of to keep system performance from being too negatively impacted.
If a remote camera LCD isn"t in visible range to a player, then don"t gather render data from the camera nor render the camera onto the LCD. I do not believe this is something that a modder could do, since it would require access to a player"s rendering data and being able to detect if any remote camera LCDs are within what"s being rendered.
Any camera feeds are sampled at a lower resolution and also rendered to LCDs at a lower resolution than when a player views through the camera directly. With a lower resolution on both sampling and rendering I would expect GPU stress to be lower as well.
Nested camera LCDs (any LCD"s rendering a camera that are THEN viewed by a later camera and rendered to a later LCD) would be only rendered at 1fps and only when the player is looking at the later LCD, otherwise it is not rendered. Or just don"t render nested camera LCDs at all, though that might confuse some players if done without explanation.
I also find it very strange that this is so hard to implement... Duke Nukem 3D dynamically rendered security cameras onto display screens just fine 25 years ago (before even basic 3d graphics cards were even in most gamer"s PCs) along with a few N64 games, like Goldeneye. Not to mention more recent games like Half Life 2. There are a lot of ways to keep it performant on modern systems. Here"s a few suggestions that little old me can think of to keep system performance from being too negatively impacted.
If a remote camera LCD isn"t in visible range to a player, then don"t gather render data from the camera nor render the camera onto the LCD. I do not believe this is something that a modder could do, since it would require access to a player"s rendering data and being able to detect if any remote camera LCDs are within what"s being rendered.
Any camera feeds are sampled at a lower resolution and also rendered to LCDs at a lower resolution than when a player views through the camera directly. With a lower resolution on both sampling and rendering I would expect GPU stress to be lower as well.
Nested camera LCDs (any LCD"s rendering a camera that are THEN viewed by a later camera and rendered to a later LCD) would be only rendered at 1fps and only when the player is looking at the later LCD, otherwise it is not rendered. Or just don"t render nested camera LCDs at all, though that might confuse some players if done without explanation.
Many games implement in-view screens of the game world. This isn"t new and not impossible just something Keen chose not to implement with their time. Other priorities. The LCD displays in the game and the cameras seem like a perfect match.
Many games implement in-view screens of the game world. This isn"t new and not impossible just something Keen chose not to implement with their time. Other priorities. The LCD displays in the game and the cameras seem like a perfect match.
Ill be honest, I don"t care about the GPU limitations and all the technical issues. Sorry but thats not for us players to worry about, we come up with ideas and devs make the judgements and solutions. If this feature works it would be a massive improvement to the game.
Ill be honest, I don"t care about the GPU limitations and all the technical issues. Sorry but thats not for us players to worry about, we come up with ideas and devs make the judgements and solutions. If this feature works it would be a massive improvement to the game.
Now as to why this will never probably happen other than those options I had given above and not dragging into question player Computer specs and what not.
Now as to why this will never probably happen other than those options I had given above and not dragging into question player Computer specs and what not.
It"s not the overlay, it"s the feed - which doesn"t exist. Cameras cheat by moving the player"s POV to the camera, not be sending a camera feed back to the player. So this request is more work than it appears; each camera would need to be rendered. Would it be rendered by the server? Servers don"t render anything right now. A player? Which one? What if they log out? It"s complicated.
It"s not the overlay, it"s the feed - which doesn"t exist. Cameras cheat by moving the player"s POV to the camera, not be sending a camera feed back to the player. So this request is more work than it appears; each camera would need to be rendered. Would it be rendered by the server? Servers don"t render anything right now. A player? Which one? What if they log out? It"s complicated.
I was searching about the best camera for photography then I found an article on google which gave the best info about top cameras and lenses. The article was from
I was searching about the best camera for photography then I found an article on google which gave the best info about top cameras and lenses. The article was from
It"s not rhetoric, it"s simple reality of economics. If you can"t afford what"s necessary to run a feature, then you can hardly expect the feature to be made available to you anyway, can you? I too would like if my car was as luxurious as a Bentley. Alas, I couldn"t afford a Bentley, so, why should I be entitled to having VW make my Polo be like one for what I paid for that Polo?
It"s not rhetoric, it"s simple reality of economics. If you can"t afford what"s necessary to run a feature, then you can hardly expect the feature to be made available to you anyway, can you? I too would like if my car was as luxurious as a Bentley. Alas, I couldn"t afford a Bentley, so, why should I be entitled to having VW make my Polo be like one for what I paid for that Polo?
I was not refering to the message, that was true enough. your statement is also true. but if your polo and bentley were made in the same year, is one more primitive than the other? I was reffering to error 404"s use of the word primitive in the context of consoles and its derogatory connotation in this sense.
I was not refering to the message, that was true enough. your statement is also true. but if your polo and bentley were made in the same year, is one more primitive than the other? I was reffering to error 404"s use of the word primitive in the context of consoles and its derogatory connotation in this sense.
Attacking strawmen buys you nothing. I never said anywhere that either make was more or less primitive than the other, and you know damn well I never did. You were the one who conflated those two very separate illustrations of the matter.
Attacking strawmen buys you nothing. I never said anywhere that either make was more or less primitive than the other, and you know damn well I never did. You were the one who conflated those two very separate illustrations of the matter.
I was reffering to error 404"s message with my primitive statement. I apologize if that was interpreted the wrong way. as far as justification of purchase and all that, I just want to play the game and have fun. I won"t get into a linguistics debate because I don"t want to. all the rest of that eggshells and diplomacy and whatever else you are talking about is kinda irrelevant because you are right. they should be two seperate versions. but just because you are correct does not mean you can"t be polite in your speech and manner towards other people.
I was reffering to error 404"s message with my primitive statement. I apologize if that was interpreted the wrong way. as far as justification of purchase and all that, I just want to play the game and have fun. I won"t get into a linguistics debate because I don"t want to. all the rest of that eggshells and diplomacy and whatever else you are talking about is kinda irrelevant because you are right. they should be two seperate versions. but just because you are correct does not mean you can"t be polite in your speech and manner towards other people.
The troll face says it all. PC gamers also have low end hardware. There is a bit of psychology at work here though. If your PC can"t handle the camera-to-LCD feature you may chose to turn it off for now, maybe consider a GPU or RAM upgrade or just accept it for now. For cool screenshots you can always turn it back on temporarily. You feel like it"s all in your hands. On a console on the other hand, graphics and complexity are often locked down, like the number of planets or asteroids. You can"t upgrade a hardware component or decide for yourself if camera-to-LCD is worth the performance hit. Others decide what your console can handle. You begin to feel disenfranchised compared to a PC gamer with comparable hardware.
The troll face says it all. PC gamers also have low end hardware. There is a bit of psychology at work here though. If your PC can"t handle the camera-to-LCD feature you may chose to turn it off for now, maybe consider a GPU or RAM upgrade or just accept it for now. For cool screenshots you can always turn it back on temporarily. You feel like it"s all in your hands. On a console on the other hand, graphics and complexity are often locked down, like the number of planets or asteroids. You can"t upgrade a hardware component or decide for yourself if camera-to-LCD is worth the performance hit. Others decide what your console can handle. You begin to feel disenfranchised compared to a PC gamer with comparable hardware.
I have a lot of critique for Keen and their decitions, but I agree with them on this one. I am a software developer, with 8 years of experience in game engines and I don"t know of any way to implement this in a way that performs well and satisfies what players expect.
So unless you can give a detailed explanation of how to implement this, and not just how you "think" it can be done, then please respect the actual developers who decided not to implement this one feature.
I have a lot of critique for Keen and their decitions, but I agree with them on this one. I am a software developer, with 8 years of experience in game engines and I don"t know of any way to implement this in a way that performs well and satisfies what players expect.
So unless you can give a detailed explanation of how to implement this, and not just how you "think" it can be done, then please respect the actual developers who decided not to implement this one feature.
Also, generaly speaking, if you are a doing one job and you find yourself strugling due to incompetence, you can always go do somethingh ealse. Sweeping streets or emptying sewers pays well. I wouldnt know tho, cos i do my job well.
Also, generaly speaking, if you are a doing one job and you find yourself strugling due to incompetence, you can always go do somethingh ealse. Sweeping streets or emptying sewers pays well. I wouldnt know tho, cos i do my job well.
As can be seen in this YouTube Video (https://www.youtube.com/watch?v=cWpFZbjtSQg) implementing a camera feed to the LCD screens shouldn"t be thatdifficult. Now one difference would be the need to dynamically alter the position of the projection but even as an inexperienced programmer that is not an issue. If the devs have some competence (which I would assume given they developed this game) it should not be a problem to implement at all, except of course the issue with consoles other users mentioned. Drawing a second camera is expensive for the render engine but if not done at full resolution, unless the player is accessing the camera directly, I fail to see any issues except poor performance on low end pc"s and console, which imo is already the case so that would be a drop of water in an ocean.
As can be seen in this YouTube Video (https://www.youtube.com/watch?v=cWpFZbjtSQg) implementing a camera feed to the LCD screens shouldn"t be thatdifficult. Now one difference would be the need to dynamically alter the position of the projection but even as an inexperienced programmer that is not an issue. If the devs have some competence (which I would assume given they developed this game) it should not be a problem to implement at all, except of course the issue with consoles other users mentioned. Drawing a second camera is expensive for the render engine but if not done at full resolution, unless the player is accessing the camera directly, I fail to see any issues except poor performance on low end pc"s and console, which imo is already the case so that would be a drop of water in an ocean.
you always pull the "how many of you are programers" card.But it"s true. There"s a difference between bashing some stackoverflow search results together and truly making the effort of working it effectively and efficiently into the final product. And that"s not even considering the economics of working under employment in a company that earns the money to pay you from selling the work you contribute. You may think Keen is incompetent, you may call Keen incompetent, and maybe they even are, by some measure or another, but that still doesn"t change anything about that, right here, right now, they have this much work, this much capacity, and this much market demand for this much of their products. You might not like it. Hell, they might not like it. But nobody can escape their daily need of bread on the table, and that"s ultimately what makes or breaks pursuit of any requested feature.
As can be seen in this YouTube VideoYes, but SE"s gameworlds aren"t exactly just some five polygons like in that video"s test world. I have no doubt the R&D to find out how to optimise this before even going about optimising this, and a ton of other considerations in the ecosystem of the whole game around such a camera feature, is weighing a lot heavier than just spending an afternoon or so to get the code written.
It"s still a business decision. How many more paying players could adding such a small yet challenging-to-implement-well feature as a ploppable cam feed realistically invite? Enough to warrant the effort? Likely no? Then no.
you always pull the "how many of you are programers" card.But it"s true. There"s a difference between bashing some stackoverflow search results together and truly making the effort of working it effectively and efficiently into the final product. And that"s not even considering the economics of working under employment in a company that earns the money to pay you from selling the work you contribute. You may think Keen is incompetent, you may call Keen incompetent, and maybe they even are, by some measure or another, but that still doesn"t change anything about that, right here, right now, they have this much work, this much capacity, and this much market demand for this much of their products. You might not like it. Hell, they might not like it. But nobody can escape their daily need of bread on the table, and that"s ultimately what makes or breaks pursuit of any requested feature.
As can be seen in this YouTube VideoYes, but SE"s gameworlds aren"t exactly just some five polygons like in that video"s test world. I have no doubt the R&D to find out how to optimise this before even going about optimising this, and a ton of other considerations in the ecosystem of the whole game around such a camera feature, is weighing a lot heavier than just spending an afternoon or so to get the code written.
It"s still a business decision. How many more paying players could adding such a small yet challenging-to-implement-well feature as a ploppable cam feed realistically invite? Enough to warrant the effort? Likely no? Then no.
The various LCD Panel blocks are a great way to add a human touch to a ship or base by displaying useful images or text. For LCD configuration and usage, see LCD Surface Options.
Note: Some functional blocks, such as Cockpits, Programmable Blocks, Custom Turret Controllers, and Button Panels, have customizable LCD surfaces built in that work the same way as LCD Panel blocks, which are also discussed in detail under LCD Surface Options.
LCD Panels need to be built on a powered grid to work. Without power, they display an "Offline" text. While powered without having a text, image, or script set up, they display "Online".
LCD Panel blocks come in a variety of sizes from tiny to huge (see list below) and are available for large and small grid sizes. Note that LCD Panel blocks all have connections on their backs, and very few also on a second side.
All LCD Panels and LCD surfaces work with the same principle: They are capable of displaying dynamic scripts, or few inbuilt static images accompanied by editable text. Access the ship"s Control Panel Screen to configure LCD Panels or LCD surfaces; or face the LCD Panel block and press "K".
A Text Panel, despite its name, can also display images. On large grid, it is rectangular and does not fully cover the side of a 1x1x1 block. On small grid it is 1x1x1, the smallest possible LCD block in game.
On large grid, you choose the Text Panel when you need something that has rectangular dimensions that make it look like a wall-mounted TV or computer screen. If you want to display images, this one works best with the built-in posters whose names end in "H" or "V" (for horizontal or vertical rotation). On Small grid, you place these tiny display surfaces so you can see them well while seated in a cockpit or control seat, to create a custom display array of flight and status information around you.
Corner LCDs are much smaller display panels that typically hold a few lines of text. They don"t cover the block you place them on and are best suited as signage for doors, passages, or containers. They are less suitable for displaying images, even though it"s possible. If you enable the "Keep aspect ratio" option, the image will take up less than a third of the available space.
These huge Sci-Fi LCD Panels come in sizes of 5x5, 5x3, and 3x3 blocks, and can be built on large grids only. These panels are only available to build if you purchase the "Sparks of the Future" pack DLC.
They work the same as all other LCD Panels, the only difference is that they are very large. In the scenario that comes with the free "Sparks of the Future" update, they are used prominently as advertisement boards on an asteroid station.
This LCD panel can be built on large and small grids. The transparent LCD is basically a 1x1x1 framed window that displays images and text. It is part of the paid "Decorative Blocks Pack #2" DLC.
What is special about them is that if you set the background color to black, this panel becomes a transparent window with a built-in display. In contrast to other LCD Panels it has no solid backside, which makes it ideal to construct transparent cockpit HUDs, or simply as cosmetic decoration.
While configuring an LCD Panel, the GUI covers up the display in-world and you can"t see how the text or images comes out. In the UI Options, you can lower the UI Background opacity to be translucent, so you can watch what you are doing more easily.
An organic light-emitting diode (OLED or organic LED), also known as organic electroluminescent (organic EL) diode,light-emitting diode (LED) in which the emissive electroluminescent layer is a film of organic compound that emits light in response to an electric current. This organic layer is situated between two electrodes; typically, at least one of these electrodes is transparent. OLEDs are used to create digital displays in devices such as television screens, computer monitors, and portable systems such as smartphones and handheld game consoles. A major area of research is the development of white OLED devices for use in solid-state lighting applications.
OLED is fundamentally different from LED which is based on a p-n diode structure. In LEDs doping is used to create p- and n- regions by changing the conductivity of the host semiconductor. OLEDs do not employ a p-n structure. Doping of OLEDs is used to increase radiative efficiency by direct modification of the quantum-mechanical optical recombination rate. Doping is additionally used to determine the wavelength of photon emission.
An OLED display works without a backlight because it emits its own visible light. Thus, it can display deep black levels and can be thinner and lighter than a liquid crystal display (LCD). In low ambient light conditions (such as a dark room), an OLED screen can achieve a higher contrast ratio than an LCD, regardless of whether the LCD uses cold cathode fluorescent lamps or an LED backlight. OLED displays are made in the same way as LCDs, but after TFT (for active matrix displays), addressable grid (for passive matrix displays) or indium-tin oxide (ITO) segment (for segment displays) formation, the display is coated with hole injection, transport and blocking layers, as well with electroluminescent material after the first 2 layers, after which ITO or metal may be applied again as a cathode and later the entire stack of materials is encapsulated. The TFT layer, addressable grid or ITO segments serve as or are connected to the anode, which may be