Welcome to
Mod The Sims
Online: 1098
Have an account? Sign in:
If you don't have an account, why not sign up now? It's free!
Other sites: SimsWiki
Reply  Replies: 3 (Who?), Viewed: 181 times.
Search this Thread
Old 28th Nov 2020, 6:23 PM DefaultIs instantiating too many non-static classes a bad thing in some way? #1
Original Poster

Lab Assistant

Join Date: Jan 2012
Posts: 140
Thanks: 308 in 2 Posts
5 Achievements

View My Journal

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.
Old 28th Nov 2020, 7:22 PM #2
Field Researcher

Join Date: Dec 2008
Posts: 385
Thanks: 825 in 5 Posts
8 Achievements

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 ?
Old 28th Nov 2020, 8:11 PM #3
Forum Resident

Join Date: Oct 2005
Posts: 722
Thanks: 7573 in 18 Posts
12 Achievements

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
Old 28th Nov 2020, 8:50 PM #4
Original Poster

Lab Assistant

Join Date: Jan 2012
Posts: 140
Thanks: 308 in 2 Posts
5 Achievements

View My Journal

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.

Section jump:

Powered by MariaDB Some icons by http://dryicons.com.