-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump: adding and removing objects from the world #180
Comments
I think the best way to handle objects that can be deleted and recreated is to just a active flag to the object. Then whenever you call world:move you will pass in a filter that will change the way the collision is handled based on that flag. |
I see; yeah I suppose using a filter function would have been a cleaner way to do this. During development I felt a bit like I was grasping at straws since I was framing the problem in terms of "items to be added and removed from the world" rather than "the contents of the world are fixed at initialization time, and you can dynamically choose to ignore them on a per-case basis". I wonder if the docs could be improved to suggest this pattern to folks like me who were scratching their heads wondering how to do it and not finding any guidance. Maybe I could put together a "limitations" or "tips" section for the readme if you like? |
I'm open to folks writing interesting tutorials to help people learn how to better use STI. I am thinking of updating this repo to move the tests to a different repo, so we coudl add tutorials there too. |
See: #207 |
I ran into some trouble when trying to use the bump plugin in my game. All the collidable objects get loaded into the bump world table just fine when calling
bump_init
, but I wanted to make doors which could open and close, which required adding and removing objects from the bump world at runtime.Calling
world.remove
on an object that you get frommap.layers[layer_name].objects
doesn't work because thebump_init
function doesn't add the object table directly to the world, it creates a wrapper table that has copies over a subset of that table's fields. So you need to callremove
(and later on,add
) with that wrapper table instead, but I couldn't find a way to get it from the map object.I ended up writing a bit of a hack to work around this by storing all the wrappers in a
wrappers
table keyed on the original objects and adding abump_wrap
function that would intercept any method call and do the lookup for you before handing off to the bump world. But it seems a bit unsatisfactory; surely I'm not the first person to want to use this library together with bump and want to have doors that can open and close?So two questions: the first being did I miss something that's already in the code? Is there a better way to do what I did above?
If not, would you accept a patch to the bump plugin to allow for this kind of thing? Is the approach I used above OK, or is there another way we should do it? The other alternative I could see would be storing the wrapper table as a field in the original table which is in the
layers
table on the map itself, which might be cleaner.The text was updated successfully, but these errors were encountered: