k8vavoom: no good thing ever dies! (2023, Dec 22 build)

and with mine one can build perpetuum mobile. ;-) if there is not enough place to make mobj origin to rest at the floor, the corpse would never stop sliding.

we should combine our bugs features, i believe! ;-)

heh. at the end of the day i implemented school textbook physics algo to determine if a body is "stationary". if we collect all contact points, and then create convex hull with them, we can check if center of the mass is in that hull.

choosing sliding vector is still somewhat arbitrary. (i have to calculate torque forces on contact manifold, and use that, but meh… too much for me yet.) so sometimes bodies can slide into the support sector, not out of it (i.e. backwards). one day i'll fix that, but for now it looks funny, so i'll let it stay.

i don't know how it should work. i see nothing wrong with it after quck testing. please, be more specific with your reports: describe what you expected, what you got instead, and how to trigger the bug.

it runs (i mean movement here) ok in my latest build. the only problem is that it teleports to the exactly same place where it was. ;-) anyway, i already made some tweaks in decorate compiler, and will make some more.

thank you for your report! i'll try to find out why it cannot properly teleport.

ok, teleporting seems to work now too.

I still don't understand the complex logic of the decorate, "I'm not a magician, I'm just learning" like in a movie about Cinderella. Just such examples and communication help me understand what's what.

and btw. saved games are now in VWAD format too. ;-) if you think that i am little obsessed with my New Shiny Format… well, you are prolly right. but besides that, VWAD has a proper file hierarchy inside, so it will be much easier for me to modify or extend saves without huge compatibility problems.

you prolly never noticed it, but VSG save format changed many times. it wasn't designed as very extensible, so most of the time i had to find some byte i can set to invalid value, and use that to detect new features in saves. at the end of the day, VGS becomes a beast, full of hacks like "oh, check this byte, and that byte, and hope that they are wrong because they were used as extension flags".

of course, full conversion is not complete yet: the engine still writes huge lumps of non-extensible map data. but at least i can add new things as new files now, without resorting to ugly hacks.

and don't worry: your old saves still can be loaded (and the engine will use old save format for old saves, because of… eh, the code does it this way). i am not some AAA studio, so i cannot afford the luxury of breaking saved games with each new patch. ;-)

as a side effect, saved games will take slightly less memory now. the engine has to keep the last loaded save in memory, and it creates internal memory-only saves for wads with hubs. now we can avoid unpacking the whole save data before reading it: VWADs can be read with on-the-fly depacking.

in the future i will split monolithic map data to separate files too, and will optimise saved games even more.

the huge problem is that i don't want to make old saves unloadable. of course, it's not that important considering the small k8vavoom userbase, but hey, it's fun challenge!

anyway, to make code more maintenable, i have to split saving code (in several places i didn't touched yet) to separate functions. now, with proper virtual file system in place, it would be much easier to do.

internal file structure of VWADs is the same as in pk3. it is a different container format, slightly better suited for random files access. for the modder, it doesn't matter, tho, you don't need to change your habits. just think of VWAD as "yet another archive format i have to deal with", instead of zip. ;-)

for creating vwads (and pk3s, by the way), i'd recommend to use k8vlumpy tool. it is used to create k8vavoom basepaks, for example, and to build Zan mod. it lacks documentation, of course, but that's where you can look at Zan mod sources, for example, to see how build scripts are written.

p.s.: @dasho, don't you want to steal this code to EDGE Classic? ;-)

simply speaking: you can't. i'm not expecting any editor to support the format, ever (and much less full support, with group tags). use vwads only for public releases, not for development. or spam editor authors with requests for support. ;-)

p.s.: but i will definitly add vwad support to my Eureka fork. i didn't want to add pk3 support, but vwads are much easier to work with.

nope, the fork is not ready for using yet (and will prolly never be). sorry.

Sounds cool