Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Important Detailed Info change in the next Major

Discussion in 'Modding' started by Filip, Oct 30, 2018.

  1. Filip Staff

    Messages:
    10
    Hi everyone,
    There will be change in the next Major release with Detailed Info from IMyTerminalBlock interface. This property will no longer be updated on server side. If you are using it in your mod or script, please, let us know what kind of information you are using so we can add it to standard Mod API.

    Update: PB will stay as it is now.

    Thanks
     
    Last edited: Oct 30, 2018
  2. Kham Apprentice Engineer

    Messages:
    467
    I read information from that using MMaster's Automatic LCDs for blocks like Solar Farms to get their current output levels, projector blocks to show their current build status/missing blocks etc. I know I use it in a few other places too but I'll have to take some time to look through all my builds to remember what else I do read from that.
     
  3. Malware Master Engineer

    Messages:
    9,032
    Good riddance. One should not be parsing Detailinfo in scripts to get info, it's both slow and usually causes memory allocation. Don't ask to get this back, ask to get the relevant info exposed.
     
    • Agree Agree x 1
  4. MMasterSK Trainee Engineer

    Messages:
    58
    Would it be possible to let in-game scripts read the DetailsInfo on servers? In-game scripts run on server anyway so they don't need data to be sent to clients.
    Reason for this is:
    It is not reasonable to expect in-game script like Automatic LCDs to be able to interpret data from all mods out there. I need to let mods interpret their data and pass string that makes sense to player which I can then display on LCD .. which is essentially what Details Info was used for. Any replacement will have similar behavior to Details Info it will just be done in some different obscure way that was originally not intended for this use. I would hate Custom Data to be used for this as that one is synced to all clients.

    Also In-game scripts use "Echo" that writes text to Details Info - how would this behave after the change? Would the clients not see the Echo-ed text?
     
    Last edited: Oct 30, 2018
  5. Filip Staff

    Messages:
    10
    PB will have detailed info like before, no change there so Echo will work. Other blocks will not update Details Info on server. That property will be empty.

    @MMasterSK do you have any script that is parsing some data from Details Info?
     
  6. Hemp Plan[e]t Apprentice Engineer

    Messages:
    156
    I use Detailed info on vents i want to read pressure also if they're disabled, since you can't GetOxygenLevel() when turned off and there is no vent idle state
     
  7. Malware Master Engineer

    Messages:
    9,032
    That's technically a bug though. It doesn't make sense that you should be able to read pressure on a device that's disabled (provided, that is, that you're talking about ingame scripts). DetailInfo should be empty on a disabled device
     
    • Agree Agree x 1
  8. Hemp Plan[e]t Apprentice Engineer

    Messages:
    156
    Yes it's pretty bad to do it this way, but i found no other way to read pressure without depressurize/pressurize same time :/
     
    • Like Like x 1
  9. Gwindalmir Junior Engineer

    Messages:
    999
    Mods can expose their own information to PB via terminal properties. That's the "proper" way to do it, and how modders should be exposing their mods for interactivity with PBs.

    What about Mods that set CustomInfo (which wraps around DetailedInfo) property? Are they going to require client-side code? Not sure if they already do require it.
    Frankly, I'd like to see CustomInfo vanish, and mods directly edit DetailedInfo, as right now there's no way to remove vanilla information (modded blocks).

    EDIT: Also, thanks for the heads up on this!
     
  10. Malware Master Engineer

    Messages:
    9,032
    Oooh, I see what you're after. You want a "do nothing" state for the air vent, something that doesn't try to modify pressure - just shows the current status. That would actually be quite useful, I agree - even for non-scripting use.
     
    • Friendly Friendly x 1
  11. MMasterSK Trainee Engineer

    Messages:
    58
    @Filip not exactly parsing. Just taking whatever is there and showing it on LCD. So mods can put output in user readable format there and automatic lcds doesn't need to understand it but can still display it on LCD that supports scrolling in between other stuff.

    @Gwindalmir as I tried to explain it is physically impossible (seriously) for script like Automatic LCDs to understand properties of every mod out there. That's why stuff like DetailedInfo makes sense because it gives mods standard way to display player understandable text that can then be displayed for example on LCD (without any special parsing). It's probably the only reasonable and proper use case for DetailsInfo text that I can think about. Yes mods can do the same thing and expose stuff through StringBuilder property that will behave exactly like DetailsInfo does today which is counter productive in my opinion. It would be much better to refine DetailsInfo to be effective for its use case rather than letting modders do it their way which may end up much worse. That's why I propose to make Details text server side only.

    My point is: removing one thing for performance reasons doesn't solve anything when people then implement the same thing again in some other way that may be even worse performance wise than the original thing.
     
    • Agree Agree x 3
  12. Digi Senior Engineer

    Messages:
    2,335
    That's how it works already, detail/custom info is not sent over the network.

    @Filip
    The property should only be updated on demand (with a cooldown or a flag that gets tripped when it needs re-updating on next call) regardless of client or server side.
    If you also want to break old scripts that parse detail info for data, then rename the property or replace it with a method that takes a StringBuilder arg (would be less string allocations too).
     
  13. TheWarMaster97 Trainee Engineer

    Messages:
    9
    I use "max jump distance" for the jump drive, please add this in the mod api, thanks.


    I would also love this, or some other way to check pressure without actually pressurizing/depressurizing.
     
  14. Malware Master Engineer

    Messages:
    9,032
    It is important that you specify mod API or PB API. Those are two very different things.
     
  15. SileniusFF Trainee Engineer

    Messages:
    95
    This probably doesn't qualify as scripting but just in case.
    I use Easy Automation 2.0 by Coren (sort of meta language for mere mortals without c# skills)
    which among other things parses Detailed Info and enables to use its value in EA code.

    Most common uses in my creations:
    rotor current angle, piston current position, tank fill level, air vent pressure, battery power storage, block power usage, solar panel output, landing gear lock state etc.

    Although i realize that parsing text isn't performance friendly and not "proper" way,
    it is a bit sad news to know that it prevents some of the stuff working in servers.
    But then scripts will most likely stay in experimental mode anyway and their use in MP will always be risky endeavor.
    Good news is that SP wont be affected and i can continue my tinkering ;)
    ------
    Edit: Just quick addition: it seems that something has already changed with rotors
    Detailed Info in SP - they often don't show any info at all. Changes, changes...
     
    Last edited: Nov 5, 2018
  16. Digi Senior Engineer

    Messages:
    2,335
    All of those things have interface properties, if the script uses detail info to get that data then it's horribly inefficient...
     
  17. Sarithule Trainee Engineer

    Messages:
    48
    Hi, I am Coren, author of Easy Automation 2.0.

    To answer Digi as to why I am parsing Detailed info Instead of using the interface properties, it is because doing so requires that the block in question be cast to a specific type before the interface becomes available. This would involve checking to see what type of block we are dealing with every time from a list of all available blocks... now that is inefficient, especially when the script can possibly be cycling every frame, for instance if it is taking a value from a block and displaying it on an LCD every frame. It would also require that I update my script every time keen adds a new block or changes something.

    Since my script is built to be able to deal with any type of block on the fly without needing to determine what that block type is every time (This allows keen to add new blocks and new properties without me having to change my script and it will automatically work with any new additions), the removal of Detailed info without making the info it provided available to be pulled from a block without needing to cast it, puts a wrench in the whole works of what my script is capable of doing.

    My script is also capable of finding and using the Actions and Properties of blocks without the aforementioned casting but a lot of the information necessary such as rotor "Current angle" and piston "Current position" is not connected to one of those and is not made available in a way that allows for viewing without casting except for parsing Detailed info. Detailed info was the only way to grab this info on the fly.

    Detailed info was Easy to parse as it rarely changed how it presented its information (information name, then a comma, then the value). This allowed me to create a generic set of parsing rules that would grab information from any block without needing to worry about what type of block that information was coming from.

    It saddens me to see that detailed info will not be updated, this will severely limit what is possible in Space engineers in-game scripting if another avenue to block information is not provided that dose not require the knowledge of block type.

    P.S. Thanks to SileniusFF for bringing this to my attention
     
    Last edited: Nov 7, 2018
    • Disagree Disagree x 1
  18. Malware Master Engineer

    Messages:
    9,032
    I have a very hard time believing that casting and checking is less efficient than string parsing and the allocation that usually follows from that. Type checking and casting is very fast. Using terminal actions and properties is also much less efficient than using their interface equivalents. I am sorry, but these things have been considered bad for scripts for quite some time already. Especially for scripts that run very often. As for adding new blocks or changing something, that hardly ever happens so that's not really an issue. Sure, it may happen now and again, but the number of breaking changes so far can be counted on one hand. Actually I'd wager its more likely for the Detailinfo to change than any new block interface or breaking change to happen.
     
    Last edited: Nov 7, 2018
    • Agree Agree x 2
    • Disagree Disagree x 1
  19. Sarithule Trainee Engineer

    Messages:
    48
    Take into consideration that this script is fairly old. back in the day Keen was coming out with new blocks and functionality nearly every other week. Also This script will work with any new blocks that modders might add, something that I could never keep up with. In essence I was attempting to get around the problem of requiring a list to check that could become obsolete due to decisions made that are outside my influence. Detailed info did this beautifully. The parsing also did not cause any noticeable effect on the game in terms of slowing it down (i am using StringBuilder). I have had multiple instances of my script running every frame without the sim speed taking a hit (back before programing blocks scripts running were parsed out between frames).
    Why chase efficiency if it has no noticeable effect?
    In essence the benefits out weighed the negatives over the years that I have been up keeping this script.

    If Detailed info Is going, I would like something that allows in game scripts to view information about blocks without needing to understand what type of block is giving the information. This will allow Keen and modders to add what ever they want while not having to worry about compatibility.
     
  20. Malware Master Engineer

    Messages:
    9,032
    Because your script is going to be used on multiplayer servers so every little piece of improvement you can get helps :)

    You won't be noticing much with a single script - or even a few instances - running on a single machine, I'm sure. But take this script and add all the other scripts and mods people are using, on a multiplayer server and everything starts counting a lot more. Memory allocation hits won't be measurable immediately, because that affects the garbage collector, eventually causing small hitches in framerate. Casting and using members directly will be orders of magnitude faster than processing a string and parsing various values. This is an undisputable fact.



    Oh, I understand your point of view here, don't you worry. However, I also understand Keen's point of view. Removing the server side processing of DetailInfo will remove extra processing of thousands of blocks on the server, which helps increasing server performance. Which is more important, a slight inconvenience in a programmable block script, or increasing the performance of the servers? :) I'm sorry, but I understand their choice quite well. This is beneficial to far more people than your script is, despite its popularity. You know, like Spock's proverb. "The needs of the many outweigh the needs of the few - or the one" :)

    They're not doing this lightly. They've always been very careful not breaking scripts, even more careful with programmable block scripts than mod scripts. None of the breakages that has happened has been without a good reason. This is no different.



    Modders can already add extra stuff through terminal properties. Those are also already the feature you're asking for. Maybe they'd consider adding some more readonly values there, although people should generally avoid using them in scripts if they can because of their overhead.
     
  21. Sarithule Trainee Engineer

    Messages:
    48
    I understand keens point of view as well. I am all for better servers. I am super impressed with the improvements they have made to them! I remember the days when asteroids would eat my friends and clients would see objects spazzing all over the place.

    If detailed info has to go for better servers, then so be it. I just wish there was a way to expose that information in the way that detailed info did so I can have a script that is as generic as possible and that is able to deal with new blocks and situations that keen and modders produce without needing to update it. I'm a lazy programmer :)

    If there was a generic interface that all blocks shared that could store references to a blocks information like how it's done with properties and actions, that would be awesome!

    Can I find the properties of any block without having to cast it?
    Yes
    var block = GridTerminalSystem.GetBlockWithName(blockName);
    var properties = new List<ITerminalProperty>();
    block.GetProperties(properties);
    YAY!

    Can I find the Actions of any block without having to cast it?
    Yes
    var block = GridTerminalSystem.GetBlockWithName(blockName);
    var actions = new List<ITerminalAction>();
    block.GetActions(actions);
    YAY!

    Can I find the information in a block like "Current position" or "Current angle" without having to cast it?
    No
    ???
    var block = GridTerminalSystem.GetBlockWithName(blockName);
    var informations = new List<ITerminalInformation>();
    block.GetInformation(informations);
    ???

    could this be done?
    This would mean that the server would only have to update the information for those blocks that have had it requested instead of updating all blocks all the time.
    A nice compromise which would give great server benefits while also allowing for scripters to access block information generically and without the need to parse a string.
     
    Last edited: Nov 8, 2018