Jump to content

[TOPIC: topicViewTemplate]
[GLOBAL: userSmallPhoto]
Photo

[SOLVED] How to access custom properties or tileset name in Qiso?
Started by J@V0 Jul 16 2019 01:29 AM

2 replies to this topic
qiso maps
[TOPIC CONTROLS]
[/TOPIC CONTROLS]
[modOptionsDropdown]
[/modOptionsDropdown]
[reputationFilter]
[TOPIC: post.html]
#1

J@V0

[GLOBAL: userInfoPane.html]
J@V0
  • Enthusiast

  • 72 posts
  • Corona SDK

I've been through the documentation and it seems there is no way to access custom properties or tileset name of a .lua map. I tried to do something like the extract below but that didn't work.

local mapData = qiso.getMapData()
print(inspect(mapData.sprites))

I would like to do that in order to access a specific tile, as suggested on Tiled forum.

In the end, I would like to do something like:

addToTile(x, y, tilesetName, localID)

It seems that this option is available in other libraries.

 

Is this already available or could potentially be added?



[TOPIC: post.html]
#2

richard11

[GLOBAL: userInfoPane.html]
richard11
  • Contributor

  • 448 posts
  • Corona SDK

The Tiled export isn't actually what Qiso uses. Qiso maps are minimalist for performance and currently don't incorporate custom properties as such. The Tiled import converts a Tiled map into a Qiso map, and then ignores the Tiled data completely. It does use Tiled custom properties to automate calls to the enablePath() and disablePath() etc functions during this set-up phase, but the actual properties aren't kept.

 

There is actually some structure within the Qiso map data that was intended to store per-tile attributes but ended up not being used. It wouldn't be much work to add a couple of new functions to get/set tile attributes so that you can store properties against individual tiles... But, note that this would be a tile as in a literal x,y coordinate within the world, not as in a sprite which might exist multiple times throughout the world. From your post in the Tiled forum, it sounds like you're wanting to identify whether a tile contains a building, i.e. a specific sprite, in which case the way you're already doing it is actually the proper approach, despite the issue of these ID's changing when you reorder the spritesets within Tiled.

 

These ID's actually correspond to the spritesheet files and the sprites within those files so when Tiled changes the gid after you swap the order of the sheets, it's because the order the spritesheet files need loading in has just swapped around so sheet 1 has to become sheet 2, and sheet 2 has to become sheet 1. The ID's aren't decided by Tiled as such, they're just natural references that all engines can mathematically reverse back to the right images.

 

We could potentially extend Qiso to internally maintain lists of per-sprite properties and provide lookup functions to see if an individual tile contains a sprite that has a specific property assigned to it, but my gut feeling is that this would unnecessarily bloat the size of the Qiso maps so perhaps wouldn't be a good idea in terms of the engine being optimised for most uses. You'd still need to pass ID's when adding sprites to tiles anyway, and these ID's are still going to change if you swap things around in Tiled. Both of these problems in mind, I'd advise that you instead maintain ID lists within your own code and use those lists for your getTiledData checks and addToTile calls, etc. If you create these lists as nested data tables where the outer table holds a human readable name as a key and the inner table holds the firstgid + ID values of that object, then any time you need to swap the sheets over, you'd just need to do a find+replace on those firstgid references and leave your addToTile() etc calls just adding the two values together to compute proper ID's. E.g. something like this:

-- Human readable list of sprites
sprites = {
    grass = {
        firstgid = 1,
        id = 1
    },
    hut = {
        firstgid = 1,
        id = 2
    },
    tree = {
        firstgid = 3,
        id = 1
    }
    bush = {
        firstgid = 3,
        id = 2
    }
}

-- Add a grass sprite to tile 2x2, regardless of where that sprite currently sits
qiso.addToTile(2, 2, sprites.grass.firstgid + sprites.grass.id, "ground")

This way, sprites.grass.firstgid + sprites.grass.id will always add up to the correct image and if you move things around, you just have to update those firstgid values accordingly and not worry about your game code.

 

I'm tired and convinced I've messed something up in the above code, but hopefully you understand the concept at least. I believe this approach is what Bjorn means in his paragraph:

 

 

So in your game you should generally not use the global ID to associate other information with the tile or to refer to a specific tile. Instead, use the local ID (highlighted in your screenshot) and the tileset if needed to refer a specific tile.

 

I hope all of this makes sense?


  • J@V0 likes this

[TOPIC: post.html]
#3

J@V0

[GLOBAL: userInfoPane.html]
J@V0
  • Enthusiast

  • 72 posts
  • Corona SDK

That's a good workaround and it works fine now. I stored them in a table and call them in a similar way to what you have suggested.

I will see if I move the information to my database instead of the table in the future.

 

(it seems you can't set the topic as SOLVED in this part of the forum...?)




[topic_controls]
[/topic_controls]

Also tagged with one or more of these keywords: qiso, maps