[tiled-user] Contributing source to the project

[Pedro Miller Rabinovitch]

Bjørn Lindeijer wrote:
>> * A small "Swap Tiles" dialog, akin to "Search and Replace"
> I'd like to see it. Since the Search & Replace dialog would need to be
> used at least three times for this operation, together with a
> previously unused temporary tile, I think it makes sense to include
> it. You never know who might need it. :-)
Yes, that was my reasoning. I'll see if I send it today.
>> * Changes on the firstGid attribute -- it's no longer set at save, being
>> set at read instead;
>> * Tileset properties dialog (so far only including the firstGid 
>> attribute);
> The firstGid is something Tiled uses internally to be able to match a
> simple array of numbers (layer data) with several tilesets. Setting it
> at read instead of at write would break when the size of tile sets
> change in Tiled (for example when adding or removing tiles). Can you
> elaborate on why you needed to be able to edit this manually?
Oh, I see. We don't change tilesets inside the editor. By what I read on 
the documentation online I figured firstGid would be available for 
changing for outside purposes.

Here's our situation: consider a multi-level game, e.g., a vertical 
shooter. They use different tilesets (e.g., lava, jungle, space), but 
each means basically the same. We also have `activators' -- special 
tiles that represent enemy spots, power-ups, special points of the 
stage, etc. They need to be placed on the map so the level designer can, 
well, design the level. However, they are *not* to be displayed at the 
final game -- in fact, the activator tileset exists only as far as 
editing the level is concerned. At runtime, we interpret each map layer 
differently: the visible game layers use each their own tilesets, while 
the activator layer is read and checked, but never displayed.

With other editing software, we had to use a solution using fake, 
larger, tilesets ....

Hang on. While writing this answer I realized -- the solution was needed 
for historical reasons. There's no point. Since in my application we can 
only have a single tileset per layer, the whole thing is pointless, as 
far as using multiple layers is a possibility. I'll just export local 
IDs instead.

But think on an application that needs to mix different tilesets in a 
single layer *and* needs to recognize/process certain tiles. What 
happens if each tileset has a different size? I'll have to think more 
about this.

In the meantime, I'm reverting my changes. I'll think about a way to 
tell the editor which layers can contain tiles of which sets, that would 
be way more useful at this point.

> * Export menu option -- similar to Save As..., but keeps the name used;
>
> This was planned for a long time but I never got around to
> implementing it. I'd gladly include this.
Ok. I need to work a bit more on it so the last path information is 
incorporated in the .tmx in an appropriate (i.e., relative) manner, 
right now it's just a hack. I think I already updated the resource 
strings, but I'll check.
>> * Layer separators (I need this to group layers together so they are
>> merged at export... This is very specific for us);
> Alright, I think I should let this one pass unless we could think of
> more generic usefulness.
Yeah. Maybe someday we should have layer groups (like "folders" -- 
Photoshop and Flash are good references, Gimp probably has them as 
well). But I wouldn't merge this one anyway.
>> * Small corrections to the javadoc documentation (mostly classical
>> copy-and-paste errors);
> Nice. :-)
Been there, keep doing that. :)
>> * A compact, binary output plugin (which probably wouldn't be useful
>> outside here);
> If it's supported by a publicly available engine or well documented,
> people in a similar situation as you may find it useful.
It's not supported anywhere except here. I'll think about the usefulness 
and discuss it around here before publishing.
>> * An Ant task to compile maps using the plugin above (this could be
>> generalized for other formats).
> Some people may find this interesting.
This is a new favorite of mine. I'm a big fan of automagically doing 
stuff. That's what computers are there for, anyway... :)
> I'm impressed by what you already managed to implement. :-)
Thanks :) It's been fun tinkering with your work.

Cheers

-- 
Pedro Miller Rabinovitch 
  <miller at finalboss.com>

Esta mensagem, incluindo seus anexos, contém informações 
legais privilegiadas e/ou confidenciais, não podendo ser 
retransmitida, arquivada, divulgada ou copiada sem 
autorização do remetente. Caso tenha recebido esta mensagem 
por engano, por favor informe o remetente respondendo 
imediatamente a este e-mail, e em seguida apague-a do seu computador.