I've just done some experimenting and expanded HookEntityRender() in the docs a little, I think this rather hightlights how awkward the current way of paper doll-ing is. As vec has just been wonderful and added a handle to the vsp, I thought I'd request one to the chr graphics again. Oh, and an EntitySplat() function to go with EntitySpawn().

It would be quite nice to have the option of creating an entity at runtime from data, rather than requiring a chr, or even just access to some of the things set up by the mak. At the moment there's rather a lot of stuff:

chr_version 5 | in annabelle.png | out annabelle.chr
frame_w 32 | frame_h 32
hotspot_x 8 | hotspot_y 16 | hotspot_w 16 | hotspot_h 16
frames_per_row 5 | frame_rows 6
d_idle 0 | u_idle 5 | l_idle 10 | r_idle 15
d_walk F0W10F1W10F2W10F0W10F3W10F4W10
u_walk F5W10F6W10F7W10F5W10F8W10F9W10
l_walk F10W10F11W10F12W10F10W10F13W10F14W10
r_walk F15W10F16W10F17W10F15W10F18W10F19W10

I'd say the following functions might work:
int CreateEntity(int map_x, int map_y, string image, int frame_w, int frame_h)
// Auto detect frames_per_row and frame_rows set chr_version to 5
// Set default values for hotspot, idle and animations

void EntitySetWalk(int entity, int direction, string movecode)

Hotspot already has entity.variables, add four for the idle animations. So then, you could make an entity at runtime like:

int new_ent = CreateEntity(76, 64, "annabelle.png", 32, 32);


entity.hotx[new_ent] = 8;


entity.hoty[new_ent] = 16;


entity.hotw[new_ent] = 16;


entity.hoth[new_ent] = 16;


entity.idleu[new_ent] = 5;


entity.idled[new_ent] = 0;


entity.idlel[new_ent] = 10;


entity.idler[new_ent] = 15;


EntitySetWalk(new_ent, 1, "F5W10F6W10F7W10F5W10F8W10F9W10");


EntitySetWalk(new_ent, 2, "F0W10F1W10F2W10F0W10F3W10F4W10");


EntitySetWalk(new_ent, 3, "F10W10F11W10F12W10F10W10F13W10F14W10");


EntitySetWalk(new_ent, 4, "F15W10F16W10F17W10F15W10F18W10F19W10");

Might seem a little long winded, but being able do this at runtime would save ALL KINDS of pain elsewhere.


I'm looking forward to being able to use the renderstring properly. What I need to do at the moment it something like:

FloorLayers-R1-BackLayers-R2-Entities-FrontLayers-R3

With R1 as the grid, and any square highlights; R2 dead entites; and R3 overlays and stuff.
I tried emulating the R2 layer with HookEntityRender(), but ran into problems over y-sorting: creating a blank entity at 0,0 would solve this, but just adds to an already ugly hack.

Enough random rambling,

Zip

[Edit: Dorgot map x,y values for spawn]

Being able to set the walk animation at runtime would also allow people to have separate walk/run animations, which is a bit ambitious for the average VERGE chrmaker, but would be rock out awesome nonetheless.

Hey Zip, that MAK file info is straight out of my Annabelle CHR data for P7! Shrewd bit of marketing there! Ehehe.

This is all theoretically cool and, theoretically, not that hard to do, but there's one big catch right now, which is that CHRs are cached. Most real-world maps typically have more entities than they do unique CHRs, and I didn't like the way maped2/v2 had that 'chr list' and then you plugged in the chr index for the entity. So in v3 we just made it so you listed the CHR for each entity, and had the engine do a caching system so that, in that HOV entry where every entity was Darin, only one CHR object is ever loaded. So... as things are setup, any modification to one CHR's stats would modify every CHR that uses the same file.

I'll have to think about any possible compromise solutions.

I dunno -- since many of my things rely entirely on runtime loads, and since I have no interest in paperdolling, that would screw me over. I don't think you can really say that runtime-generated chrs are any more likely to need individual chrs. What I think you might need to do is have the system generate a unique chr for every entity, or something similarly unpleasant.

Vecna: would you believe I actually suspected that CHRs would be handled like that? Still, is that so much of a problem if paperdolling were really only used for partymembers?

A possible solution would be to have a flag you could set that says whether an entity uses a unique CHR or not, so we save memory when we can and use more of it for funky paperdolling when we need to.

That's true, Zip, but if you don't consider it a meaningful excess there's no reason to have caching on any chrs. The way you suggested is like not allowing dogs into your store unless they're wearing hats.

You take 9999 analogy damage.

I'll tell you where to stick your Advanced Healing Salve +72 Against Dogs.

Well, it's sorta like a mouth...