For those interested in in-engine mapediting...

[ben.m...@gmail.com]

I asked Overkill to evaluate how hard it'd be to get the features in
that'd make in-engine mapediting possible in v3. Almost a year ago,
now. Sheesh.

Anyways, this is the list that he came up with. It may be of interest
to some of you.

Overkill, is this list up to date?

=====================

Overkill (2006-07-07):
The todo begins here.

* Difficult
o Moderately challenging
. Easy, but a chore
+ Very easy

+ Make entity.hot(x/y/w/h) writable.
* int ObstructionTilesToImage()
o int EntityFrameToImage()
* void CopyImageToEntityFrame(int image)
. int AddLayer(int width, int height);
. void ResizeLayer(int layer, int width, int height);
. void RemoveLayer(int layer_index);
. int AddZone();
. void RemoveZone(int zone_index);
o void CopyTilesFromImage(int image, int obstruction_tiles, int
replace_existing);
* void CopyTilesFromVSP(string vsp_file, int obstruction_tiles, int
replace_existing);
* void RemoveTile(int tile_index);
. int AddVSPAnimation();
. void RemoveVSPAnimation(int vsp_animation_index);

Map Variables
. {"3", "curmap.startup", ""},
o {"1", "curmap.obstileset", ""},
Layer Variables
. {"1", "layer.count", ""}, // Number of layers on the map, not an
array.
. {"1", "layer.name", "1"},
Zone Variables
. {"1", "zone.count", ""}, // Number of zones on the map, not an
array.
. {"1", "zone.percent", "1"},
. {"1", "zone.delay", "1"},
. {"1", "zone.adjacent", "1"},
VSP Animation Variables
. {"1", "vspanim.count", ""}, // Number of animations on the map vsp,
not an array.
. {"3", "vspanim.name", "1"},
. {"1", "vspanim.start", "1"},
. {"1", "vspanim.finish", "1"},
. {"1", "vspanim.delay", "1"},
. {"1", "vspanim.mode", "1"},
Entity/CHR Variables
. {"3", "entity.name", "1"},
. {"3", "entity.onactivate", "1"}, // Activation script
. {"3", "entity.description", "1"},
. {"1", "entity.idleframe", "1"}, // Idle frames for each direction.
. {"3", "entity.animscript", "1"}, // Animation scripts for each
direction.
. {"1", "entity.autoface", "1"},

[Overkill]

Well, I was recently thinking maybe some of the data might be
accessible if they were each assigned image handles. Like entity
frames could probably be one big sheet, and the obstruction tileset
could be an image, like curmap.tileset is already.

Currently, I think there's some oddness like curmap.tileset was a
handle that was pushed on when the engine started, and the engine just
references to this constant handle id or something. Which meant that
if you set the tileset to a new image, it wouldn't work, or at least,
not right. Er yeah:

SetHandleImage(2, vspdata);

This should be replaced with something better, so the user could
change the handle if they want to manipulate the image in certain ways
like resizing which currently aren't possible. You can only set an
image's size when it's newly loaded, and then it's stuck! So there's
that.

Maybe add a builtin handle type for VSPs, so the player can use this
to copy the VSP images using VergeC code and manipulate the animations
instead of relying on the current map, and allow for saving of any
arbitrary VSP. This would also get rid of the current ugly
curmap.savevsp filepath thing Verge uses when it saves the map, and
you'd be able to cache multiple tilesets and switch them at runtime.

Oh, and another item:
* Making the save() functions for Map, VSP, and CHR formats write as
little-endian (which is what the engine reads) regardless of native
endianess, for cross-platform to work properly.

- Overkill