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

#2933 Set the firstgid property on Tilesets #2934

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

csueiras
Copy link

@csueiras csueiras commented Nov 8, 2020

Fixes issue #2933

I've also added test coverage for the property being set.

@bjorn I know there's some on going work to release the latest version of the library to Maven central, let me know how can I help out to get these changes into master and released. Thanks!

@bjorn
Copy link
Member

bjorn commented Nov 10, 2020

Hmm, why do you need the tileset's firstGid attribute set? What part of the code relies on it?

I'd prefer if we could remove the firstGid member from the Tileset class instead, because I don't think it belongs there. It is only set when saving a map and only used while loading a map, and for that we have tilesetPerFirstGid.

@csueiras
Copy link
Author

@bjorn isn't the firstgid required to map a global id back to a tileset? I am using this library in a server-side setting btw to parse out maps/tilesets.

@bjorn
Copy link
Member

bjorn commented Nov 21, 2020

@csueiras With the clarifications above, do you still see a use for exposing the firstgid attribute? If you still need it, please let us know why.

@bjorn bjorn force-pushed the master branch 3 times, most recently from 384d5ac to 2e9a0fb Compare June 25, 2022 13:33
@duarm
Copy link

duarm commented Oct 16, 2023

More so than setting the firstgid to an specific value, For my use case, it would be enough to reorder each tileset when they are embedded into the map. I have an exclusive tileset for "non-colliding" tiles, setting that to the first tileset allows me to check for collision with tile < tilesets[0].firstgid. Of course I can reorder them while importing, but if they are already in order, it would help. Currently, if you create a new map and arbitrarily start painting, the firstgids would be out of order, and you can't reorder them without destroying the map.

@bjorn
Copy link
Member

bjorn commented Oct 17, 2023

@duarm This PR is a proposed change affecting the Java library for loading Tiled maps. I don't think it has anything to do with your concern, which appears to be about manually setting the firstgid or manually ordering the tilesets. The latter is covered by issue #1613.

Note however, that the firstgids for the tilesets will always be incremental, as defined in the file format documentation. So, manually placing a tileset at the start of the list would change its firstgid to 1:

"If there are multiple <tileset> elements, they are in ascending order of their firstgid attribute. The first tileset always has a firstgid value of 1."

So I don't think your plan would work as such. You'd have to put that tileset first, and then check against the firstgid of the second tileset: tile < tilesets[1].firstgid. However, I'd still recommend against such an approach, and would rather advise to just find out which tileset the tile is from (as documented here) and check a custom tile or tileset property to decide whether a tile is colliding. It would be more flexible and more readable that way.

@duarm
Copy link

duarm commented Oct 17, 2023

Sorry for the wrong issue, yeah, I meant to check with the second tileset, wrong pseudo code

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.

None yet

3 participants