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.

initialization vs. destroyed blocks

Discussion in 'Programming (In-game)' started by hellokeith, Dec 19, 2016.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. hellokeith Apprentice Engineer

    How does your script handle one or more of the blocks of script interest getting destroyed?
    Do you get the blocks only at initialization, to save memory?
    Are you ok with the script likely erroring out when one of these blocks is destroyed?
    How do you handle one of the blocks of interest being destroyed on purpose and rebuilt (relocation for example)?
  2. Lynnux Junior Engineer

    - Remove damaged blocks before accessing them.
    - Keep state.
    - Reinitialisation on adding blocks.

    This even allows to run the script while building/repairing without the need to recompile.
    Look for the Ackermann steering script (advanced version) here in the forum for details.
  3. Georgik Apprentice Engineer

    The destroyed blocks still live in PB script, but action applied to them do nothing.
    Storing blocks during init is not good for my use, I refresh them at some compact rate. (Getting blocks is not so perfomance heavy.)
  4. Ronin1973 Master Engineer

    Destroyed or missing blocks will throw a null. So just check them before accessing. A learned a trick from Whiplash to just put a question mark after the variable and it will check for null and not execute. It's easier than a bunch of if statements.
  5. Georgik Apprentice Engineer

    Hm, I tried it again, and block's instances stored outside Main function are still accessible even after the real blocks were destroyed/removed. They are not null, no exception. Also applying actions works.
    They are null only when they are not found by GridTerminalSystem.
  6. Lynnux Junior Engineer

    In the past destroyed blocks accessed by scripts could even crash the game. Possibly the new compiler and updates prevent this now. But I wouldn't take this for granted.
  7. mric Trainee Engineer

    Be aware that variables in a script are not a representation to blocks in game. They are just “soft links” or addresses to those blocks.

    Similar to when you send a mail to someone, you use his address but if he moved your mail will never reach.

    It is your responsibility as the developer to code checks and make sure your code is resistant.

    Also it will be helpful to you to understand a script does not run continuously. It is executed a limited number of time per second. The fastest is once every 1/60 sec I believe.

    Also between 2 script executions the game runs the rest of the game : you move your character, physics (ships moving, crashing ?), building, IA, interface…

    I do not think the world state can create / delete blocks at the same time a script is running (I believe those 2 tasks are not in parallel). But between 2 execution of a script you may have added or deleted a block.

    And the script does not know unless you code this.

    Basic way to program would be as follow (pseudo code). Of course there are much better ways to do.

    Const string myBlockName = “name in interface”; // make sure a block has this name

    IMyTerminalBlock someBlock;

    Main() {

    someBlock = GridTerminalSystem.GetBlockWithName(myBlockName);

    if ( ! someBlock ) Do stuff …

Thread Status:
This last post in this thread was made more than 31 days old.