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.

Help creating a basic status checker script

Discussion in 'Programming (In-game)' started by SirConnery, May 11, 2019.

  1. SirConnery Apprentice Engineer

    Messages:
    129
    I'm trying to create a script that is simply this:
    if connector is unconnected > play soundblock once.

    The problem is that it keeps starting to play the sound over and over again if I do it by updatefrequency100.

    I didn't find anywhere in the API (https://github.com/malware-dev/MDK-SE/wiki
    /SpaceEngineers.Game.ModAPI.Ingame.IMySoundBlock) how to check if whether the "play sound" on the soundblock is true. From looking at it I don't think it can be done.

    I guess I should try to check if some other variable is true if play() function cannot be checked?

    I have very basic programming knowledge but am willing to learn.
     
  2. DMOrigin Trainee Engineer

    Messages:
    10
    There is no way to do this over the Mod API. I'm not familiar with the sound block, but if I look over the functionality I don't see any functionality to do this. The whole block is inconsistent and curios. There is a list of sounds. Some of this sounds allow to setup a loop period. Some not. But it isn't possible to see which sounds allow which configuration. The whole block needs a complete rewrite. I don't know why it is not possible to ask is something is playing. Every Sound API knows which Sound Buffer is currently playing. Maybe someone who has more experience with the sound block will drop by.

    So, you can try to use deeper API's or you need to do this job by your own. In this case we need more informations what you want to do.
     
  3. SirConnery Apprentice Engineer

    Messages:
    129
    Yeah, that's what I figured. Could it be possible to use the
    Runtime.UpdateFrequency |= UpdateFrequency.Once;

    And tie this one event tied check (as I understand it) to the Connector becoming unconnected? This would stop the looping.

    Right now I'm unsure.
     
  4. DMOrigin Trainee Engineer

    Messages:
    10
    I don't know what you want to construct. The best way to help you is, that you explain what you exactly want :)

    The UpdateFrequency is a flag that allows you to setup how often the Main method is executed by the game. "Once" mean, that this method is called only one time. If you have a Connector (I think you mean a Ship Connector Block) that you want to monitor, then Update100 is a better way to do that. Or, you control all over a button. In that case you don't need an automatic update. Set it to "None". Because, every time you execute the pb over the "Run-Bottom" directly or over a button the Main method is also called. On which way the main method is called is stored in the second parameter of the main method: https://github.com/malware-dev/MDK-SE/wiki/Sandbox.ModAPI.Ingame.UpdateType

    Code:
    Program()
    {
      Runtime.UpdateFrequency = UpdateFrequency.Update100;
    }
    
    void Main(string arg, UpdateType updateSource)
    {
      if ((updateSource & UpdateType.Update100) != 0)
      {
    	// Do something on automatic update
      }
    
      if ((updateSource & UpdateType.Terminal) != 0)
      {
    	// Is called during a click on the "Run-Button" of the PB.
      }
    }
    
    As a little example.
     
  5. SirConnery Apprentice Engineer

    Messages:
    129
    Thanks for explaining how the UpdateFrequency "once" method works, seems I was confused.

    I would like a ship to play a Soundblock when it's Connector unconnects. I was able to do this but since the UpdateFrequency can't check if a Soundblock is already playing it just keeps starting to play the Soundblock again every few seconds. Which is not what I want.
     
  6. DMOrigin Trainee Engineer

    Messages:
    10
    In this case, you don't need to check if a sound block is playing currently. My first step would be to set the update frequency to 100. Than, in the constructor find the connector and save the current state. In the Main method check the state of the connector and if that state is switching from "Connected" to "Unconnected", then play a sound. Maybe an alert. Set the loop period to a value of.. i don't know.. 6sec or so, and save the time you call Play() as a DateTime (DateTime.Now). Now you can check if a sound is playing. The last step is a workaround. But I think it works. This is not tested. I can't do that at the moment.
     
  7. Malware Master Engineer

    Messages:
    9,404
    Fair warning. DateTime is not reliable in non-optimal simspeed situations. It will return the wrong value as the game time will differ from wall time. It shouldn't be used for timing. Use TimeSinceLastRun for game-accurate timing. A little cumbersome I know but it's all we have for now.

    @SirConnery I strongly recommend going to the programming-in-game channel on Keen's discord. You'll get a lot of help there.
     
    Last edited: May 15, 2019
  8. DMOrigin Trainee Engineer

    Messages:
    10
    In which way DateTime becomes unreliable? You mean, that DateTime use a less precision as the Stopwatch object. That is used to track the ticks. Then, it's right :)

    But, I don't think that this is relevant in this situation.
     
    Last edited: May 15, 2019
  9. Malware Master Engineer

    Messages:
    9,404
    @DMOrigin No. I mean that DateTime uses wall time, while the game time stretches out when simspeed changes. For example, on 0.5 simspeed, one second for anything in the game is two seconds wall time. Which means that you will get the wrong measured time for in-game operations. I specifically designed TimeSinceLastRun to work with ingame time for just this reason. I also have a timing patch waiting to be merged, with a proper game-time aware StopWatch equivalent, which would make all this easier, although I don't know if it will be at this point.
     
  10. DMOrigin Trainee Engineer

    Messages:
    10
    I didn't know what you mean with "wall time" ^^ But yes, if the game scales the result with the simspeed, then the usage of DateTime becomes problematic in some cases. That's good to know :D