k8vavoom: no good thing ever dies!

[-TDRR-]

Just now, ketmar said:

flag values are not related here. that is, it doesn't matter if they're numeric or constants, because constants were copied from GZDoom anyway, so the values are the same.

Nice, i thought K8Vavoom only accepted constants. (Yeah don't ask me why)

 

Just now, ketmar said:

small sample will help alot here. i may very will miss something there, or made a typo. that function is a fuckin' mess (like most ZDoom added code pointers, tbh), and ZDoom wiki is not the best source of knowledge too (it often misses crucial parts of the info), so i need something small to check with gzdoom and with k8vavoom.

I was wrong. A_SpawnItemEx works perfectly fine! However, A_SpawnItem is broken. Sometimes it simply doesn't spawn anything at all, and most of the time it's offset horribly.

k8v_spawnitemsample.zip

Here's a sample you can use. All Zombiemen on D2 MAP01 should be either missing or positioned incorrectly.

 

Just now, ketmar said:

they were semi-broken. in the new build, the second control customisation menu will appear, with all keyconf keys there. yet default keyconf bindings are ignored for now (i.e. all bindings will be empty). this is because i didn't implemented per-mod bindings yet, and it's better play safe, and don't allow mods to accidentally kill normal bindings.

Good to know, i'll add Vavoom-specific open menu keys to my mods that use them.
 

Just now, ketmar said:

tbh, i can't recall it straight out of my head. i'll try to re-check it when i'll have some time (and inspiration), and will drop you a PM.

It can be whenever you want, i'm not in a hurry so don't worry too much about it.

 

Just now, ketmar said:

p.p.s.: and of course, you can write k8vavoom-specific "modmenu" lump. it is way better than menudef, and can contain help strings. this is what k8vavoom itself is using to create most of its menus, so you can look at "basev/common/uidef/menus" to get the idea.

 

just define new menu with "menudef mymodmenuname", and then do this:

 

menudef OptionsMenu extend {
  option submenu {
    title = "BDW Mod Options";
    submenu = k8BDWModMenu;
  }
}

 

and boom! your menu will magically appear in "options".

That's really cool! I'm going to do that instead. Nice that it's on a separate lump too so ZDoom won't crash if it's there.

[ketmar]

6 minutes ago, -TDRR- said:

Here's a sample you can use.

thank you alot, i'll check it!

 

6 minutes ago, -TDRR- said:

Nice that it's on a separate lump too so ZDoom won't crash if it's there.

yeah, i'm usually trying to introduce new lumps, so people can support other sourceports too. i strongly believe that locking mod to The Only True Sourceport is wrong (yeah, ZScript, i am looking at you!).

[ketmar]

25 minutes ago, -TDRR- said:

However, A_SpawnItem is broken. Sometimes it simply doesn't spawn anything at all, and most of the time it's offset horribly.

lol. here:

if (!Distance) Distance = Radius+ItemType.default.Radius;

 

don't even ask me why that line was there, but this is the cause of offsets. and spawning failures are due to occupied positions. fixed, thank you!

 

p.s.: you can simply pass one file with "-file" to k8vavoom. i.e. with "-file dirname" k8vavoom will mount that directory as "virtual pk3", and with something like "-file decorate.txt" it will simply add that file as a standalone lump.

[-TDRR-]

Just now, ketmar said:

lol. here:

if (!Distance) Distance = Radius+ItemType.default.Radius;

 

don't even ask me why that line was there, but this is the cause of offsets. and spawning failures are due to occupied positions. fixed, thank you!

And with that Supreme Invasion should finally work perfectly fine on K8Vavoom, thank you!

Also, i made a nice new K8Vavoom-specific menu for it, and it looks pretty cool and tidier than in ZDoom. MODMENU is a really good feature.

 

About Varied Doom, the random map on exit and pistol start options don't work. Neither do KILL-type scripts or the keyword to force them in MAPINFO. Everything else works just fine though!
I imagine K8Vavoom just doesn't have the xlat translator, but is there any workaround that could be done with VavoomC? Bonus points if KILL-type scripts could also be forced with it.

 

I also share your opinion about ZScript. That's why i only really ever support Zandronum features as my standard, so they can work in:
GZDoom, ZDoom (LE + 32), Zandronum and of course K8Vavoom.

ZScript is the one i only use when it's strictly necessary and there's no possible way of recreating the same thing in DECORATE+ACS because literally only GZDoom supports ZScript.

 

EDIT: Apparently, forcing the AMBUSH flag doesn't work:

I use A_CheckFlag to see if the spawned monster should also have the AMBUSH flag, and set it's TID to 43434 if that's the case.
SpawnDeaf:
        TNT1 A 0 Thing_ChangeTID(0, 43434)
        Goto Spawn2

 

In ACS, i do the following:

Script "DeafMonsters" OPEN
{
    Delay(1);
    GiveActorInventory(43434, "VD_AmbushFlag", 1);
}

 

And that item does this:
ACTOR VD_AmbushFlag : CustomInventory
{
    +INVENTORY.AUTOACTIVATE
    states
    {
    Use:
        TNT1 A 0 A_ChangeFlag("AMBUSH", TRUE)
        Stop
    }
}

Edited August 15, 2019 by -TDRR-

[ketmar]

8 minutes ago, -TDRR- said:

About Varied Doom, the random map on exit and pistol start options don't work. Neither do KILL-type scripts or the keyword to force them in MAPINFO.

yeah, those things are not supported yet. but k8vavoom has it's own "self-imposed constraints" options under "gameplay options" menu, so at least pistol start can be turned on there.

 

as for "kill" scripts -- i didn't even knew about that until now.

 

as for "xlat"... i thought that that feature was long dropped. sure, k8vavoom internally does the same thing, and i can try to implement at least limited support for xlat tables.

[ketmar]

22 minutes ago, -TDRR- said:

Apparently, forcing the AMBUSH flag doesn't work:

hm. it doesn't look wrong. as usual, small test wad will help. i am asking for those instead of crafting them myselves so i can see what exactly you're doing, because my knowledge of the engine may force me to write the things in the way that will "work for sure", because i know how exactly it should be done for k8vavoom. ;-) (and its somewhat hard for me to exctact parts of the mod, even if it is a small mod -- again, i could do it wrong, or accidentally "fix" it so it will work).

[-TDRR-]

Just now, ketmar said:

as for "xlat"... i thought that that feature was long dropped. sure, k8vavoom internally does the same thing, and i can try to implement at least limited support for xlat tables.

Hey, i'd say there's no need for that. I'm pretty much the only guy who had the silly idea to use an old and never updated lump to execute an ACS script that randomizes your exit map. I mean, Zion did it too but that's just for an effect on map exit, not something that really affects gameplay.

 

Just now, ketmar said:

yeah, those things are not supported yet. but k8vavoom has it's own "self-imposed constraints" options under "gameplay options" menu, so at least pistol start can be turned on there.

In that case, i can steal that option and put it in the menu, surely no one is going to notice the difference!

 

Just now, ketmar said:

as for "kill" scripts -- i didn't even knew about that until now.

KILL scripts are really useful and they can massively increase your mod's compatibility with other mods. They are well worth implementing IMO.

 

EDIT: Got ninja'd by you, wait a bit i'm writing the sample.

[-TDRR-]

Just now, ketmar said:

hm. it doesn't look wrong. as usual, small test wad will help. i am asking for those instead of crafting them myselves so i can see what exactly you're doing, because my knowledge of the engine may force me to write the things in the way that will "work for sure", because i know how exactly it should be done for k8vavoom. ;-)

Testing again, a delay of 3 tics seems to work. So apparently K8Vavoom does things in this order:
First execute any ACS scripts, then wait a little bit, and set up all actors.

k8v_custominventorysetflag.zip

Not sure which other mods have problems with this but i imagine there's quite a few more. Set the delay in SAMPLEACS.acs to 1 tic and suddenly it doesn't work anymore.

This sample sets the FLOAT and NOGRAVITY flags instead because they are more noticeable, but AMBUSH works all the same.

 

Right now i'm writing the Varied Doom MODMENU code so i can release v2 with slightly better K8Vavoom support :D

[ketmar]

18 minutes ago, -TDRR- said:

Hey, i'd say there's no need for that.

i can implement "just enough" of it so Varied Doom will work. after all, this is simply mapping of action special to line special, and k8vavoom is already doing it internally.

 

18 minutes ago, -TDRR- said:

KILL scripts are really useful and they can massively increase your mod's compatibility with other mods. They are well worth implementing IMO.

another zdoom "invention". sigh... i'll take a look at it. if only anybody bothered to write a PROPER FUCKIN' SPECS for all crap zdoom introduced...

 

8 minutes ago, -TDRR- said:

Testing again, a delay of 3 tics seems to work. So apparently K8Vavoom does things in this order:
First execute any ACS scripts, then wait a little bit, and set up all actors.

yeah, Vavoom is not a lockstep engine, so ACS delays may deviate a little due to floating point inexactness. this is a known problem, and sadly, i don't know what i can do to fix it. and thank you for the sample -- it may help me to find some workaround.

[-TDRR-]

Varied Doom Now works with K8Vavoom. Probably the very first showcase of K8Vavoom's custom menu feature which is quite cool.

 

Most bugs with it running in K8Vavoom have been fixed by this point, and there's only 2 missing features. (One of them is replaced by just selecting another option manually anyways)

 

Anyways, i hope you guys enjoy it. If you didn't know, WadSmoosh also runs in K8Vavoom so you can mix Varied Doom with it. Just use -iwad "the path to your doom_complete.pk3 here" and in the Varied Doom menu you can set up everything up, including setting the current game as WadSmoosh.

[ketmar]

1 hour ago, -TDRR- said:

KILL scripts are really useful and they can massively increase your mod's compatibility with other mods. They are well worth implementing IMO.

ok, it turned out to be quite easy. implemented. scoring in Varied Doom now works. will be in the next build.

 

Quote

Just use -iwad "the path to your doom_complete.pk3 here"

actually, if you'll put complete pk3 somewhere where k8vavoom can find it, it is possible to simply use "-complete" as a shortcut, because "games.txt" has definition for it.

[-TDRR-]

Just now, ketmar said:

ok, it turned out to be quite easy. implemented. scoring in Varied Doom now works. will be in the next build.

Awesome! I actually thought it would be easy too, since it's just like forcing a script execution on monster death. Did you implement a MAPINFO toggle too right?

[ketmar]

4 minutes ago, -TDRR- said:

Did you implement a MAPINFO toggle too right?

sure. both decorate flag (two flags, actually), and mapinfo's gameinfo flag.

 

btw, you can use color codes in help strings. like this:

"\cGWARNING: In K8Vavoom, this option sticks even without VD loaded!"

and your warning will be shown in red. color code automaticaly resets on line end.

[-TDRR-]

Just now, ketmar said:

sure. both decorate flag (two flags, actually), and mapinfo's gameinfo flag.

 

btw, you can use color codes in help strings. like this:

"\cGWARNING: In K8Vavoom, this option sticks even without VD loaded!"

and your warning will be shown in red. color code automaticaly resets on line end.

Nice. Thanks for your help and patience!

Tomorrow i'm going to test some more mods and tell you if there's anything to be fixed.

[ketmar]

2 minutes ago, -TDRR- said:

Tomorrow i'm going to test some more mods and tell you if there's anything to be fixed.

great, thanks. then i'll prolly push out a new build. maybe i'll implement a limited support for xlat too, it should not be that hard.

 

p.s.: WaterDoom already fixed, btw, it now correctly colors all sectors.

[-TDRR-]

Hey ketmar, i was wondering, could you add support for defining custom IWADs? VavoomC is getting extremely powerful so the need of editing the source code to make new games with the K8Vavoom engine is none except for defining a custom IWAD.

 

Unless this is already in, and if that's the case could you tell me how it works? Been looking a bit through the basev progs and i haven't found anything related to defining a custom IWAD yet.

 

I probably won't switch any of my announced projects to K8Vavoom as they are just too far in development like to have such a large change, but i got one that fits K8Vavoom's advanced abilities perfectly. Does VavoomC allow at least simple map editing? Just raising and lowering floors, retexturing and spawning stuff would be perfect. Even better if it allows ACS-level (or better) editing.

[ketmar]

7 hours ago, -TDRR- said:

could you add support for defining custom IWADs?

i think i don't understand. from k8vavoom's PoV, iwad is not different in any way from any other wad. i.e. pk3/wad can contain/override anything you want, there is no need to make anything special. or i got it wrong?

 

7 hours ago, -TDRR- said:

I probably won't switch any of my announced projects to K8Vavoom

tbh, i prefer them to stay in decorate+acs. you read my note about ZScript, and i believe the same for VavoomC: unless it is absolutely impossible/very slow in decorate+acs, don't use VC. yeah, VC is even more powerwul than ZScript, but... if it is possible it all -- i really want people to not be locked to k8vavoom. to the extent that i'd prefer separate k8vavoom "extension packages" for mod instead of packing k8vavoom stuff inside a main pk3. of course, it is the authour of the mod who'll decide, and i'm not demanding anything, but i think that using a "core" thing plus port-specific "spicy" addons is the way.

 

oh, nevermind, i love to talk about barely related things, and too fond of my letters to remove them.

 

7 hours ago, -TDRR- said:

Does VavoomC allow at least simple map editing?

actually, VC allows EVERYTHING. you're THE GOD. literally. the whole game except renderer and some very small parts of coldet in written in VavoomC. linedef translation is done with VC. initial map thing spawning is done with VC. all sector effects are done with VC. physics is done with VC. everything. while GZDoom still struggling to move the whole game to ZScript side (sorry, just couldn't resist...), Vavoom already done that more than a decade ago, and almost completely.

 

dirty little secret: many complex things ACS trying to do are done by calling VavoomC code, and optionally passing back its result.

 

tbh, you can even move map vertices, but that won't end up in anything good, as you may imagine. but you can, because it is VavoomC. while we're talking about its code as "scripts", technically it is a full-featured OOP programming language, with static typing, and even with such low-level features as pointers.

 

p.s.: as always, with the power comes the responsibility. k8vavoom does not try to "validate" your VC code in any way, neither it tries to restrict you from doing something. so some kind of terrywad can wrek a massive havoc. it cannot access/write files outside of vavoom config directory, tho, and cannot access network directly, but those are prolly the only restrictions. and yes, you can overwrite almost any random memory with VC, and cause a segfault/access violation easily.

 

p.p.s.: no, i don't have any plans to implement VC safety nets. this will make the engine much slower, more complicated to maintain, and people will find a way to fool the protection anyway. just don't use mods from strangers you see for the first time. ;-)

Edited August 16, 2019 by ketmar

[ketmar]

alphabet soup doom!

 

Spoiler

 

actually, this is very nasty gfx/texture glitch that i cannot find yet, and i suspect that it is the source of some other gfx glitches too. so it is not really fun... but still fun.

[ketmar]

i fixed alphabet soup, but still have mysterious memory corruption heisenbug. dunno. i think that if i won't find it soon, i'll push out the build as it is now, and will hope for the best. i think i have to take a rest for several days, it may help.

 

the bug may not manifest itself at all (it mostly doesn't on my system), but ocasionally WEIRD things happens. like crashes where it absolutely cannot crash (no, really, there is no way in hell some of those asserts can fail, they're guarded by other asserts that should be triggered earlier). it won't burn your house or kill your dog (but can electrocut your neighbours, i guess), so it is still safe to play. just be ready to see some really strange things.

[-TDRR-]

18 hours ago, ketmar said:

great, thanks. then i'll prolly push out a new build. maybe i'll implement a limited support for xlat too, it should not be that hard.

 

p.s.: WaterDoom already fixed, btw, it now correctly colors all sectors.

Cool, and i didn't even have to ask! Thanks.

 

11 hours ago, ketmar said:

i think i don't understand. from k8vavoom's PoV, iwad is not different in any way from any other wad. i.e. pk3/wad can contain/override anything you want, there is no need to make anything special. or i got it wrong?

Defining a custom IWAD means: The source-port automatically loading it without any other file required (except the source-port's files themselves) and it containing it's own content and stuff.

 

11 hours ago, ketmar said:

tbh, i prefer them to stay in decorate+acs. you read my note about ZScript, and i believe the same for VavoomC: unless it is absolutely impossible/very slow in decorate+acs, don't use VC. yeah, VC is even more powerwul than ZScript, but... if it is possible it all -- i really want people to not be locked to k8vavoom. to the extent that i'd prefer separate k8vavoom "extension packages" for mod instead of packing k8vavoom stuff inside a main pk3. of course, it is the authour of the mod who'll decide, and i'm not demanding anything, but i think that using a "core" thing plus port-specific "spicy" addons is the way.

 

oh, nevermind, i love to talk about barely related things, and too fond of my letters to remove them.

It's a standalone commercial game that would be on a store like Steam. No reason at all to add support for some other sourceport. But i agree this should be the case for mods, no reason to lock it to a single sourceport.

 

We already use Zandronum, GLOOME and LZDoom as our bases for other games anyways, and i wanted to see if K8Vavoom could have everything needed for a standalone game, if you don't want to do it, it's perfectly fine, we could just continue using Zandronum and use ACS+DECORATE for what we want to do in this game even though it's filled with bugs and quite slow, and barely customizable too.

 

11 hours ago, ketmar said:

actually, VC allows EVERYTHING. you're THE GOD. literally. the whole game except renderer and some very small parts of coldet in written in VavoomC. linedef translation is done with VC. initial map thing spawning is done with VC. all sector effects are done with VC. physics is done with VC. everything. while GZDoom still struggling to move the whole game to ZScript side (sorry, just couldn't resist...), Vavoom already done that more than a decade ago, and almost completely.

Very good! This is exactly what we were looking for. A very powerful scripting (Well, programming now) language that could do everything we needed and even more.
 

11 hours ago, ketmar said:

dirty little secret: many complex things ACS trying to do are done by calling VavoomC code, and optionally passing back its result.

I knew it! I had this suspicion since i knew Vavoom C was as powerful as you said it was. Does DECORATE do this too?

 

11 hours ago, ketmar said:

tbh, you can even move map vertices, but that won't end up in anything good, as you may imagine. but you can, because it is VavoomC. while we're talking about its code as "scripts", technically it is a full-featured OOP programming language, with static typing, and even with such low-level features as pointers.

That's pretty cool. That means i just have complete control over the map structure with Vavoom C? So if theoretically Doom didn't use a static BSP tree i could just transform the whole map on the fly? That's seriously awesome.

 

 

11 hours ago, ketmar said:

p.s.: as always, with the power comes the responsibility. k8vavoom does not try to "validate" your VC code in any way, neither it tries to restrict you from doing something. so some kind of terrywad can wrek a massive havoc. it cannot access/write files outside of vavoom config directory, tho, and cannot access network directly, but those are prolly the only restrictions. and yes, you can overwrite almost any random memory with VC, and cause a segfault/access violation easily.

 

p.p.s.: no, i don't have any plans to implement VC safety nets. this will make the engine much slower, more complicated to maintain, and people will find a way to fool the protection anyway. just don't use mods from strangers you see for the first time. ;-)

Don't worry, at least i won't bomb anything at all using Vavoom C (At least not on purpose). Not sure if there will ever be a K8Vavoom terrywad so perhaps we are pretty safe for now at least :P

 

EDIT: Where's all the DECORATE-related stuff? I'm at the linespec folder and i'm very confused. Where are the codepointers? @_@

EDIT2: I found it. And wow it's very easy to read! I'm able to understand pretty much everything in Actor.Decorate.vc. I'm going to keep experimenting and see if there's any bug i can fix by myself. Maybe then i'll become your official second dev in charge of DECORATE, just remember to keep an eye in what i do so nothing bursts in flames :)

EDIT3: @ketmar WAIT BEFORE POSTING THE NEW BUILD: A_LookEx is broken! The sight check does absolutely nothing at all now, and the sound check doesn't seem to work either. Attacking the monster does make it react again but that's it.

Edited August 16, 2019 by -TDRR-

[ketmar]

11 hours ago, -TDRR- said:

Defining a custom IWAD means: The source-port automatically loading it without any other file required (except the source-port's files themselves) and it containing it's own content and stuff.

ah, that's easy. all known games are described in basev/games.txt. its format is awful, though, i'll change it, but the basics will remain the same. when started, the engine just looks for the first suitable iwad from games.txt (if nothing else was specified by user).

 

11 hours ago, -TDRR- said:

It's a standalone commercial game that would be on a store like Steam. No reason at all to add support for some other sourceport. But i agree this should be the case for mods, no reason to lock it to a single sourceport.

ah, in that case go wild! i'm not against VavoomC (hey, VC was the main reason i started working on Vavoom!), i am only against overusing of VC. of course, total or partial conversion may need to alter game logic in various ways, and here VavoomC is the way to go.

 

11 hours ago, -TDRR- said:

We already use Zandronum, GLOOME and LZDoom as our bases for other games anyways, and i wanted to see if K8Vavoom could have everything needed for a standalone game

sure, no objections! i'll be proud if other peope will use k8vavoom to create any games they want, free or commercial.

 

11 hours ago, -TDRR- said:

Does DECORATE do this too?

internally decorate compiled to the same VM code as VavoomC (even using the same compiler mostly). so technically when you're writing decorate code, you're using very broken variant of VavoomC. ;-)

 

also, this is why many mods are not working too. besides unimplemented features, VC compiler is statically typed. and ZDoom was very... careless about argument types. so people tend to pass strings where numbers are expeced, or even forgot about some arguments completely (and ZDoom was happy to compile that nonsense). i added alot of workarounds for decorate, but it still not so careless as ZDoom. ;-)

 

11 hours ago, -TDRR- said:

That's pretty cool. That means i just have complete control over the map structure with Vavoom C? So if theoretically Doom didn't use a static BSP tree i could just transform the whole map on the fly? That's seriously awesome.

yeah. when i'll implement JIT compiler, i'm planning to move the rest of collision detection code to VC too.

 

to make it slightly more clear: the map is loaded into C++ class `VLevel`, which is fully exposed to VavoomC as `Level`. and i mean fully exposed, with all its fields. so VavoomC have access to the same data structures as C++ part, including subsector data, nodes data, and so on.

 

actually, by adding several API calls (they're not there yet, but it is not hard at all), it is possible to build the map completely with VC code. k8vavoom does internal node building anyway, and it doesn't really matter if lines/sides/sectors data is loaded from some file, or generated by some code. ;-)

 

11 hours ago, -TDRR- said:

I'm at the linespec folder and i'm very confused.

original Vavoom didn't even had any subdirs there! just a flat dump of all source files.

 

decorate API is somewhat special thing. you can export almost any VC method to decorate, you only need to declare it in basev/common/actors/nativeclasses.txt. parameter list doesn't matter there, the only things that matters are:

action native Name ();

at the start, k8vavoom reads that list, and then using it to find decorate methods.

 

also, if you'll see ugly code, that prolly was me who added it. i added alot of code without understanding what i am doing when i only started working on the engine.

 

Quote

A_LookEx is broken! The sight check does absolutely nothing at all now, and the sound check doesn't seem to work either. Attacking the monster does make it react again but that's it.

hm. thank you, i'll check.

 

i am still suffering from memory corruption bug, so every bug report may be not what it seems to be. the quick look at `A_LookEx()` code doesn't show anything wrong.

 

btw. are you compiling the C++ code yourself, or do you simply using the binary i uploaded? usually, uploaded binary becomes obsolete the day i uploaded it. if you'll look at k8vavoom git repository, you'll see that i am commiting there almost every day. i am really working on k8vavoom full-time (only without guaranteed salary, lol).

Edited August 17, 2019 by ketmar

[Graf Zahl]

6 hours ago, ketmar said:

also, this is why many mods are not working too. besides unimplemented features, VC compiler is statically typed. and ZDoom was very... careless about argument types. so people tend to pass strings where numbers are expeced, or even forgot about some arguments completely (and ZDoom was happy to compile that nonsense). i added alot of workarounds for decorate, but it still not so careless as ZDoom. ;-)

  

 

You shouldn't really use a token type aware parser for DECORATE. The original parser inherited from Hexen that was the only thing available in 2004 had no concept of that, and too many mods used quotes badly. You can enclose anything in quotes, even the opening and closing parenthesis of a function call. That's why in GZDoom the DECORATE parser still uses the same old parsing mode and not the better ones that get used for more recent things and then interprets the parsed token based on context.

 

 

[ketmar]

28 minutes ago, Graf Zahl said:

You shouldn't really use a token type aware parser for DECORATE.

i know that. yet i don't want decorate bugs go unnoticed too. k8vavoom decorate compiler tries to make sense of what it sees (this includes converting various string types to other types, and vice versa), issuing warnings on its way.

 

but sometimes mods are plainly broken, passing complete gibberish nonsense to code pointers. usually this means that the author counted args badly, or something like that. those are fatal errors, and i won't create any workarounds for such bugs -- broken mods should be fixed, breaking the compiler to compile bad code is not acceptable for me. if it means that some mod will not work with k8vavoom ever (because author is not there, or they're ok with the current mod state), then so be it.

[ketmar]

@-TDRR- also, there is another reason to avoid VC API if you can: i give zero guarantees of its stability and backwards compatibility. while i'm not going to break everything just because i can, sometimes implementing some feature require API change. or i can spot a Very Bad Code and decide to refactor it, so it will be better maintainable. most of the time it is not fatal, but still... so if you're going to use VC for your game, you'd better watch for git changes, and somehow get me involved. i don't mean "hire me", no! ;-) i mean "watch for VC code changes (they're usually prefixed with "script:" in git log), and check if your code won't break. and contact me if you're not sure."

 

also, it is better to build upon the existing VC code, because some parts of the engine expects to find various things on VC side, and Bad Things can happen if you violate those expectations. that is, most `eventXXX` methods should be retained, for example. and it is always better to extend/extend-replace classes than to copy-paste their code in your project. for obvious reasons, i hope. ;-)

[-TDRR-]

12 hours ago, ketmar said:

ah, that's easy. all known games are described in basev/games.txt. its format is awful, though, i'll change it, but the basics will remain the same. when started, the engine just looks for the first suitable iwad from games.txt (if nothing else was specified by user).

I saw that file but i thought some blanks were filled in by the engine, like required lumps or something. At least it's nice to know that there's not much to do there.

 

12 hours ago, ketmar said:

ah, in that case go wild! i'm not against VavoomC (hey, VC was the main reason i started working on Vavoom!), i am only against overusing of VC. of course, total or partial conversion may need to alter game logic in various ways, and here VavoomC is the way to go.

 

sure, no objections! i'll be proud if other peope will use k8vavoom to create any games they want, free or commercial.

Alrighty then, i'm going to fiddle around with Vavoom C and see if i can get some progress going. If there's anything i don't understand i'll ask you.

 

12 hours ago, ketmar said:

internally decorate compiled to the same VM code as VavoomC (even using the same compiler mostly). so technically when you're writing decorate code, you're using very broken variant of VavoomC. ;-)

 

also, this is why many mods are not working too. besides unimplemented features, VC compiler is statically typed. and ZDoom was very... careless about argument types. so people tend to pass strings where numbers are expeced, or even forgot about some arguments completely (and ZDoom was happy to compile that nonsense). i added alot of workarounds for decorate, but it still not so careless as ZDoom. ;-)

I suppose this is one of the reasons BDv20 isn't working? BDv21 has added various arguments to codepointers where there weren't any, so i guess that's why BDv21 is easier to get working?
 

12 hours ago, ketmar said:

yeah. when i'll implement JIT compiler, i'm planning to move the rest of collision detection code to VC too.

 

to make it slightly more clear: the map is loaded into C++ class `VLevel`, which is fully exposed to VavoomC as `Level`. and i mean fully exposed, with all its fields. so VavoomC have access to the same data structures as C++ part, including subsector data, nodes data, and so on.

 

actually, by adding several API calls (they're not there yet, but it is not hard at all), it is possible to build the map completely with VC code. k8vavoom does internal node building anyway, and it doesn't really matter if lines/sides/sectors data is loaded from some file, or generated by some code. ;-)

That's pretty cool! So you could write something like displaying particles at the center of each subsector to help view how K8Vavoom does it's nodes? Quite nice.

If those are eventually added, a way to only rebuild a few sectors at a time to maximize performance when moving sectors should be done, so we finally get the fabled Duke 3D style cars but much, MUCH more flexible.

 

12 hours ago, ketmar said:

original Vavoom didn't even had any subdirs there! just a flat dump of all source files.

 

decorate API is somewhat special thing. you can export almost any VC method to decorate, you only need to declare it in basev/common/actors/nativeclasses.txt. parameter list doesn't matter there, the only things that matters are:

action native Name ();

at the start, k8vavoom reads that list, and then using it to find decorate methods.

 

also, if you'll see ugly code, that prolly was me who added it. i added alot of code without understanding what i am doing when i only started working on the engine. lol).

That's quite cool. So with that i could cut most, if not all ACS calls in DECORATE and greatly speed things up in some cases? That's awesome.
 

12 hours ago, ketmar said:

hm. thank you, i'll check.

 

i am still suffering from memory corruption bug, so every bug report may be not what it seems to be. the quick look at `A_LookEx()` code doesn't show anything wrong.

I don't think it is the memory corruption bug though, it happens every time, on every map, with every gamemode and every bot setting.

 

12 hours ago, ketmar said:

btw. are you compiling the C++ code yourself, or do you simply using the binary i uploaded? usually, uploaded binary becomes obsolete the day i uploaded it. if you'll look at k8vavoom git repository, you'll see that i am commiting there almost every day. i am really working on k8vavoom full-time (only without guaranteed salary, lol).

Yes i'm using the binary you upload. I just can't compile anything at all in this craptop, first the compiler kept spitting errors, so i upgraded it to MinGW-w64 and now it's slightly better but i still can't compile anything. CMake worked fine, but now it bombs out with "cc0.exe" not working. In fact, the only C++ code i ever compiled is Nintendont for my Wii when i modified it to load multiple controller configs, and even then that's not on this laptop and it was with an already setup toolchain.
So yeah i can't really compile anything.

 

3 hours ago, ketmar said:

also, there is another reason to avoid VC API if you can: i give zero guarantees of its stability and backwards compatibility. while i'm not going to break everything just because i can, sometimes implementing some feature require API change. or i can spot a Very Bad Code and decide to refactor it, so it will be better maintainable. most of the time it is not fatal, but still...

Don't worry, i'm perfectly fine with rewriting code, i do it pretty commonly even when not strictly needed just because i want to make it more readable (After all, almost all of my code is MIT licensed so i can't just leave a mess that only i understand) Even when i first got into ACS i kept rewriting my code because even to myself it was very hideous.

 

4 hours ago, ketmar said:

i don't mean "hire me", no! ;-) i mean "watch for VC code changes (they're usually prefixed with "script:" in git log), and check if your code won't break. and contact me if you're not sure."

Not sure if that was sarcasm but we take anyone who knows C# or C++, so if you ever feel like taking the role, PM me ;) We won't ask much from you anyways.
Anyways, sure i'll check it often.

 

4 hours ago, ketmar said:

also, it is better to build upon the existing VC code, because some parts of the engine expects to find various things on VC side, and Bad Things can happen if you violate those expectations. that is, most `eventXXX` methods should be retained, for example. and it is always better to extend/extend-replace classes than to copy-paste their code in your project. for obvious reasons, i hope. ;-)

Yeah, i think it is because when copy-pasting i'll probably miss out on most updates and fixes to all those classes, so extending will just allow me to add more or change whatever needed and when the update comes, little to no work is needed.

[ketmar]

2 hours ago, -TDRR- said:

I saw that file but i thought some blanks were filled in by the engine, like required lumps or something.

basically, the engine only wants to see PLAYPAL. maybe some other standard lumps too, i don't really remember, but i don't think so. PLAYPAL is required, because it is used to build various translation tables and color cube.

 

2 hours ago, -TDRR- said:

If there's anything i don't understand i'll ask you.

you're always welcome. ;-)

 

2 hours ago, -TDRR- said:

I suppose this is one of the reasons BDv20 isn't working? BDv21 has added various arguments to codepointers where there weren't any, so i guess that's why BDv21 is easier to get working?

actually, BD21 got a huge code cleanup. it is still a mess, but now it looks slightly less like a vomit. also, i added alot of things since i last tried BD20, so it may "almost work" now.

 

2 hours ago, -TDRR- said:

That's pretty cool! So you could write something like displaying particles at the center of each subsector to help view how K8Vavoom does it's nodes? Quite nice.

yeah. but you can see it with much less efforts by using "am_cheating" cvar, and "am_show_XXX" cvars. k8vavoom automap can show alot of interesting things! ;-) (basically because i am lazy, and never bothered to write The Real Debug Tool)

 

2 hours ago, -TDRR- said:

a way to only rebuild a few sectors at a time to maximize performance when moving sectors should be done, so we finally get the fabled Duke 3D style cars but much, MUCH more flexible.

that would be a mess, if possible at all. BSP will degrade to almost unusable polygon soup quite fast.

 

yet i have some other ideas for moving sectors, and renderer. not enough time to do everything i want, as usual, but idea of moving sectors isn't ditched, and i hope to eventually introduce this feature to k8vavoom. ;-)

 

2 hours ago, -TDRR- said:

So with that i could cut most, if not all ACS calls in DECORATE and greatly speed things up in some cases? That's awesome.

yeah. this, or write your actors directly with VC, it supports creating states too (albeit VC codepointers cannot have arguments yet -- it is possible, i just never bothered to implement that).

 

2 hours ago, -TDRR- said:

I don't think it is the memory corruption bug though, it happens every time, on every map, with every gamemode and every bot setting.

as usual, small sample will help. i already rewrote the `A_LookEx()` implementation, though (it was a mess anyway).

 

2 hours ago, -TDRR- said:

So yeah i can't really compile anything.

that's sad. not disasterous, but still sad. ;-)

 

2 hours ago, -TDRR- said:

Not sure if that was sarcasm but we take anyone who knows C# or C++, so if you ever feel like taking the role, PM me ;)

i just don't have enough time. i'm working on k8vavoom 8-10 hours a day usually, and this is somewhere near my limit now. i just cannot code for 20+ hours a day, like i used to do 20 years ago. ;-)

 

2 hours ago, -TDRR- said:

Yeah, i think it is because when copy-pasting i'll probably miss out on most updates and fixes to all those classes

even worse than that: you may end up with completely broken engine. C++ and VC classes and structs should be always in sync. the engine does a very loose job on checking that (C++ sux!), so if i'll swap some fields, or something like that, you won't even notice the change... until everything will blow away. ;-)

 

but extending classes is almost safe. well, as safe as such things could be.

[-TDRR-]

Just now, ketmar said:

basically, the engine only wants to see PLAYPAL. maybe some other standard lumps too, i don't really remember, but i don't think so. PLAYPAL is required, because it is used to build various translation tables and color cube.

Probably PLAYPAL is the bare minimum required to boot. I'll try a bit later.

 

Just now, ketmar said:

actually, BD21 got a huge code cleanup. it is still a mess, but now it looks slightly less like a vomit. also, i added alot of things since i last tried BD20, so it may "almost work" now.

I hope that it "almost works" because Project Brutality is a big, and i mean BIG mod. It's at minimum 4x times larger than BDv20 and suffers from the exact same issues so i really hope i won't have to manually go through every single actor and try to fix whatever is wrong. If it doesn't, i guess i'm going to just release the K8Vavoom compatibility as a later update because it's most likely quite tedious to do.

 

Just now, ketmar said:

yeah. but you can see it with much less efforts by using "am_cheating" cvar, and "am_show_XXX" cvars. k8vavoom automap can show alot of interesting things! ;-) (basically because i am lazy, and never bothered to write The Real Debug Tool)

Oh, that's even better then! It's basically like having GZDoom Builder's Node View mode but directly in the game, which is for obvious reasons useful and less tedious to work with sometimes.

 

Just now, ketmar said:

that would be a mess, if possible at all. BSP will degrade to almost unusable polygon soup quite fast.

 

yet i have some other ideas for moving sectors, and renderer. not enough time to do everything i want, as usual, but idea of moving sectors isn't ditched, and i hope to eventually introduce this feature to k8vavoom. ;-)

I'm really hoping this comes to fruition, because i have been wanting proper Build-style moving sectors in Doom ever since i got my hands on Doom Builder :)
 

Just now, ketmar said:

yeah. this, or write your actors directly with VC, it supports creating states too (albeit VC codepointers cannot have arguments yet -- it is possible, i just never bothered to implement that).

Maybe not. I just love DECORATE's simple syntax so much because it makes quick fixes and edits painless (Unless your mod is Brutal Doom lol)

 

Just now, ketmar said:

as usual, small sample will help. i already rewrote the `A_LookEx()` implementation, though (it was a mess anyway).

It happened consistently every single time and now that i made a sample it works fine. But when it's on the TDBots it does not work for some reason, what could be causing this? Could it be that calling A_LookEx on a player actor is not the same as in ZDoom?
 

Just now, ketmar said:

i just don't have enough time. i'm working on k8vavoom 8-10 hours a day usually, and this is somewhere near my limit now. i just cannot code for 20+ hours a day, like i used to do 20 years ago. ;-)

Understandable. Just know that when i get the money, some donations will likely come your way (If i can understand all this Bitcoin business though :P)
 

Just now, ketmar said:

even worse than that: you may end up with completely broken engine. C++ and VC classes and structs should be always in sync. the engine does a very loose job on checking that (C++ sux!), so if i'll swap some fields, or something like that, you won't even notice the change... until everything will blow away. ;-)

 

but extending classes is almost safe. well, as safe as such things could be.

Oh yeah, the classic "snowball bug". Now i understand, thanks for the clarification.

[ketmar]

29 minutes ago, -TDRR- said:

Could it be that calling A_LookEx on a player actor is not the same as in ZDoom?

from the quick look at the code -- it doesn't do anything special. but it may be different somewhere deeper. that's why i wondered too -- because it seems to work with my tests, and with monster mods. i bet nobody (not Janis and me, at least) ever thought that `A_LookEx()` can be used on player pawns. ;-)

 

ok, now that i know about bots, i'll try to find out what is going on.

 

29 minutes ago, -TDRR- said:

Project Brutality

NO, GOD NO, PLEASE, GOD, NO!!! ;-) i already have one abomination mostly working (clusterfuck), and another mostly working (doomrl arsenal+doomrl monsters), we don't need the third one! ;-)

 

("mostly working" means that you can run it, and it is playable, but many non-gameplay-fatal things either doesn't work, or work different/glitchy)

 

Quote

I just love DECORATE's simple syntax so much because it makes quick fixes and edits painless (Unless your mod is Brutal Doom lol)

understandable reason. from the technical point it doesn't really matter anyway which one you'll use, the compiled VM code is the same. tbh, some things aren't even possible to do outside of decorate (like `A_Jump()` or `randompick()` with 255 arguments, or dynamically calculated jumps).

 

i just HAET decorate syntax, and thought that everybody is like me here. ;-)

 

Quote

Oh, that's even better then! It's basically like having GZDoom Builder's Node View mode but directly in the game, which is for obvious reasons useful and less tedious to work with sometimes.

it may be fun to turn on overlay automap and say this in console:

dbg_autoclear_automap 1

this will clear automap before rendering each frame, so you'll basically get "sight beam" effect. useful to check what parts of the map are really rendered, and just fun to look at. ;-)

(also, ask me about consistent naming! ;-)

Edited August 18, 2019 by ketmar

[Mr.Rocket]

Wish you guys would quit screwing around, I want to get build 801 on the Doom Connector! :P

lol j/k take your time ;)

 

[ketmar]

sure, we can go PMing. but if we'll do that, how'd i get increasing post and page counters in this topic? it must stay hot, so people will believe that k8vavoom has thousands of happy users!