Hi there! You are currently browsing as a guest. Why not create an account? Then you get less ads, can thank creators, post feedback, keep a list of your favourites, and more!
Quick Reply
Search this Thread
Field Researcher
Original Poster
#1 Old 28th Nov 2020 at 5:23 PM
Default Is instantiating too many non-static classes a bad thing in some way?
I'm struggling to figure out a way to do something with alarms that I'm pretty sure I could do really easily by just making a non-static class containing an alarm handler field and the alarm callback as a method (I need the alarm to know which household to apply its callback to), but I've been trying to avoid creating too many classes like that because it seemed like it might be bad practice somehow? I've heard of mods causing problems because they add too much extra data to the game, but I don't actually know what that means, I just took it to mean "you should create as few new instances of anything as possible" and have been struggling ever since trying to obey that axiom I totally made up.
Advertisement
Space Pony
#2 Old 28th Nov 2020 at 6:22 PM
Hi lizcandor,
there are indeed some downsides to creating instances like gc and following memory fragmentation (this happens when objects get disposed).
As for the data you add it depends on your classes / instances of them how much space they take.

I am aware that this answer may not be as helpful as it could be. As for your problem cant you make a dictionary or other type of collection that uses the household info you need as key and the callback as value ?

do you need an alarm for each household or is something like polling every hour is sufficient ?
Forum Resident
#3 Old 28th Nov 2020 at 7:11 PM
Don't worry about it.

What you should keep an eye on is that you don't create unneeded duplicate alarms. Also, try to not store direct references to instances of game classes in your code, especially if you want to make it persistible between savegames. In case they get deleted, the GC can't free up the memory if you are holding references to them - at least to my knowledge.

If you need to keep such data, reference Id's instead of instances. So, instead of a List<Household> you work with a list of household ID's like List<ulong> and grab the actual object with something like Household.Find(id);

Find my Mods: Here at MTS, over at Simlogical
Field Researcher
Original Poster
#4 Old 28th Nov 2020 at 7:50 PM
Thanks @Battery, thanks @Consort!

About storing IDs instead of game class instances - that's interesting to know! I'd just been doing that because I assumed the IDs were smaller variables than the classes and would take up less memory for that reason; what would happen if the class instance was deleted didn't even occur to me.

For now I won't worry too much about it (this class, at least, will probably not get used that often, and to be extra safe I can restrict the conditions that apply it to active households, so it's used even less) but the dictionary of callbacks thing sounds like a good idea if I'd be able to set parameters for the callbacks that way! Needing to set callback parameters is the only reason I'm using a class at all.
Back to top