Hi again,

I did some further tests:

- INVISIBLE entities are now perfect
- sprites work fine
- wmb entities work fine too!
- entity specific decal shadows do not work
- not possible to apply both decal and stencil shadows in the same level, only one of them can be used at a time (maybe it is wmb property, not compilation fault... I do not really use WED)
- entity bounding boxes are not saved as I see
- terrains get black only when I load it from script, and assign to it a material, what modifies the ambient values. in other cases it is fine. (if compiled from WED, it does not happen)
- unfortunately I could not test terrain shadowmapping, I have now the trial version on my pc but results in "virtual memory too low" or something similar error...

some hints for usage:
- to use custom compilation add "-dialog " like this: exec("%EXE_DIR%\\wwmp2wmb.exe","-dialog export.$$M -pal expalette.pcx
- be careful, sun and ambient RGB is used within interval of 0..100, and not 0..255, (and not BGR!)
- fog rgb colors can be added too, like: -fog1 40 38 40 (but fog_color and start and end should be set in script)
- use thread -1 , if you have a single core pc

at the moment I compile with these flags:



anyway, great work! a .wmp saving tool would be fun too!

Hi Sivan, thanks for test and hints.

Afaik decal shadow can't save with wmb. There is no decal shadow in model struct.


Yes, here is problem about BBOX;
it does always return str_cat(temp_str,"1"). I have no idea why.

indeed But i am not sure that is possible.

decal shadows and bbox - yes, I checked the manual, only a script can handle decal shadow settings... maybe a trick can help, e.g. if decal shadow name is stored in string1, and created after level load (or run through simply all entities, and check their file names)... but in this case the bounding box determines its size, what also cannot be set properly (no min_x/y/z..max_x/y/z stored) so that should be handled too, in another tricky way, e.g. storing them in 6 skills...

Hi
I just realized that the saved [.$$M] file can be opened/saved directly by WED, thus this [.wmb] exporter is more useful than I thought... (of course it is more limited than [.wmp] but works)

just for nicer appearance in SED (compiled well, but the bracket opening "{" is handled by the text editor as if a real code bracket open), I use ascii codes instead of strings:

//#define obrackets file_str_write (wmb_handle,"{")
//#define cbrackets file_str_write (wmb_handle,"}")
#define obrackets file_asc_write(wmb_handle,123)
#define cbrackets file_asc_write(wmb_handle,125)

Cool! I didn't know that! Thanks for info, Sivan. Also thanks for the tip about ascii.

@Emre: About the mapentity problem. If i remember correctly, the last release of the Newton implementation of GS iterated through all levelblocks and MapEntities to add them to the collision mesh. The loop is written in LiteC, so maybe this helps

That's nice! I will try it. Thank you, Rackscha!

if I'm right, map entities are small wmb entities (i.e. compiled wmp) within a level. these are taken into account by ent_next, and works fine with your code. maybe you mean prefabs?

Yes, i mean prefabs and level blocks. That would be awesome.