Skip to content
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

Feature/ninja convert tiledmap slopemap takes tilset indices #24

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Feature/ninja convert tiledmap slopemap takes tilset indices #24

wants to merge 4 commits into from

Conversation

winstonwolff
Copy link

Hi Chad—

Thanks for accepting my previous PR. Here is another change that I need but I'm not sure if you want it. Your current version of physics.ninja.convertTiledmap() takes a slopeMap where the keys are indices into your tile map. I have changed it so the indices are for the tileset instead. In other words, the old implementation requires specifying all the slopes for each individual map you write in Tiled. My change assumes that if you use a certain tile from a tileset, that tile will always have the same Ninja slope. I think this is the common usage for tilesets—a tile in the tileset specifies what a tile looks like and it's properties such as collision Ninja slope. This is certainly an API change. If people are expecting the other way, this will break for them. However I suspect this change is what people expect from a slopeMap.

—Winston

@englercj
Copy link
Owner

Well both should happen, we should check the specific tile first and fallback to the properties on the tileset that the tile represents.

Keep it as keys into the tilemap but then lookup the tileset tile for each one and fallback to those props. That way you can use the tileset to do general config, but override on a tile-by-tile basis.

Winston Wolff added 4 commits January 30, 2015 15:23
Was using index of in tilemap, not index in tileset.
physics.ninja.convertTiledmap's slopeMap now expects a map of indices to the tileset instead of indices to the map.
@winstonwolff
Copy link
Author

I'm not understanding when you say "check the specific tile first"? We're talking about a Phaser.Plugin.Tiled.Tile instance? Is it getting a nina-tile-id somewhere I have seen yet?

@englercj
Copy link
Owner

keys are indices into your tile map

That is a tile. I'm saying instead of replacing the existing funcitonality, extend it to also check the tileset. Does that make sense?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants