![]() Miscellaneous Functionġ This will still buy staff one at a time but at an accelerated rate which is much faster that clicking for each individual member of staff.Ģ (when multiple objects are in a single square)ģ You must enable Screenshot Mode in the Game Options Developer Tools Left-click prisoner's name under his profile picture Reports / views FunctionĮscape Mode Function This can also be used to cancel jobs, planning walls, material placements and room designations. in the menus (such as objects menu)ġ Hold the right mouse button and drag the mouse to draw a selection box that you can use to cancel multiple objects with. Job: Follow the working entity / Flip / Mirror Cloned AreaĬycle through objects, items etc. ![]() As for the int counter, in lua 5.Also called keyboard shortcuts or hot-keys. Not sure I fully understand your last point, think I am getting lost in the pronouns. Though if you are using an int counter, then math.random(750, 1250) is better then mathing out a non int delay. So if the update delays need to correspond with game time it is best to use elapsed, though I can think of several cases which this wouldn't matter and your int counter might be slightly more optimized. In my testing the elapsed was ~0.03 at 1x, ~0.06 at 2x, and ~0.15 at 5x. Your 40m increments will be 80m at 2x and 200m at 5x game speeds. Honestly any bit of delay randomization is loads better then none at all.Īs for int values, you increment 1 each update, which means your DoStuff function will run less time ever game hour the faster the game speed is set. Of course this could also be prevent by picking a better random formula. That can also work but I prefer re-randomizing on each full update to remove the possibility of an inited delay coinciding with a brief downtime in an objects work cycle. But im thinking that the incremented int-values should be faster, then calculating and comparing doubles. The most disadvantage is like its best advantage, As more objects you have, as less often the code will be run. Or why not using just simple integer values, that also would prevent running all Updates at once after pause mode. Trixi wrote:what about making the delay random at initalisation This triggers DoStuff every 5 - 15 game minutes regardless of game speed and spreading the load around to prevent hitches. So by keeping a running total and using the optimizations I attempted early we come up with a much cleaner way of doing this. ![]() These TU(time units) translate into 2 per game minute. Conversely, the faster the game speed, the less DoStuff will be triggered per game hour.Īlso the value that gets returned is cached and only seems to recache when at least 50ms have pasted which is obviously an optimization of PA that messes with my optimizations.Īll in all Game.Time() is not the correct way of going about this.Īfter further tested I realized that the Update function gets passed a param of game time units since last update. So after a long pause all your Do Stuff functions will trigger instantly on an un-pause. Your object doesn't need updating dozens/hundreds of times a second, in fact it probably only needs updating every 5 seconds (5 prison minutes) or so in most cases.Īt least that is all in theory, but as I tested it all I found some issues.įirst off is that Game.Time() returns time played in real world seconds which counts at a steady rate regardless of game speed. The only code you should put in Update() is something to check the amount of time since the last Update() otherwise you're just wasting CPU cycles. The Update() function is called dozens, if not hundreds, of times a second. Things may be different on other operating systems, but on a Mac I seem limited to the in-game debug window for now. I've searched the disk for other debug.txt and found none, and can't find any other logs that seem related to PA. This means, as far as I can tell, you can only debug one script at a time - whichever script most recently threw an error.Īpparently the debug output should also appear in debug.txt in the main PA folder, but on a Mac at least this does not work. The next interesting thing about the debug window is that it's scoped to the first script that makes it appear. Put print() right down at the end of the script, because it will throw an error and Lua will not run anything past that point in the script. Print() - this will throw error and open debug window Code: Select all - define any locals, etc., hereįunction log(s) Game.DebugOut(tostring(s)) end
0 Comments
Leave a Reply. |