Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
ketmar

k8vavoom: no good thing ever dies!

Recommended Posts

Pfst… Freak'n nice!

Looks better than quake.. is that a PS1 sky back there?

Love it, downloading now..

Share this post


Link to post

oops. and i found that damage multiplier powerup was completely broken too. it should work in the next build. ;-)

Share this post


Link to post
Posted (edited)

@Gunrock i finally fixed elevator logic, so in the next build player won't stuck in SS:R elevators on MAP01, for example (or in any similar elevators). the original logic was right, but when i introduced support for GZDoom-style 3D floors, i accidentally it. ;-)

 

p.s.: and other news: i removed limit on number of weapons in one slot, and rewrote slot management code. now it should respect keyconf/gameinfo slot definitions in addition to PlayerPawn, and weapons without any slot set are put in slot 11 (which is bindable in controls menu), so a user will be able to cycle/select such weapons anyway. tnx to id0 for kicking me. ;-)

Share this post


Link to post

Ugh, the frantic sprite shaking is happening with the new version, and my fix of "use integrated graphics" isn't working on the 0808 release. 

 

Also, it's not saving any of my settings. I set it to fullscreen and when I start it up again it's in window.

Share this post


Link to post
19 hours ago, ketmar said:

@Gunrock i finally fixed elevator logic, so in the next build player won't stuck in SS:R elevators on MAP01, for example (or in any similar elevators). the original logic was right, but when i introduced support for GZDoom-style 3D floors, i accidentally it. ;-)

 

p.s.: and other news: i removed limit on number of weapons in one slot, and rewrote slot management code. now it should respect keyconf/gameinfo slot definitions in addition to PlayerPawn, and weapons without any slot set are put in slot 11 (which is bindable in controls menu), so a user will be able to cycle/select such weapons anyway. tnx to id0 for kicking me. ;-)

Thanks ketmar for fixing that!!!!

Now that Dark Wispers: Remastered is out of the way, I'm working on Dissolution: Definitive Edition.

I know people are tired of the Quake theme but Quake is my favorite game. Being able to mix both Quake assets into Doom I get the best of both worlds using GZDoom and K8Vavoom.

 

pic1.jpg

Share this post


Link to post
Posted (edited)

@DuckReconMajor i really don't know what is going on. nobody else reported something even relatively close to the problems you described. it is absolute mistery. i am really sorry that your experience with k8vavoom is so unpleasant. and for my "average support guy" tone, i am just puzzled, and trying to scare bugs with it. ;-)

 

@Gunrock Quake "dark gothic" style has its own uniuqe charm. ;-)

 

p.s.: showing GZDoom screenshots in k8vavoom thread is cheating! ;-)

 

Quote

Thanks ketmar for fixing that!!!

thank you for making maps for us to play! even the best engine is useless without the actual content to play.

Edited by ketmar

Share this post


Link to post
1 minute ago, Mr.Rocket said:

Is the @ response working in the next build?

it is working in GNU/Linux version. but in windows version, something is wrong. it looks like it deadlocks somewhere (yet there are no threads involved at that stage, so i'm genuinely puzzled. of course, i'll do my best to fix it for the next build. ;-)

Share this post


Link to post

@Mr.Rocket: ooh, what a great bug! i was using response file as one big memory chunk, and then tried to `free()` individual portions of it! and somehow i never bothered to test response files with valgrind, so this bug went unnoticed for almost two years. i hope that it is fixed now, and in the next build response files will be great again! ;-)

Share this post


Link to post

@DuckReconMajor also, for some reason windows version is writing zero-length config file. that is prolly why your settings aren't saved. eh, something VERY strange is going on here... i really miss valgrind for wine.

Share this post


Link to post
Posted (edited)

i FUCKIN' LOVE shit-plus-plus. i am used to sane languages (D, for example) to do a Right Thing in dtor. and i was pretty sure that if i'll declare my dtor as virtual, and will call virtual method there, it will be dispatched to the actual overriden method in a subclass. but -- FUCK NO! that is shit-plus-plus, you cannot expect it to do anything sane. just. fickin'. hilarious. now, most of my virtual cleanup functions (including that one in VStream which closes the disk file, for example) are simply ignored.

 

NEVER. EVER. USE C++. sadly, i have to. but i reget every moment of that.

Share this post


Link to post

Not being a programmer, I don't understand the reasons. But I hope you still enjoy working on k8vavoom! While I look forward to new versions, I wouldn't want it at the expense of your happiness :)

Share this post


Link to post
Posted (edited)

thank you. basically, one of my assumptions about c++ was wrong (or, being more correct, my c++ memory rusted). and that assumption is used through the whole codebase, so now i have to re-check almost every source file, to find out if i did it wrong, and fix it. not the end of the world, of course, but highly annoying.

 

sure, i won't drop k8vavoom over that, but i just had to shout out my frustration, otherwise i'd explode into gibs. ;-)

 

what that means for you all is that i found Yet Another Source of Heisenbugs, so the next build will be even more stable. as usual. ;-)

Edited by ketmar

Share this post


Link to post

k8vavoom isn't launching under ZDL properly anymore, it won't remember the config and will reset it, and not long after during play the game begins to put out garbage graphics (corruption in the world and in the menu).

Share this post


Link to post

yep, there was at least one HUGE bug in cli handling, which causes memory corruption. for now, plz, either run it without args (-file should be ok, tho), or wait for the next build (i'm working hard on it). i'm sorry. i just want to make sure that i nuked all memory corruption bugs i know about, therefore no quickfix yet.

 

broken config is another bug i ranted above -- about c++ and destructors. i don't even know why it worked before at all. ;-)

 

thanks for reporting!

Share this post


Link to post
5 hours ago, Lila Feuer said:

It's all cool, just glad to know it's not me. The port is still awesome!

thank you. no, it is not on your side, for sure. something VERY wicked is coming this way: i can crash the engine while running with valgrind (memory access validator), but no crashes with gdb/plain run. yet with plain run there are strange sound glitches, almost like something is trashing sound buffers (and they are completely unrelated to the code, and not even managed by k8vavoom, but by OpenAL). this is my first time when valgrind is plainly refusing to give any useful info on crash, it only tells me that "somehow, your code jumped to the crazy address." which is VERY strange, because valgrind is CPU emulator, and it records the path leads to the invalid address. it is almost like the code just magically nuked valgrind trace info (absolutely impossible), and then tried to kill itself. ;-)

Share this post


Link to post
On 8/7/2019 at 6:59 PM, ketmar said:

Jack and Jill went up the hill to find a public build... and here's what they found!

 

* WARNING! networking code is completely broken for now. i know it, and i will try to restore it later.


* new progam icon by Mr.Rocket! thanks alot!
* added experimental fluidsynth midi backend
* added some decorate codepointers
* removed AJBSP limit to 65536 vertices (and k8vavoom hangups due to it)
* implemented some more UDMF properties
* UDMF parser will not report unknown properties multiple times
* rendering sprites and walls with non-integral alpha levels now shouldn't glitch
* added experimental support for `A_Jump(n, func())` decorate abominations
* adding RandomSpawner to inventory now works (who thought out that idea?!) (thanks, id0!)
* fixed bug with disappearing sprites when alot of huge gameplay pwads loaded (thanks, id0!)
* slopes with total height less or equal to maximum step height won't affect velocity anymore (this is so you can simply step up on a small steep slope instead of being unable to climb it)
* fixed occasional slope troubles (especially with 3d floors); now you should not stuck in empty spaces when you're moving under sloped 3d ceiling, or suddenly go into the air when moving from sloped to normal floor
* you won't endlessly slide off slopes anymore, and should not acquire endless momentum on slopes
* it is now possible to crouch on the water bottom, and swim down with "crouch" button
* it is now possible to fly down with "crouch" button
* corpses won't block movement anymore (this can happen when dead actor is hidden, but not destroyed; hello, Winter's Fury!)
* fixed rare stencil lighting bug (wrong shadows due to wrong assumption about stencil buffer contents)
* stencil lighting optimisations, +3/+5 FPS on Dark Wispers, for example (experimental, sometimes producing wrong lighting, turned off by default)
* optimised model rendering a little, and turned on shadows from models by default
* direct code generation for `[f]randompick()` decorate functions (now it supports up to 255 arguments)
* added experimental background thread for sound loading (can be turned off with "+snd_background_loading 0")
* added experimental background thread for music loading (can be turned off with "+snd_music_background_load 0")
* keyconf aliases will not be saved in config, and won't kill user-defined aliases (don't load a mod, and user-defined aliases will return); it was implemented in original Vavoom, but i broke it
* rewritten ANIMDEFS parser (it was completely wrong; now it is slightly better) (thanks, Mr.Rocket!)
* added fake sprite shadows (a-la Duke3D); thanks to Nash for inspiration
* added support for conditionals in SNDINFO and TERRAIN lumps
* color translations can be applied to decals; added k8vavoom-specific flag to pass blood translation to spawned actors (tl;dr: got rid of duplicate actors and decals whose only difference was their color shade)
* `A_LookEx()` now respects FOV, minsee and maxsee arguments (thanks, TDRR!)
* fixed bug in `A_ChangeVelocity()` (it wasn't worked; thanks, TDRR!)
* fixed bug with floating decorate constants (and again, thanks to TDRR!)
* added experimental support for actor-local constants in Decorate
* colored monster blood now mostly works (i.e. mods with colored blood, like colorfull hell)
* implemented `A_SetSpeed()`, `A_SetFloatSpeed()`, `A_JumpIfMasterCloser()`, `A_JumpIfHigherOrLower()`, `A_Blast()` decorate actions
* rewritten cluster leaving and entering texts; restored Doom1 episode end texts (thanks, DuckReconMajor!)
* fixed bugs in additive surface renderer (sometimes additive surfaces wasn't there at all) (thanks, Gunrock!)
* made "summon" autocompletion slightly better (and you can summon replaced actor now)
* added some debug cheats ("WhereIsSrc classname" to see in which file the class was defined, "PrintXXX" to print various class info, including partial list of used sprites) (thanks, id0!)
* it is now possible to preload most used sprites on map loading (turned off by default, because it is quite slow and GPU-demanding)
* fixed tracer bug: we could hit a line, but forgot to set `tmtrace_t` field; oops! (thanks, id0!)
* added "changeweapon" console command; can be bound to a key, and used like this: "changeweapon supershotgun shotgun chaingun", and it will cycle between the named weapons (WARNING! weapons without ammo will still be selected!)
* added alot of code to process bouncing and ripping missiles (dunno if it is right, but it is definitely better now) (thanks, id0)
* cheating is always enabled in standalone client (i.e. you don't need to set "sv_cheat" to 1 to enable all cheats in single-player games)
* fixed some lightmapping bugs (occasional missing surfaces)
* fixed bug with invalid lightmaps on scrolling floors and ceilings
 

p.s.: it is now possible to restore most menu options to their defaults by pressing "backspace".

I tried testing out DoomTerrains with K8Vavoom and it didn't work.

DoomTerrains.zip

Share this post


Link to post
54 minutes ago, Gunrock said:

I tried testing out DoomTerrains with K8Vavoom and it didn't work.

the usual problem with [g]zdoom being lax on proper naming. most of the things in k8vavoom are case-sensitive for speed, and [g]zdoom is case-insensitive. i'm slowly turning k8vavoom into case-insensitive, though.

 

tl;dr: thank you, will be fixed in the next build!

Share this post


Link to post
16 hours ago, ketmar said:

the usual problem with [g]zdoom being lax on proper naming. most of the things in k8vavoom are case-sensitive for speed, and [g]zdoom is case-insensitive. i'm slowly turning k8vavoom into case-insensitive, though.

 

tl;dr: thank you, will be fixed in the next build!

Thats cool! Also is this related to the same case-sensitive problem too?

Watertest.zip

Share this post


Link to post
2 hours ago, Gunrock said:

Also is this related to the same case-sensitive problem too?

no, this is different. k8vavoom has no concept of "drowning" at all, the player can stay underwater forever without any consequences. tbh, this (drowning) is a very low-priority thing that i am not planning to introduce in any foreseeable future. there is also no code to emit other kinds of "going under/overwater" sounds. this may be fixed, though (prolly in one of the next builds).

 

p.s.: thank you for your samples, btw. it is always great to have a small sample to work with!

 

p.p.s.: tbh, vavoom swimming code was clearly unfinished. i fixed some of the most obvious issues with it, but there is still alot to do there. and introducing "drowning" requires more than a simple two-liner fix, so it have to wait. sorry.

Edited by ketmar

Share this post


Link to post
8 hours ago, ketmar said:

no, this is different. k8vavoom has no concept of "drowning" at all, the player can stay underwater forever without any consequences. tbh, this (drowning) is a very low-priority thing that i am not planning to introduce in any foreseeable future. there is also no code to emit other kinds of "going under/overwater" sounds. this may be fixed, though (prolly in one of the next builds).

 

p.s.: thank you for your samples, btw. it is always great to have a small sample to work with!

 

p.p.s.: tbh, vavoom swimming code was clearly unfinished. i fixed some of the most obvious issues with it, but there is still alot to do there. and introducing "drowning" requires more than a simple two-liner fix, so it have to wait. sorry.

Oh ok.

Share this post


Link to post
On 8/7/2019 at 9:59 PM, ketmar said:

Jack and Jill went up the hill to find a public build... and here's what they found!

 

LIST OF CHANGES!!!
 

p.s.: it is now possible to restore most menu options to their defaults by pressing "backspace".

I seriously don't know how i missed this update! Downloading and hopefully finally finishing the TDBots for Vavoom.

Also, i think i never told you what i think about this port. IMO it's just fantastic! I love how it looks and the lightmapped renderer with extra smoothing looks and runs great even on my Intel HD4000 (or that's what i think it is based on it's support for GL4.0) at 1366x768, which is something i can't say about most other sourceports. I also tried the stenciled lighting but it's too slow for my old GPU and anyways i prefer the smooth shadows lightmapping provides. I also love the Quake-y particle effects. It's like playing Doom but with everything i like from Quake (Which is mostly the effects as you can see), i really applaud you for your efforts on continuing Vavoom development.

 

This has also become my most used non-ZDoom family sourceport, and 3rd most used overall. I use ZDoom LE/ZDoom32 (practically the same so i count them as one) and Zandro the most but that's because they are the ones i just know how to mod the best. And really, for a sourceport to get into my most used list it's got to be very good, so that should speak quite a bit about how awesome K8Vavoom is.

There's bugs of course, and one of them was seeing the sky through middletexture bars. I can't upload a screenshot ATM but it happens on Doom 2 MAP26 on the hallways with midtex bars on the sides.

 

EDIT: Oh and about your "second developer" offer, i can do that so you could in the end get to at least full GZDoom 1.8.6 compatibility. All my mods try something new in terms of coding so reaching that goal possibly won't take too long.

Just be wary, the last goal involves fixing Brutal Doom v20b compatibility :)

Edited by -TDRR-

Share this post


Link to post
36 minutes ago, -TDRR- said:

I seriously don't know how i missed this update! Downloading and hopefully finally finishing the TDBots for Vavoom.

don't bother, it has some really bad bugs, and new one is on its way! ;-) (and it has even more decorate actions implemented)

 

36 minutes ago, -TDRR- said:

Also, i think i never told you what i think about this port. IMO it's just fantastic!

thank you alot!

 

36 minutes ago, -TDRR- said:

And really, for a sourceport to get into my most used list it's got to be very good, so that should speak quite a bit about how awesome K8Vavoom is.

still, most of the foundation work was done by Janis. sure, i did alot too, but without Janis it wouldn't be possible. i still wonder WHAT Vavoom could be if Janis kept working on it all these years... prolly light years ahead of where GZDoom is now. ;-)

 

36 minutes ago, -TDRR- said:

Oh and about your "second developer" offer, i can do that

that would be great!

 

36 minutes ago, -TDRR- said:

Just be wary, the last goal involves fixing Brutal Doom v20b compatibility :)

brutal shi... doom v20 is not "incompatible", it is plainly broken. gzdoom goes a big way to make old and broken code work, and i simply won't do that. it is possible to run bdv21 with k8vavoom, though (but you need some secret developer keys for that, and perform some manual fixes on it ;-).

 

p.s.: as for bugs, at least "mypos" console command output will help. maybe i'll simply notice the bug myself then.

Edited by ketmar

Share this post


Link to post
Just now, ketmar said:

brutal shi... doom v20 is not "incompatible", it is plainly broken. gzdoom goes a big way to make old and broken code work, and i simply won't do that. it is possible to run bdv21 with k8vavoom, though (but you need some secret developer keys for that, and perform some manual fixes on it ;-).

Oh trust me, i know it's broken more than most people and i'm currently digging in it's code trying to get it to run in K8Vavoom. Seriously, if i can get Project Brutality Redux running on K8V before i release it, that would be very sick. Don't worry, i'm working on making the code less messy and ugly.

But what are the largest issues that prevent BDv20 from even booting up in K8Vavoom and the ones that BDv21 fixes? I will go through each and every single issue if you tell me what they are, no matter if it takes a long while.

Anyways, the next mods i would like to get working in K8Vavoom are Supreme Invasion as well as Varied Doom.
Supreme Invasion actually works very well, almost identically to ZDoom. However, A_SpawnItemEx seems to be slightly wrong. This appears to be because it's using numbers instead of constants, but i don't know what
A_SpawnItemEx("Zombieman", 0, 0, 0, 0, 0, 0, 0, 288, 0, 999)

means. What flags does the number 288 contain?

Varied Doom works nice too and there's a couple missing features but we will get to those when v2 comes out (In half a hour i think?)

 

Something that REALLY bothers me is having to memorize all the CVARs of the mods. Is it possible to add autocompletion for CVARINFO-added CVARs? It's fine if you don't add full MENUDEF support but at least autocompletion would help massively.

Share this post


Link to post
38 minutes ago, -TDRR- said:

A_SpawnItemEx("Zombieman", 0, 0, 0, 0, 0, 0, 0, 288, 0, 999)

means. What flags does the number 288 contain?

SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG

and both those flags are implemented, and should work...

 

38 minutes ago, -TDRR- said:

Is it possible to add autocompletion for CVARINFO-added CVARs?

hm... they should be there. i'll check it, tnx.

 

also, many things in menudef works too. sometimes you have to manually invoke menu from console with "setmenu menuname", though.

Share this post


Link to post
Just now, ketmar said:

SXF_NOCHECKPOSITION|SXF_TRANSFERAMBUSHFLAG 

and both those flags are implemented, and should work...

That didn't fix it. Spawns are still offset by a noticeable amount, and this causes monsters to get stuck on the ledges of the platform on D2 MAP01's blue room.

 

Just now, ketmar said:

also, many things in menudef works too. sometimes you have to manually invoke menu from console with "setmenu menuname", though.

Really? I had no idea. Why do keys on KEYCONF not work though? I can't see any of them in any of the menus.

Share this post


Link to post
31 minutes ago, -TDRR- said:

That didn't fix it. Spawns are still offset by a noticeable amount,

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.

 

31 minutes ago, -TDRR- said:

Spawns are still offset by a noticeable amount, and this causes monsters to get stuck on the ledges of the platform on D2 MAP01's blue room.

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.

 

31 minutes ago, -TDRR- said:

Why do keys on KEYCONF not work though?

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.

 

1 hour ago, -TDRR- said:

But what are the largest issues that prevent BDv20 from even booting up in K8Vavoom and the ones that BDv21 fixes?

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.

 

 

p.s.: btw, it happens that i recently checked Varied Doom, and it seems to work. and you can access its menu with "setmenu vd_options" -- it is almost fully supported.

 

the reason i didn't implemented menu integration is that because i don't understand how GZDoom chooses what menu to show and where. so the menu is parsed, and k8vavoom knows about it, but it is simply hidden.

 

also, "openmenu" works too (that is how GZDoom calls that command).

Edited by ketmar

Share this post


Link to post

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 = mymodmenuname;
  }
}

 

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

 

p.s.: don't try to override standard menus, k8vavoom will not allow you to do that. at all. ;-) and shaders are protected too.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×