FOSS gamedev and creative worlds

any way to idk fix this or works around it...

no my computer is not slow either :) thats what alot of this has been blamed on... is there more information about what this does or means?

my computer-> 2 physical processors 4 cores each at 3ghz, 64gb of ram, 4gb video memory, only running minetest server and client.

when it does this it really messed up my mod... puts blcks back that have already been mined.

I question the loop in the block of code this warning comes from

https://github.com/minetest/minetest/bl ... .cpp#L1166

It looks to me like there would be instances where that loop would keep running ABMs on active map blocks until it ran for 200ms. If you remove the loop ABMs work fine from my testing and the warning disappears.

I don't think so, the bit that is timed is here: https://github.com/minetest/minetest/bl ... 1173-L1198

It's the time for all ABMs to run.

But the only time the Do..While is broken out of is if m_active_block_interval_overload_skip > 0 and m_active_block_interval_overload_skip is only changed in that loop when the timer is over 200ms unless I'm missing something.

Plus it loops through all active blocks twice in this section, once for node timers and once for ABMs, can't they both be handled in one loop through the active map_blocks?

So it looks like nothing changed recently performance wise, they changed this warning to using warningstream instead of infostream.

hold up... does this mean the game kills the abm if it runs too long... becasue if so i found my bug :) i been beating my mod code to death for this one specific error where it is breking bricks and all the sudden just misses one section... and if minetest kills the abms becasue they were too slow this would be the result.

it does it most after i run the code a few times. not instantaneously. when you have an abm remove 100x100x100 blocks its gonna take more than 200ms especially if the loop repeats until the machine is out of fuel...

No it shouldn't cut the ABM short. I think if all the ABMs for the active blocks take more than 200ms then it starts skipping ABMs on the next pass through.

BrandonReese wrote:But the only time the Do..While is broken out of is if m_active_block_interval_overload_skip > 0 and m_active_block_interval_overload_skip is only changed in that loop when the timer is over 200ms unless I'm missing something.

That's a "do {} while(0)". Doesn't that mean it never repeats?

duane wrote:That's a "do {} while(0)". Doesn't that mean it never repeats?

Yep you're right. That's what I was missing. Makes a lot more sense now.

soo... the short answer is change code, recompile and call it a day?

Look at the changes I've made with my Adventuretest client. I've noticed considerable performance improvements with the changes I made in environment.cpp. I'm still testing it to see if there are any adverse affects.

https://github.com/Bremaweb/adventurete ... onment.cpp

ill compile it tommorrow and run it. maybe i wont have to move all my world stuff (probably will though)

got around to it a little later than i thought. my tests indicate both a solution and a problem. in your version of the client, i dont ever get the error about the abm taking too lon just now when it takes too long the server never comes back. you end up trapped in a invisible box because it cant generate the map (or update the client to tell the user things have changed) other than that your very right it feels alot smoother than the default client. lots less lag to me any how. i think if all holds out correctly i am just gonna change my code to use another method that doesnt involve an AMB. i can watch it in the console, in about 3 seconds it is done, but the game doesnt respond for 2 to 5 minutes. sadly it is looking like i will have to slow my code down to meet the speed of minetest.. kind of like when you move too fast and minetest resets you and you walk the same 5 blocks 15 times. :)