script timer memory question

[kelly1111]

Does running this with a timer set to 1 have any impact on performance .. or is it neglible ? I mean when the timer keeps on running?

function time()
local x = math.floor(GameMode.getTimeOfDay()%1*12)

for i=0, 11 do
if i == x then
findEntity("clockPit"..i).door:close()
findEntity("firefly"..i).light:fadeIn(10)
findEntity("firefly"..i).particle:fadeIn(10)
else
findEntity("clockPit"..i).door:open()
findEntity("firefly"..i).light:fadeOut(10)
findEntity("firefly"..i).particle:fadeOut(10)
end
end
end

[akroma222]

I don't think it would (I have not tested though)

However you could/should add:
currentLevelOnly = true, to the timer

and/or you could run a script that checks to see if the party if within the area in question first,
then if they are you can do you TimeofDay and findEntity stuff (only when necessary)
IIRC findEntity() isnt as taxing as allEntities() on performance - but may as well not if you dont have to

SpoilerShow

Code: Select all

function time()

if not checkPartyWithin(xMin,xMax,yMin,yMax) then		--enter in the search area
	return
end

local x = math.floor(GameMode.getTimeOfDay()%1*12)

for i=0, 11 do
if i == x then
findEntity("clockPit"..i).door:close()
findEntity("firefly"..i).light:fadeIn(10)
findEntity("firefly"..i).particle:fadeIn(10)
else
findEntity("clockPit"..i).door:open()
findEntity("firefly"..i).light:fadeOut(10)
findEntity("firefly"..i).particle:fadeOut(10)
end
end
end


function checkPartyWithin(xMin,xMax,yMin,yMax)
	for x = xMin,xMax do
    	for y = yMin,yMax do
        	for entity in party.map:entitiesAt(x,y) do
            	if entity == party then
                	return true
                end
            end
        end
    end
    return false
end

[Mysterious]

Hi what does this mean or do:
local x = math.floor(GameMode.getTimeOfDay()%1*12)

I assume this checks to see it the party is in a square?
if not checkPartyWithin(xMin,xMax,yMin,yMax) then --enter in the search area
return
end

TY

[Isaac]

Hi what does this mean or do:
local x = math.floor(GameMode.getTimeOfDay()%1*12)

This assigns to the variable x, the value of the current in-game time of day, converted to hours. The value will be 0-11, depending on the in-game time of day.

[Lark]

Of course, you could always fall back on Pythagoras and calculate the distance between the party and whatever object, such as the script, and test to see if you're within the distance you wanted:

if math.sqrt((party.x - self.go.x) ^ 2 + (party.y - self.go.y) ^ 2) > 6 then return

But this might use more processor... it might be worth a test. It has the advantage that you don't need to define the boundary box (minimum and maximum coordinates) around anything, just the distance, so it's more portable. Of course, it defines an equidistant "circle" around the place of interest. If you want an offset rectangle, for example, you could still define your boundary box and use one logical test like:

if xMin > party.x or party.x > xMax or yMin > party.y or party.y > yMax then return

Cheers, -Lark

[EDIT] There's no real benefit in performing the square root operation - just square both sides of the equation for less in-game mathematical operations and you get:

if (party.x - self.go.x) ^ 2 + (party.y - self.go.y) ^ 2 > 36 then return

This will return if the party is not within 6 linear squares of "self". If you want 7 squares, compare it to 7 * 7 or 49 and so on.

[minmay]

72 string concatenations every 1 second is fine. There is nothing to worry about here.

akroma222's script is slower because of the number of entitiesAt calls. If you want to check the party's position (or any other object's position), check the object's x and y fields instead of looking for it in every square.

Generally if you are worried about the performance of a piece of code, you should profile it instead of guessing, otherwise you might end up accidentally writing something that's more complex and slower...like akroma222 just did.
In Grimrock, under normal circumstances, there is only one place where you are likely to encounter Lua performance issues: applying a complex operation to a large number of objects. Map:allEntities() and Map:entitiesAt() in Grimrock 2 are actually quite fast in themselves; you can iterate through 5000 GameObjects very quickly if you don't do anything to them. But for example, if you try to go through every GameObject in the level, check it for ModelComponents and call ModelComponent:updateLods() on all of them, you'll likely encounter a noticeable delay.
Note: entitiesAt() has a relatively high setup cost. If you need to check objects in more than about 50 squares, it is often faster to use Map:allEntities() than Map:entitiesAt().

findEntity() is fast. Much, much faster than getting the object with allEntities() or entitiesAt(). In fact, when you do this in a script:

Code: Select all

party:getWorldPosition()

it is equivalent to:

Code: Select all

findEntity("party"):getWorldPosition()

(unless you defined another variable named "party" in the script)

[Komag]

I've been learning to deal with performance issues while working on my Roku project (a cross between Grimrock and old-school 2D Zelda). Roku models vary widely in processing power too, so I have to accommodate that. I too have found that anything within a large loop, such as checking every column of every row on the dungeon grid, can take something that would normally take just 1 millisecond or less, and turn it into 100ms or more if programmed badly.