The first element ([0]) does not contain anything, it is empty, so I must use “-1” to discount that empty element.
So maybe it’s because of that ‘\ n’ symbol?
I think you’re overcomplicating things in your code. You’re splitting the string by \n and getting a blank starting line as a result, even though the thing you’re splitting isn’t necessarily just your data. For example, some parsers require the first line to be field names, in which case that first empty line correctly tells them there are no names (though I don’t think that’s why it’s there, I think it’s there for legibility).
trim()CSVData before processing it this will get rid of any leading and trailing newlines, so you can be sure the string is just your data. Then you won’t even need to split it.
As @eishiya guessed, the line break was added for readability. This way the first line aligns with the rest.
Apart from trimming the data, you could also pass StringSplitOptions.RemoveEmptyEntries to the String.Split function.
But note that you should actually only split this data on commas. The newlines are not guaranteed to be there at all, and are left out when the “minimize export” option is enabled (and the file is exported). The newline per row is also only there for increasing readability.
Similarly, you shouldn’t derive numCols and numFilas (numRows) from this data. These values are available as the width and height attributes on the layer element.
Thanks for all the info guys! but … why does each layer have width and height properties if all layers must be the same in the editor?
There are width and height values for each layer and also in the <map …> element
I mean, just query the values of a single layer because the others will be the same.
Currently the data is meaningless/redundant (it has some relevance within Tiled for rendering), but it may become relevant in the future when/if support for differently sized layers or different tile sizes per layer is added.
Ok I understand.
I only have one problem to solve, I was able to optimize the code with the advice you both gave me.
Now the CSV values for empty tile is 0, not -1.
But if I export in CSV it is -1.
I would prefer -1 for empty tiles.
Can this be changed?
Here you can see, the empty tiles have the value 0 in XML format
No, this cannot be changed. The CSV export is designed for the scenario where you have exactly one tileset and none of the tiles are flipped, with -1 being the empty tile. The CSV format within TMX is designed with multiple tilesets in mind and with the ability to include flips. Due to how negative numbers are represented in computers, I think -1 for empty could get in the way of representing those flips depending on how the data is read in. Using unsigned numbers avoids any such issues with representation.
You should subtract the tileset’s firstgid from the tile ID before using it, to get the tile ID within the tileset. The firstgid is listed with the tileset in the map. If you only ever have 1 tileset per map, it’ll always be 1 I believe.
No, that’s the next object ID, which is completely unrelated. You need to subtract the firstgid, which is a property of each tileset included in the map.
This property is what allows you to identify which tileset a given tile is using, if your map has more than one tileset.
Hello again, one more question.
The values in CSV cannot be saved in int data, since they exceed the maximum value, is it true or do I have something wrong in my code that causes this in some way?
This value exceeds the maximum allowed value for int by 2 units.
You should be using unsigned ints, then you’ll be able to store these values fully, as you’ll not be wasting a bit for the sign.
This sort of situation is what I meant earlier with the -1 empty value getting in the way - if you had to use signed ints just to be able to store -1 for “empty”, you’d lose use of 1 bit (for the sign), which can otherwise be used for flip flags while allowing many more tile IDs.
Hmm now this of the layers of different sizes seems very useful to me, is there a plan for the implementation of this or is it just something that is separated?
It’s not really planned at the moment because it would only make the file a bit smaller while at the same time adding complexity to the editor. What makes it seem very useful to you?
It is a bit complicated to explain, and then I must translate with the google translator and see that everything is coherent … it is a burden to explain something a bit complicated !.
But it would be useful for something I have made for Godot that reads tiled’s TMX files.
When combined with differing tile sizes per layer (another wishlist item for some users), I think the need for per-layer sizing is obvious ;D
Being able to set custom width/height in the editor would make it more convenient to edit parallax layers like I have in my game. Currently I have to draw borders with tiles to show the layer’s size to make it easier to compose them, and if I decide to change the layer size, I need to redraw those borders. Obviously I’ve got this workaround in place so I don’t need the feature, but it would be nice.
@The_Mnk I have custom “width” and “height” properties, and when reading the map, I only load the tile data within that width and height. Perhaps something like that could work for you?
