[Bugs] Moth Lamp


simplex

Recommended Posts

the preview doesn't fix the stutter, it starts at the end of the first static cycle but after that it seems to be its own independent thing

Are you positive it's triggered by the end of the first static cycle? I never noticed that. And it started happening before static was implemented.

Wasn't Ipsquiggle on a 1 week vacation? :/

Link to comment
Share on other sites

  • Developer

@simplex @debugman18 any ideas about this?

Sorry I didn't explain the problem well enough.  At some point Spriter detected two files in your folder called 'pngB5e.png' and 'pngF17.png' which are probably temporary file names which were created while pngs were actually being copied to your folder and your Spriter file is now referencing them.  They don't really cause too much harm other than the 'Don't Starve' pipeline considers missing images an error which is the spew you get when starting the game.  Unfortunately I don't see how to cleanup unused references in Spriter so the easiest solution right now is probably to add some placeholder pngs to the 'sky_octopus' folder.  Someone could also write a script to clean up the Spriter file but I won't have time to do that anytime soon.

 

My suggestion for right now is to save two placeholder images in the 'sky_octopus' folder called 'pngB5e.png' and 'pngF17.png' and try to avoid copying pngs to your spriter folder while Spriter is open.

Link to comment
Share on other sites

  • Developer

@Cheerio

@Craig_Perry

@debugman18

Since the Spriter save format is just XML, what I did was comment out the references to the missing/temporary files in sky_octopus's build.scml. As long as Spriter doesn't impose that file ids must be contiguous, it should work. Let me know if that's the case.

I think it does.  That's what I had first tried and then Spriter crashed opening the file :(

Link to comment
Share on other sites

I think it does.  That's what I had first tried and then Spriter crashed opening the file :(

Bleh.

Ok, so I removed the references while keeping the file ids contiguous (by renumbering them). What I did was fix the file declaration header manually, and then passed the .scml through this (using IO redirection):

local holes = {	14,	18,}table.sort(holes)for l in io.lines() do	io.write((		l:gsub('file%s*=%s*"(%d+)"', function(n)			n = tonumber(n)			for i=#holes, 1, -1 do				local hole = holes[i]				assert( n ~= hole, "There's something in hole #" .. hole .. "!" )				if n > hole then					n = n - 1				end			end			return ('file="%d"'):format(n)		end)	))	io.write "\n"end
I'd usually use Perl for this kind of thing, but I am in a Lua mood. :razz:

If it still doesn't work, I'll do it properly using a XML parser, in Perl.

I replaced the build.scml in the git repo with the (hopefully) fixed one. The old version was backed up as old_build.scml.

Link to comment
Share on other sites

@simplex

@Cheerio

 

I've isolated the stutter bug. It occurs more or less at the time static begins. The entity count begins to increase, and doesn't seem to stop, more than doubling in a short period of time. I believe this is the source of the stutter. (Entity count going from 7.5k, to upwards of 20k).

 

Edit: In addition, the 'lua memory' increases to upwards of 100k. It seems to fluctuate along with the stutter.

Link to comment
Share on other sites

@simplex

@Cheerio

 

I've isolated the stutter bug. It occurs more or less at the time static begins. The entity count begins to increase, and doesn't seem to stop, more than doubling in a short period of time. I believe this is the source of the stutter. (Entity count going from 7.5k, to upwards of 20k).

 

Edit: In addition, the 'lua memory' increases to upwards of 100k. It seems to fluctuate along with the stutter.

I had an inkling it was static related a while back... but my active entity count never got that high when I did it

 

if it was just entity count as a whole and not active Im going to feel so bad about this :/

Link to comment
Share on other sites

I had an inkling it was static related a while back... but my active entity count never got that high when I did it

 

if it was just entity count as a whole and not active Im going to feel so bad about this :/

As a whole. :p The awake entities don't seem to fluctuate too much. No worries. I don't know what's causing it, however. (As in, I don't know if the static cycles themselves are doing it, or if it's an issue with charged states.) @simplex said that it appeared before static was added, but the entity count / lua memory seems to indicate otherwise. Aside from that, we're reaching entity levels that are nearly three times those of the overworld. Even if this isn't the cause, it certainly exacerbates the issue.

 

Also, an FYI for our testers, there is a now a development branch that differs from the master branch. This branch is used to test things that are buggy or incomplete, that we don't want just anyone using. (Think nightly builds.) Currently, the new biome changes, and biota testing, are in the latest development commits. This doesn't mean much at the moment, but when alpha rolls around (soon), we can keep the version a little more organized. Testers are encouraged to switch to the development branch of the mod, if they are using GitHub. When the mod is considered stable/complete enough for alpha, it will be merged into the master branch and will be easily downloadable.

Link to comment
Share on other sites

As a whole. :razz: The awake entities don't seem to fluctuate too much. No worries. I don't know what's causing it, however. (As in, I don't know if the static cycles themselves are doing it, or if it's an issue with charged states.) @simplex said that it appeared before static was added, but the entity count / lua memory seems to indicate otherwise. Aside from that, we're reaching entity levels that are nearly three times those of the overworld. Even if this isn't the cause, it certainly exacerbates the issue.

 

Also, an FYI for our testers, there is a now a development branch that differs from the master branch. This branch is used to test things that are buggy or incomplete, that we don't want just anyone using. (Think nightly builds.) Currently, the new biome changes, and biota testing, are in the latest development commits. This doesn't mean much at the moment, but when alpha rolls around (soon), we can keep the version a little more organized. Testers are encouraged to switch to the development branch of the mod, if they are using GitHub. When the mod is considered stable/complete enough for alpha, it will be merged into the master branch and will be easily downloadable.

ah... I'll try and use github again as it didnt seem to like me before but ah well I'll get the hang of it

 

I think it might be the charged states as i was using both backspace logs and the ctrl-l log and the ctrl-l log was heavily cluttered by "enter state charged" or something like that, doing that for every entity on the world sounds like quite the performance problem 

 

EDIT: ah ha! idea on how to try and tackle this bug:

 

we should take a look at the ruins nightmare cycle files and see where we can minimise the amount of code that is used on the changes to static and unchrged

Link to comment
Share on other sites

  • Developer

@simplex

@Cheerio

 

I've isolated the stutter bug. It occurs more or less at the time static begins. The entity count begins to increase, and doesn't seem to stop, more than doubling in a short period of time. I believe this is the source of the stutter. (Entity count going from 7.5k, to upwards of 20k).

 

Edit: In addition, the 'lua memory' increases to upwards of 100k. It seems to fluctuate along with the stutter.

This sounds like what we've seen when upping the entity count as well which is stutters caused by the lua garbage collector periodically having to iterate over a ton of entities. You should be to verify this once the profiler gets released in the public preview.

Link to comment
Share on other sites

This sounds like what we've seen when upping the entity count as well which is stutters caused by the lua garbage collector periodically having to iterate over a ton of entities. You should be to verify this once the profiler gets released in the public preview.

But the garbage collector became incremental in Lua 5.1 (that's its major pro compared to Lua 5.0, in fact, and solved many stutter issues WoW had). Assuming you aren't forcing full cycles (by calling collectgarbage() directly, either without an argument or passing it the string "collect", instead of just "step"), this shouldn't happen.

@debugman18

Great job narrowing this down. I'll try to pinpoint the root cause. It's still very strange it's related to ground type somehow...

Link to comment
Share on other sites

  • Developer

But the garbage collector became incremental in Lua 5.1 (that's its major pro compared to Lua 5.0, in fact, and solved many stutter issues WoW had). Assuming you aren't forcing full cycles (by calling collectgarbage() directly, either without an argument or passing it the string "collect", instead of just "step"), this shouldn't happen.

@debugman18

Great job narrowing this down. I'll try to pinpoint the root cause. It's still very strange it's related to ground type somehow...

Unfortunately it's not 100% incremental.  Basically there's a known non-incremental part which is affected by the number of bound c++ objects you have which in our case is every entity, anim state and a few other things.  

Link to comment
Share on other sites

@debugman18

@Cheerio

@Craig_Perry

I wrote a little entity creation profiler and tracked the entity explosion cause down. The issue was with the sparks spawned by the storm ram. Fx entities spawn, play an animation and then remove themselves, however, sparks spawned for offscreen rams never played their animations (until the player got close enough), so the removal hook never triggered as well. I fixed it by making them spawn only when the ram is onscreen, which fixed the population explosion. The fix was pushed to the development branch.

However, the stutter remains. It doesn't seem that was its cause after all.

Link to comment
Share on other sites

@debugman18

@Cheerio

@Craig_Perry

I wrote a little entity creation profiler and tracked the entity explosion cause down. The issue was with the sparks spawned by the storm ram. Fx entities spawn, play an animation and then remove themselves, however, sparks spawned for offscreen rams never played their animations (until the player got close enough), so the removal hook never triggered as well. I fixed it by making them spawn only when the ram is onscreen, which fixed the population explosion. The fix was pushed to the development branch.

However, the stutter remains. It doesn't seem that was its cause after all.

That's very odd. I'll see if I can't attempt to narrow it down again.

 

Edit: You said you'd pinpoint it, nevermind me :p I don't have a profiler. I'll keep an eye on this topic.

Link to comment
Share on other sites

That's very odd. I'll see if I can't attempt to narrow it down again.

 

Edit: You said you'd pinpoint it, nevermind me :razz: I don't have a profiler. I'll keep an eye on this topic.

The profiler I just wrote (a very, very simple one, just for tracking entity creation and removal) is a part of the mod code. Just set

PROFILING.ENTITY_CREATION.ENABLED = true
in rc.lua, and then look for the results in entity_count_profiling.txt, which gets placed inside the mod folder (it's written to disk whenever the game saves, in particular on "Save and Quit"). The comments in tuning/profiling/entity_creation.lua document it some more, and its code is at scripts/upandaway/profiling/entity_creation.lua.

However, since now the entity count just remains constant (other than some light natural oscillation up and down depending on some factors), I don't think it'll be of further use to us at the moment. I'm quite certain the issue is indeed caused by adding a new ground type, and that the population explosion just added even more lag on top of it.

Link to comment
Share on other sites

  • Developer

The profiler I just wrote (a very, very simple one, just for tracking entity creation and removal) is a part of the mod code. Just set

PROFILING.ENTITY_CREATION.ENABLED = true
in rc.lua, and then look for the results in entity_count_profiling.txt, which gets placed inside the mod folder (it's written to disk whenever the game saves, in particular on "Save and Quit"). The comments in tuning/profiling/entity_creation.lua document it some more, and its code is at scripts/upandaway/profiling/entity_creation.lua.

However, since now the entity count just remains constant (other than some light natural oscillation up and down depending on some factors), I don't think it'll be of further use to us at the moment. I'm quite certain the issue is indeed caused by adding a new ground type, and that the population explosion just added even more lag on top of it.

 

Is the entity count constant but still way higher than in vanilla?  Or is it now about the same.  

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.