I don't think there's a way to fix it in Tiled, but you can edit the TMX file in a text editor to rearrange tileset order. Pay attention to the "firstgid" and "tilecount" attributes of the tileset objects. The firstgid attribute is the only one that would need to change, but the tilecount attribute can help you figure out what firstgid needs to change to.
Adding another tileset might have altered the IDs of the tiles. Make sure the tile ids in your tilesetdef match what is shown in Tiled. You can check the tile id of the current layer's tile in Tiled by looking at the status bar (see attached image)
Can you post the contents of the map (in Flare's txt format) and your tilesetdef? It's likely that you need to include the old tileset inside the new one. Try adding this to the top of your new tilesetdef:
[tileset] INCLUDE tilesetdefs/tileset_garden_ruins.txt
If you open the Map Properties in Tiled, there should be a custom property called "tileset" with a value such as "tilesetdefs/tileset_cave.txt". This tells the engine which tileset definition to use. The tileset definition sets the tileset images to be loaded and the indicies, bounds, and offsets of the tiles. If the property isn't there, you need to add it yourself.
From your short description, you shouldn't have to fork the engine. Flare mods are created with INI-style text files that set assorted properties for the engine. Clint's "HD" mod works on the latest copy of the engine, so it may be worth looking at: https://github.com/clintbellanger/wandercall-ch1
@Ateo88 We already have a few NPCs in monster populated areas that remain indifferent to the player being attacked. The easiest solution is to just keep this behavior. The effect could even be lessened by keeping enemy spawns far away from the towns (makes sense; why build a settlement right next to monsters?).
However, the ideal solution would be to make it so that NPCs could attack back:
Some work has been done outside the master branch to get NPCs to be driven by the combat AI, but it's implemented in the form of having the NPC become part of the player's party. We'd want something broader.
This would require the existing NPCs to be rigged, as they have no movement or attack animations.
We don't want NPCs to die, nor do we want them to be able to "carry" the player. This is easily solved by giving them ample HP, excessive HP regen, and low attack damage.
The terrain brush is definitely cool, but we've been using Tiled's automap feature to achieve a similar goal. If you load up one of the templates (ex. tiled/cave/cave_template.tmx), you'll notice there is an "automap" layer. From the available tilesets, there should be one called "set_rules". With the tiles here, you can paint into the automap layer and then run Map > AutoMap (shortcut: A). This will fill in the non-automap layers with the appropriate tiles (including collision). Our automapping rules also support variation where possible, like with the cave walls. Granted, I think we only used automapping because it predated the terrain brush (or was more stable at the time).
The Flare Tileset Definition Generator does indeed create the tilesetdefs in part 1 of your post. The reason they appear different is that the flare-game tilesets are single images, whereas the generator keeps the images separate (the part about Imagemagik being used in the generator is no longer true).
For packing, I use the 'flare/spritesheetpacker.py' script in this repo: https://github.com/dorkster/RectangleBinPack. The script has a --tileset option for processing Flare tilesetdefs.
Thanks for the thorough bug report! Though it is undesirable behavior in this case, it technically isn't a bug. Allow me to explain the flow based on the status of save_onload:
save_onload=true
Arrival map loads upon starting a new game
The cutscene event triggers.
The game is saved (for the first time) and then the game is unloaded to show the cutscene
When the cutscene ends, the game that was saved is then loaded.
The save file has the cutscene status set from when the event first triggered, so the event doesn't trigger again.
save_onload=false
Arrival map loads upon starting a new game.
The cutscene event triggers.
The game is unloaded to show the cutscene.
When the cutscene ends, there's no game to load (this is why the save file version is reported as 0.0). So the player is sent to the Arrival map by default.
No cutscene status is set, so the event triggers again.Hence the loop.
It is possible to fix this by adding 'save_game=true' to the cutscene event. That way the save will be triggered even if save_onload=false.
However, I think it's worth going a step further. I've added another property to misc.txt called 'save_oncutscene'. As the name implies, it globally controls saving the game when a cutscene is triggered. The default value is true to avoid "bugs" like this one, but modders can set it to false if they want to control game saves via events like in the above fix. The new property is available in v1.11.06.
I don't think there's a way to fix it in Tiled, but you can edit the TMX file in a text editor to rearrange tileset order. Pay attention to the "firstgid" and "tilecount" attributes of the tileset objects. The firstgid attribute is the only one that would need to change, but the tilecount attribute can help you figure out what firstgid needs to change to.
Adding another tileset might have altered the IDs of the tiles. Make sure the tile ids in your tilesetdef match what is shown in Tiled. You can check the tile id of the current layer's tile in Tiled by looking at the status bar (see attached image)
So from what I see, your "tilesetdefs/sand_128x64.txt" file should look like this:
[tileset]
img=images/tilesets/grass_medium_128x64.png
tile=...
[tileset]
img=images/tilesets/sand_128x64.png
tile=...
In fact, you may want to try using this: https://github.com/flareteam/tilesetdef-generator
Can you post the contents of the map (in Flare's txt format) and your tilesetdef? It's likely that you need to include the old tileset inside the new one. Try adding this to the top of your new tilesetdef:
[tileset]
INCLUDE tilesetdefs/tileset_garden_ruins.txt
Remember to add [tileset] above your own tileset (see here: https://github.com/flareteam/flare-engine/wiki/Tile-Set-Definitions#multiple-images-in-a-single-tileset-definition)
If you open the Map Properties in Tiled, there should be a custom property called "tileset" with a value such as "tilesetdefs/tileset_cave.txt". This tells the engine which tileset definition to use. The tileset definition sets the tileset images to be loaded and the indicies, bounds, and offsets of the tiles. If the property isn't there, you need to add it yourself.
The format of tileset definitions themselves is documented here: https://github.com/flareteam/flare-engine/wiki/Tile-Set-Definitions
From your short description, you shouldn't have to fork the engine. Flare mods are created with INI-style text files that set assorted properties for the engine. Clint's "HD" mod works on the latest copy of the engine, so it may be worth looking at: https://github.com/clintbellanger/wandercall-ch1
@Ateo88 We already have a few NPCs in monster populated areas that remain indifferent to the player being attacked. The easiest solution is to just keep this behavior. The effect could even be lessened by keeping enemy spawns far away from the towns (makes sense; why build a settlement right next to monsters?).
However, the ideal solution would be to make it so that NPCs could attack back:
The terrain brush is definitely cool, but we've been using Tiled's automap feature to achieve a similar goal. If you load up one of the templates (ex. tiled/cave/cave_template.tmx), you'll notice there is an "automap" layer. From the available tilesets, there should be one called "set_rules". With the tiles here, you can paint into the automap layer and then run Map > AutoMap (shortcut: A). This will fill in the non-automap layers with the appropriate tiles (including collision). Our automapping rules also support variation where possible, like with the cave walls. Granted, I think we only used automapping because it predated the terrain brush (or was more stable at the time).
The Flare Tileset Definition Generator does indeed create the tilesetdefs in part 1 of your post. The reason they appear different is that the flare-game tilesets are single images, whereas the generator keeps the images separate (the part about Imagemagik being used in the generator is no longer true).
For packing, I use the 'flare/spritesheetpacker.py' script in this repo: https://github.com/dorkster/RectangleBinPack. The script has a --tileset option for processing Flare tilesetdefs.
The files in part 2 of your post are the actual map files exported from Tiled (via the Flare plugin). See this tutorial for enabling the plugin: https://github.com/flareteam/flare-engine/wiki/Creating-a-Map-in-Tiled
Thanks for the thorough bug report! Though it is undesirable behavior in this case, it technically isn't a bug. Allow me to explain the flow based on the status of save_onload:
save_onload=true
save_onload=false
It is possible to fix this by adding 'save_game=true' to the cutscene event. That way the save will be triggered even if save_onload=false.
However, I think it's worth going a step further. I've added another property to misc.txt called 'save_oncutscene'. As the name implies, it globally controls saving the game when a cutscene is triggered. The default value is true to avoid "bugs" like this one, but modders can set it to false if they want to control game saves via events like in the above fix. The new property is available in v1.11.06.
Pages