Hey there
@msalaba ! Yeah, we spammed a little the past few days, sorry about that
Also, was the high amounts of struct creation / deletion mentioned due to not having version m correctly installed?
Yes, for some reason, MO2 was being dumb. After I manually deleted the previous install and added the m version everything was fine, as it should. I was just testing the M version with Nukem's logging to see if there were any other massive structs creation, but I couldn't find any.
You were asking about the WorldObject struct. What I can tell you is every object spawned by a building plan, city plan, WSFW layout and plot icons (there may be more I'm forgetting) have the spawn data packaged into a WorldObject struct and passed to WSFW via a place object thread to actually be spawned.
It took me around 3 hours to write that post, and in the end (
it doesn't even matter!... sorry, it is stronger than me... ignore this parenthesis) I had lost my train of thought and forgot to summarize things xD Nukem's logging only detects structs creation, release and destruction. It was not written to debug massive function calls that might cause script lag. So I intentionally did that test with the version BEFORE the fix, so I could use Nukem's log to see where the calls were coming from. One thing I forgot to mention in that post is that the 6438 structs created as soon as I built a storage correspond to 222 calls for each of my 29 plots at the time, which honestly seems excessive to me. I still didn't find which code is called when you place down an object so I can follow it to see what's happening, but 200+ calls for each plot every time something is built can get out of hand pretty quickly xD
In regards to the HUD, every time a plot requests and gets an update, the old icons are deleted. The new icons are spawned using the same WSFW create object thread described previously.
As for the HUD updates, what concerns me a little is the fact that, unlike in other places, I can't find any control variable to slow down chain calls. Kinggath has them in several places in the code and I'm not saying that they aren't somewhere in the path between the first call update itself. The good thing is that the update function only has one reference in the code, so there is only one place where is being called. The bad thing is that it is inside an event and, from what I understood from kinggath explanation, it is possible for several "instances" of the same event to run in parallel, as long as they come from different places. So an event calling StartTimer on itself will just reset the timer, but a call for StartTimer outside the event might create parallel runnings of the OnTime event(?). Without more knowledge, it is complicated for me to fully understand (and debug) what's going on.
Every time they flicker or change, HUDManager is being called to update that plot's icons. Which IIRC, is a lot.
Yeah, I remember from one of the update videos in SS2 v1.x kinggath mentioned that having the icons always visible was a huge hit on performance, but that's what I want. I want to push the engine to its limit until it screams in pain and then 2 things can happen. Either it's just the way things are and there is nothing to do about it, or there is room for optimization of the code. This is what I mean when I say the GC problem was just a symptom (and thank god it was a symptom that screamed very loudly!). The instances were being created because of a small bug in the code and it was filling the GC. But why were there so many calls in the first place? Was it because it is necessary, or was some unexpected function call loop that passed noticed in the review process? That's what I'm trying to figure out.
I think the tool
@Mystical Panda is developing goes in that direction too. He's focused on the stacks dumps since the beginning and I think that his tool will be a huge boost to performance for all the modding community.
Here's a final example to clarify my thought process:
A called and B called C. C is where the instances were being created. But, on other occasions, D called B and B called C. Hotfix M fixes C, but the functions calls behind that are still there. As I said, this might not be a problem, but I like to dissect code xD
Tkx for the input
@msalaba. That explains all the ThreadRunner_OnThreadCompleted I'm seeing in my stack dumps (and just so there is no doubt about it, I'm talking about hotfix M).
Just a final note, from the 174 dumps I had the last time, 100 were OnTime() events, from several scripts, but mainly SimPlot and HudManager.