Tutorial: Runtime Information

The Runtime

The Runtime property provides you with information about the current runtime environment of a programmable block. The values provided are:

Code:

        /// <summary>
        /// Gets the time elapsed since the last time the Main method of this program was run. This property returns no
        /// valid data neither in the constructor nor the Save method.
        /// </summary>
        TimeSpan TimeSinceLastRun { get; }

        /// <summary>
        /// Gets the maximum number of significant instructions that can be executing during a single run, including
        /// any other programmable blocks invoked immediately.
        /// </summary>
        int MaxInstructionCount { get; }

        /// <summary>
        /// Gets the current number of significant instructions executed.
        /// </summary>
        int CurrentInstructionCount { get; }

        /// <summary>
        /// Gets the maximum number of method calls that can be executed during a single run, including
        /// any other programmable blocks invoked immediately.
        /// </summary>
        int MaxMethodCallCount { get; }

        /// <summary>
        /// Gets the current number of method calls.
        /// </summary>
        int CurrentMethodCallCount { get; }

The TimeSinceLastRun property is replacing the ElapsedTime property directly in MyGridProgram, which is now obsoleted (not removed, not yet).

Example code:

Code:

public void DoSomethingReallyHeavy() {
	if (Runtime.MaxInstructionCount - Runtime.CurrentInstructionCount < 25000) {
		// I know I need at least 25000 instructions to run this script, I don't have that much left
		// so I'll wait for the next tick.
	}
	// Do Heavy Loop
}

 

KNOWN ISSUE:

Unfortunately a slight bug crept into this first version: The TimeSinceLastRun (and by extension the old ElapsedTime) is affected by a Save.

 

1200 off 50000 instructions and 400 of 10000 methods. My scripts have to get bigger

 

Is TimeSinceLastRun in game time or in 'real wold' time? In other words. is it effected by simspeed?

Does that mean the 'intial' time will be very large? Or will it be zero?

 

It's just ElapsedTime moved: Supposed to be game time, but not really working. I think I have found a solution to that too though, to be released with the mentioned bugfix (maybe, hopefully, next week? I can only hope). However since multiplayer changes so much these days I can't guarantee anything.

The bug I speak of means that TimeSinceLastRun will view a Save as a "last run", something it's not supposed to. That one is definitely fixed

 

So, at present, the most reliable method for knowing how much simulation time has passed is still to tell the Program to Trigger Now a Timer Block that's set to Run the Program, and just assume that 1/60th of a second has passed?

 

1/60th....Or other known game time; I use a 1 sec timer.

Sounds like that is what malware is saying.

 

This might seem trivial but my question is are these parameters man made limit or a runtime indicator? With proper tuning, it seems possible to make programs that will never slow down sim speed, and that is why its kinda important to know what exactly these numbers mean.

 

These parameters are the limits that have been imposed on the programmable block specifically, since day one. The max values have been determined by Keen, the count values are the actual values used by the game to limit impact. Helping to split bigger tasks over several ticks is exactly why this was added.

 

I'm afraid so. Also I'm curious to see what the mp update does to the solution I have... I will probably need you guys' help if/when it's released as I have limited ways to test multiplayer with simspeed issues properly. It seemed to work right before this update, we'll see.

 

This is very nice. would it be possible to correlate the line number a program failed on from this information so that finding a runtime error would be easier? like those pesky index out of range buggers?

 

Sorry, there's no correlation. The information is simply not there, nor should it be because it would add performance pressure. These counters need to be as simple as possible.