I’m trying to make a custom 2D physics system. Here’s the script setup:
Collisions is similar to Geometry, they do the math. Motion is what actually moves the objects.
All of these modules require each other, which is the issue. The ways I’ve heard of to avoid cyclic dependancy sort of mess up the types, and there are a billion functions/methods, each with parameters of declared types, so I don’t want that.
I’ve had an issue like this happen to me a long time ago while writing a system using a couple of Modules. It was a Plot system broken down into separate ‘Plot’ and ‘Occupant’ Module classes because I thought it was “neater.” It also had cyclic module dependencies, which I noticed after writing it and running it for the first time. I just merged them, and it solved the issue.
You basically only have two realistic options here: split the Modules apart further (so that shared resources are separate) or combine them all into one Module. If the Modules depend on one another, it must be a system, and should be treated accordingly by combining everything preferably. It might still be possible to bypass the cyclic dependency by not requiring the Modules in the root thread (at the very top of the Script or any other synchronous code to it), so it can at least return. That would be extremely hacky, and potentially impossible (I’ve never attempted it), so I recommend one of the two options I mentioned.
Sorry to hear that this is occurring, especially with such large Modules. If you copy/paste each Module’s source into do blocks in a new Module and declare each table at the top so resources are shared, it should behave almost identically. That’s essentially what I did in my scenario. Good luck.
Here are some screenshots of my solution to the cyclic dependencies I had:
Plot Types:
Occupant Types:
Plot Module in do block (notice how it uses Occupant, this would cause cyclic dependencies if it were in two separate Modules)
Same thing as the previous but the Occupant block (it uses Plot lower down):
There are some additional methods that sit outside of the do blocks which were not included in the screenshots, but you can see how much more flexible this structure is while still being arguably neater than separate Modules. I would recommend doing this instead. Thank you.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
