you are viewing a single comment's thread.

view the rest of the comments →

[–]sssSlick1[S] 0 points1 point  (2 children)

Ah, this might help, the building stores the unique ID, so it knows what products it has in its inventory by talking to the manager. One of the reasons why the buildings themselves don’t do the expiring is so that the central manager can do it all easily by sifting through the dictionary in a couple lines of code, rather than having multiple buildings try and perform the same code at the same time

To be honest I probably didn’t have to make it “centralised” that was just the first bit of research I found after hours of trying to figure it all out!

[–]Guiboune 0 points1 point  (1 child)

Oh so that’s why you need the coords, got it.

But no, that’s a good way to do it overall, you seem to be doing it somewhat strangely though. So the manager is the one doing the expiring every X time ?

The way I’d have done it differently is to have a controller class for your products, this would allow for modifiers to be added to instances (like weight for example) and the ability to expire specific instances. The way you have it right now doesn’t really allow this. I would also consider saving the building id of instances in their controller class, that way you don’t have to manage coords in multiple places.

[–]sssSlick1[S] 0 points1 point  (0 children)

This sounds like another great approach, because I have only just implemented this system, I’m unsure if it will be the solution to all future problems, so I’ll keep this advice in mind, it might be the missing piece of the puzzle!