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

k8vavoom: no good thing ever dies!

Recommended Posts

Yeah there's no mods, as ketmar pointed out. 

 

This is my laptop. Running the standard Win10 OS with a bit of Razer stuff that came with the laptop. If there's any more info I can give, let me know.

Share this post


Link to post
33 minutes ago, vanilla_d00m said:

The weapon vanish when I type FOV 100 or 120, 130,140

yep, this is expected effect. psprite rendering is semi-broken for now, and i still don't understand what Janis tried to do there (i.e. i cannot wrap my head around that math). sorry.

33 minutes ago, vanilla_d00m said:

Good port tho.

thank you! ;-)

 

16 minutes ago, vanilla_d00m said:

Will it have OPL emulation someday?

yes, there are plans to add at least nuked OPL emulator. i already added FluidSynth, tho, so in the next release you will be able to choose between timidity and fluid.

 

p.s.: it looks like you're using Vavoom, not k8vavoom (at least not the latest k8vavoom version). please, note that they are very different engines at this stage. also, judging from your screenshot, k8vavoom won't be able to run at your hardware, sorry. k8vavoom requires GLSL120 and VBO support.

Share this post


Link to post
17 hours ago, ketmar said:

@-TDRR- so far i see that we have an VM stack overflow due to infinite recursion (which is caught much better now, thank you!). it seems that i did something wrong in `A_LookEx()`, and got into infinite callstate chain loop.

 

@-TDRR- and now i see. `GiveInventory()` works like this:

1. spawns item

2. emulates item pickup by calling the corresponding method

 

here, item is spawned at player's location, because... because that is what the default. do you see?

 

item is spawned. then pickup handler called. then bot tries to wander (due to `A_LookEx()` flags; and we're still inside item's pickup handler!). then it immediately hits the spawned item, and tries to pick it up. and it goes on, and on, and on until it blows up the stack. lol.

 

i workarounded this, and VM doesn't crash anymore. yet it needs some more thinking.

Ah, thanks for telling me that because that's just a bad habit of mine. For some reason while working on the TDBots i added the "Pickup" state to all of the items even though the "Use" state and the +INVENTORY.AUTOACTIVATE flag are in place, i went ahead and removed them now.

 

Now we got some progress! The bots now shoot me and dodge if i stand in front of them. Another bug report: A_LookEx's fov parameter (the one before the " ") seems to be completely ignored and defaulted to 90 degrees.

 

I suspect A_ChangeVelocity doesn't work, replacing it with A_Recoil fixes the issue and the bots can move normally.

 

However another thing i noticed, is that you can't pass a custom constant to A_Recoil, it makes the bot not move at all. Any chance that could be fixed? It's just nicer to have the speed on a single value at the top of the file rather than spread across all functions.

 

Also, since A_CheckLOF doesn't work, i guess i can use the TDBotsV15Skulltag version as a base for a Vavoom version since it already has everything converted to projectiles and A_JumpIfTargetInLOS. Don't worry about the maintenance burden, i'm going to do a script file to generate the Zandro and Vavoom versions from the base TDBots, shouldn't be hard since it's almost all just search and replace.

Edited by -TDRR-

Share this post


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

Ah, thanks for telling me that because that's just a bad habit of mine. For some reason while working on the TDBots i added the "Pickup" state to all of the items even though the "Use" state and the +INVENTORY.AUTOACTIVATE flag are in place, i went ahead and removed them now.

and i fixed the bug in k8vavoom too. double win. ;-)

 

43 minutes ago, -TDRR- said:

A_LookEx's fov parameter (the one before the " ") seems to be completely ignored and defaulted to 90 degrees

yep, it is using the default monster sight checking, and monster FOV is hardcoded. i think i'll fix that for the next build.

 

43 minutes ago, -TDRR- said:

I suspect A_ChangeVelocity doesn't work, replacing it with A_Recoil fixes the issue and the bots can move normally.

it is strange, because both are modifying velocity field. can you craft a minified sample that works in zandro/gzdoom, but doesn't work in k8vavoom, if you please?

 

Quote

However another thing i noticed, is that you can't pass a custom constant to A_Recoil, it makes the bot not move at all.

hm. it should work, if you defined the constant with the right type, and outside of all actor definitions. sample will be good too. ;-)

 

Quote

Also, since A_CheckLOF doesn't work, i guess i can use the TDBotsV15Skulltag version as a base for a Vavoom version since it already has everything converted to projectiles and A_JumpIfTargetInLOS.

oh, i forgot about it being not fully implemented. tbh, it is a freakin' monster (as many ZDoom decorate actions), and each time i look at it i am thinking: "ok, next time, maybe..." ;-)

 

p.s.: it seems that for `A_ChangeVelocity()` it should be multiplied to tic rate, but i am not sure. that's why i need to have a sample.

Edited by ketmar

Share this post


Link to post

k8v_changevelocitysample.zip

There you go. In ZDoom, after going to MAP01 and firing a shot, the Zombiemen will start running forwards. In Vavoom, nothing happens.

I thought it was the CVF_REPLACE flag, but no, removing it doesn't fix anything.

Share this post


Link to post
1 hour ago, -TDRR- said:

There you go.

thank you, i'll check.

 

btw, i fixed `A_LookEx()`, it now respects all its arguments (i hope ;-).

Share this post


Link to post
1 hour ago, -TDRR- said:

In ZDoom, after going to MAP01 and firing a shot, the Zombiemen will start running forwards. In Vavoom, nothing happens.

ok, seems to be found and fixed. at least your sample now works the same as in GZDoom. thank you!

 

i am planning to push a new build soon, so if you have something more (except `A_CheckLOF()`) for me to fix, it is a perfect time to kick me. ;-)

Share this post


Link to post
1 hour ago, ketmar said:

ok, seems to be found and fixed. at least your sample now works the same as in GZDoom. thank you!

No problem! Hope to see a public test build soon so i can finish up the TDBots version for it.

Share this post


Link to post
3 hours ago, ketmar said:

hm. it should work, if you defined the constant with the right type, and outside of all actor definitions. sample will be good too. ;-)

const float Bot_MoveSpeed = 12;

That's how it looks. According to A_Recoil's wiki page and SLADE's tip when you hover over it, float is indeed the correct type. However doing A_Recoil(-Bot_MoveSpeed) (- inverts the value so the bot moves forward) doesn't work in Vavoom but it does on ZDoom.

Share this post


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

const float Bot_MoveSpeed = 12;

yay! it was a perfect idiocity on my side! `int` constants were ok, but `float` constants were completely broken. thank you, and fixed.

Share this post


Link to post

Ok so

 

On a whim I tried forcing integrated graphics on k8vavoom, and sure enough, that seems to fix the issue

At first the weapons were squished down to the bottom of the screen. I tried to screenshot it, but oddly enough it print-screened through k8vavoom, capturing everything behind the application.

I messed with the Screen resolution, switching it back and forth and restarting, and this seemed to fix the weapon graphic issue.

Played through some Doom 1 and everything looks great. Only odd thing that happened is when I killed the Cyberdemon there was no text intermission, it just skipped directly to showing the Deimos over hell graphic.

Share this post


Link to post
12 minutes ago, DuckReconMajor said:

I tried to screenshot it,

there is built-in "screenshot" command. you can bind it like this, for exampe:

Bind "backspace" "screenshot"

 

13 minutes ago, DuckReconMajor said:

Only odd thing that happened is when I killed the Cyberdemon there was no text intermission, it just skipped directly to showing the Deimos over hell graphic.

oh, yeah. i didn't even remembered that there should be some text. thank you, i'll take a look.

Share this post


Link to post

Hey ketmar! I found something unusual on Silent Steel's map 3. The body of water that surrounds the two buildings is no longer there. Oddly it shows up in my GZDoom builder editor but in game its gone?

 

Pic 1 shows no water in game and pic 2 water shows up within the map editor.

pic1.png

pic2.jpg

Share this post


Link to post
14 hours ago, DuckReconMajor said:

Only odd thing that happened is when I killed the Cyberdemon there was no text intermission, it just skipped directly to showing the Deimos over hell graphic.

fixed, thanks for reporting!

 

1 hour ago, Gunrock said:

The body of water that surrounds the two buildings is no longer there. Oddly it shows up in my GZDoom builder editor but in game its gone?

my GZDoom doesn't show the water, yeah. and k8vavoom is agree with GZDoom here. i.e. this area looks exactly the same in GZDoom (at least in my GZDoom 3.3 version, i didn't ever bother to upgrade ;-).

 

i'll take a look at the map later, but i suppose that this is gzdb bug. i cannot run gzdb, so i don't know for sure.

 

p.s.: oh, fun thing. the water is there in lightmapped renderer, but not in stenciled (at least in the upcoming build ;-):

Spoiler

4rmay3.png

 

now i have to find out why stenciled renderer is missing the water...

ok, found it, now stenciled renderer has it too.

 

tl;dr: in the last public build there was a bug in additive surface renderer. that part of the code is fixed now (for both renderers), and in the next build the water will be there. ;-) thanks for reporting!

Edited by ketmar

Share this post


Link to post

So it was about time I assaulted this topic :p.

 

On a serious note, Vavoom is one of the ports that I have not managed to check out yet, but I probably will in the future (there is at least one Hexen mod that was made specifically for it). But, it's no longer being developed, and I was looking for other ports that support Hexen to see how the experience varies between ports (other than GZDoom and Choco).

 

I know from the OP that the other Doom engine games are currently not being maintained, but, is that going to ever change? Or is k8vavoom eventually just going to drop them altogether, similar to how Crispy also dropped the other games a while ago?

Share this post


Link to post
4 hours ago, seed said:

I know from the OP that the other Doom engine games are currently not being maintained, but, is that going to ever change? Or is k8vavoom eventually just going to drop them altogether, similar to how Crispy also dropped the other games a while ago?

no, i absolutely don't have any intents to drop H/H/S. they simply don't have enough testers, so i'm trying to tell people that k8vavoom is not the best choice to play those games. i.e. if somebody wants to "just play a game", they may be annoyed by various bugs.

 

but i'll gladly accept bug reports for H/H/S, and will do my best to fix them. there was some period of time when those games weren't included, because i had no time to even make them work again, but i hope that those times are long gone.

 

so if you want to play those games with k8vavoom, and report any bugs you'll find, please, do! ;-)

 

 

p.s.: as for mod... it is not really a mod, it is a TC -- Scattered Evil. i am in (sporadic) contact with SE maintainer, and we have some our secret plans. ;-) of course, there aren't enough time and developers, as usual. but the plans are there! ;-)

 

p.p.s.: new public build is on its way, so if you want to try k8vavoom, wait for several days more. the new build has alot of fixes and enhancements, as usual.

Edited by ketmar

Share this post


Link to post

something weird is going on with the world: this time i found a weird lightmapping bug *before* i uploaded the build, in pre-upload test run. usually it happens in the reverse order...

Share this post


Link to post

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".

Edited by ketmar

Share this post


Link to post

Holy freaking shit that's a lot of adding and fixing!

I know what I'll be doing pretty much all tomorrow night after band practice.. ;)

Playing k8vavoom!

 

Nice Thanks! :)

Share this post


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

Holy freaking shit that's a lot of adding and fixing!

and this is not even a complete changelog! ;-)

 

tbh, alot of my time still spent on various code cleanups and refactoring. it is not because original Vavoom code was that bad, no, but because i want to add even more features, but keep the code maintainable.

 

and of course, i am cheating by putting two-line-fixes as separate changelog entries, to make it look like i did more. ;-)

Share this post


Link to post
2 minutes ago, ketmar said:

and this is not even a complete changelog! ;-)

Geez!

3 minutes ago, ketmar said:

tbh, alot of my time still spent on various code cleanups and refactoring. it is not because original Vavoom code was that bad, no, but because i want to add even more features, but keep the code maintainable.

Nothing wrong with that!

The way I look at it is like cooking dinner for everyone, at the end the dishes are dirty so they need washed.

If they don't get washed, the code will be a mess, and someone would be lucky to find a clean fork. :P 

 

7 minutes ago, ketmar said:

and of course, i am cheating by putting two-line-fixes as separate changelog entries, to make it look like i did more. ;-)

Freak'n sneaky.. lol

 

 

Share this post


Link to post

ah, nope, everything's ok with the world: just found a bug in line tracing/coldet. it was there for a long time, though, so i guess one more build with it doesn't matter. will be workarounded (i don't know how to fix it -- doom coldet logic is absolutely fubared) in the next build.

Share this post


Link to post

Hi,

It seems that k8 doesn't support a response file anymore?

Before I would have a args.cfg which held all the commands for the executable at launch.

At the time of launch, the args.cfg would populate with all selected/specified commands and the game would run as expected.

With k8vavoom.exe @args.cfg

 

Now the @ response file on command line doesn't seem to do anything. 

 

Otherwise without the response file I would have to have something like this at command line:

k8vavoom.exe -doom2 +name Mr.Rocket +Maxplayers 2 +Deathmatch 1 +RespawnMonsters 0 +Fast 0 +Skill 4 +Nomonsters 1 +TimeLimit 0 +noexit 0 +map MAP01 +addbot 1

Which in-turn has no way to store the commands.

 

Just wondering if it was something that was left out intentionally before I have to rewrite my dll.

 

Thanks

Edited by Mr.Rocket

Share this post


Link to post
6 hours ago, Mr.Rocket said:

Just wondering if it was something that was left out intentionally

nonono. it works with GNU/Linux version, and i have no plans to remove that feature. i'll check windows .exe later, and if it is broken, it will be restored. no worries, response files is handy feature (and doesn't cost me anything), so i won't going to remove it. tnx for reposting, as usual! ;-)

Share this post


Link to post

and fresh news: two bugs, of course. it turns out that protection powerup was completely broken. in most cases any protection powerup actor protects you from everything, letting you to get at most 1HP of damage. it was even able to protect you from built-in "suicide" console command.

Share this post


Link to post

Great news on the K8Vavoom update!!! Dark Wispers: Remastered is done.

Quick info: Dark Wispers is a small to medium size 4 map set that takes place before the events of "Project Slipgate" and "Dissolution". You are sent into the nether-realm to retrieve an artifact that is critical in defeating the monster infestation on the planet. 

Compatible with both GZDoom and K8Vavoom sources.

Please give feedback, bug reports, and suggestions before I upload it to Idgames database.

 

Pics and temporary download link:

Dark Wispers: Remastered

 

 

 

 

wispers2.jpg

wispers1.jpg

Edited by Gunrock : Download change

Share this post


Link to post

Quake? who needs that Quake for 3d? show those screenees to Quake players, and they will immediately recognize some "advanced Quake sourceport" there! ;-)

 

p.s.: now it only needs some brightmaps for those lamps and runes, and it will be even better Quake than Quake itself! ;-)

Share this post


Link to post
Guest
This topic is now closed to further replies.
×