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

k8vavoom: no good thing ever dies!

Recommended Posts

Well truth be told, it does have thousands of happy users!

So quit your lolly gagg'n and get the wip crack'n :P

Share this post


Link to post
3 minutes ago, Mr.Rocket said:

Well truth be told, it does how thousands of happy users!

so where's my billions of donated bucks?! i want to drop coding already and spend my life partying with hookers eh... i mean to work even harder!

Share this post


Link to post

Sorry my typos.. we need a bigger money jar!

I mean you, otherwise the hookers won't think there's enough to go around. will then be able to work harder..

 

Anyways, I'll get a donation to you when I'm able also..

And I can't wait for 809, if that's the current build number.

Edited by Mr.Rocket

Share this post


Link to post
36 minutes ago, Mr.Rocket said:

809, if that's the current build number

ah, the builds simply tagged with the release date. so 540717, for example, means Jul, 17, LIV A.S.

Share this post


Link to post

and a note. i guess i'll just push out the build Very Soon, because otherwise i can delay it for any time -- there are always "those two small things to fix". and i also want to clean my changelog.

Share this post


Link to post

you're in for surprise, you're in for a shock, we got the new build in our stock!

 

 

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

* fixed (i hope) HUGE bug with memory management in CLI handling (especially with response files) (thanks, Mr.Rocket!)
* completely rewritten the way spawn system works; previous code didn't do enough type checks (this is still experimental, and may break some mods)
* oops! forgot to shutdown music player when shutting down audio subsystem (this could cause sporadical crashes on quitting the game)
* i completely messed C++ dtors, and for many objects it missed shutdown/cleanup code; oops (fixed partially)
* previous tracer fix was wrong; made a new one! ;-)
* fixed some OOB reads/writes in lightmapping code for too big lightmaps
* fixed protection powerups (they weren't working right for custom damage types)
* fixed damage types; fixed "PowerDamage" powerup (it now works as expected)
* regeneration powerup now respects "strength" property (and that property is not ignored in decorate anymore)
* added "PowerBuddha" powerup
* made menu cursor slightly more visible (and reorganised video menus a little)
* added option to show selected weapon name in FS HUD (off by default)
* r_chasecam fixes: chasecam won't move into the geometry, and its movement is slightly interpolated
* completely rewritten weapon slot management code; now you should have access to all weapons: if any weapon have no defined slot, and didn't mentioned in any configs, it will be put to bindable slot 11; also, keyconf/gameinfo weapon slot definitions now has priority over playerpawn definitions (thanks, id0!)
* fixed elevator logic, so you won't stuck in Silent Steel MAP01 elevator anymore (or in other similar elevators)
* implemented "ReplaceActor" support for mapinfo skilldefs
* added "Zoom" keybind; some weapons can do some special/unusual actions (or simply implement iron sights) with `Zoom` state; so be it
* if inventory using failed, advance inventory only for Heretic and Hexen (game names are hardcoded for now)
* partially implemented `A_SetRenderStyle()` decorate action (partially, because not all render styles are supported by k8vavoom itself)
* implemented missiles in `A_CustomBulletAttack()` and `A_FireBullets()` decorate actions
* implemented `A_Weave()`, `A_SetMass()`, `A_Turn()` decorate actions
* implemented most missing arguments to `A_BFGSpray()` decorate action
* implemented `A_GiveToChildren()` decorate action
* implemented most of `A_DamageXXX()` decorate actions
* implemented most of `A_KillXXX()` decorate actions
* implemented most of `A_RemoveXXX()` decorate actions
* implemented most of `A_RaiseXXX()` decorate actions
* implemented "SPECIAL" decorate actor flag
* experimental implementation of "BumpSpecial" decorate flag (thanks, id0!)
* fixed bug in `A_SpawnItem()` (thanks, TDRR!)
* made `A_GiveToTarget()` and `A_Wander()` more complete (thanks, id0!)
* exported `ScriptedMarine` decorate codepointers (thanks, id0!)
* fixed terrain reader to be case-insensitive (thanks, Gunrock!)
* fixed ACSF velocity functions (they were reporting/setting complete BS) (thanks, id0!)
* searching for sectors and lines with tag 0 should succeed
* added "doharmspecies" decorate flag support
* automatically ignore decorate Chex Quest actors if Chex Quest is not loaded
* added official option to emulate broken gzdoom decorate gotos (misc options); WARNING! please, read the help text there!
* colored menu help texts a little, so you will easily notice some important text there
* implemented "kill" ACS scripts, and their supporting flags (thanks, TDRR!)

Share this post


Link to post

NICE!!!

It's working again!

Thank you ketmar!

 

There is one thing I should mention, and it did this in the previous builds too, on first run there's a small dialog that pops up with a msg saying that it "Failed to create OpenAL context" or something to that nature. The game still ran and I never saw the error again. But now the dialog keeps popping back up not allow the game to start.

 

Edit:

 

It seems as though I have to reboot my system before I can get k8 to run again without the OpenAL error.

Not sure why yet, did I have to free memory?

 

 

Other than that, this freak'n rocks so far!

 

Cheers!

Edited by Mr.Rocket

Share this post


Link to post
11 hours ago, ketmar said:

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.

I'm probably going to upload the TDBots version i have been used for testing if you need it.

Yeah i know i'm the only guy to come up with such silly ideas.
 

11 hours ago, ketmar said:

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)

That's quite a bit off-putting though, so maybe i'm just going to keep PB:R on Zandro and ZDoom. Oh well, it was probably going to be too slow to play anyways.

 

 

11 hours ago, ketmar said:

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. ;-)

Yeah i can see why would you hate it, it's rather lax and not as flexible as most other scripting languages.

 

11 hours ago, ketmar said:

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! ;-)

That's great! I hope that helps with increasing performance in various maps. It shows your exact cone of vision? Would increasing the FOV change anything?

Share this post


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

It seems as though I have to reboot my system before I can get k8 to run again without the OpenAL error.

Not sure why yet, did I have to free memory?

tbh, i don't know. it should "just work", but i know nothing about current windows versions, and just hope that OpenAL will do it. i should prolly upgrade OpenAL to the lastest version, though. my cross-build environment is quite... strange, tho, and i had to patch some libraries to get a static .exe (actually, k8vavoom.exe contains SDL2 and OpenAL libraries compiled in), so i am somewhat afraid of changing things. but i'll prolly try anyway.

 

1 hour ago, Mr.Rocket said:

Other than that, this freak'n rocks so far!

thank you!

Share this post


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

I'm probably going to upload the TDBots version i have been used for testing if you need it.

that would be great.

 

33 minutes ago, -TDRR- said:

Yeah i know i'm the only guy to come up with such silly ideas.

but it should work anyway! so this is definitely a bug, and i love such weird bugs. it is boring to fix things everybody's doing! ;-)

 

33 minutes ago, -TDRR- said:

That's quite a bit off-putting though, so maybe i'm just going to keep PB:R on Zandro and ZDoom.

sorry, i was only joking. my sense of humor is not the best one, i'm afraid. of course, i have nothing against PB running with k8vavoom, i just don't believe that it is possible to fix it. but i may be wrong here. ;-)

 

33 minutes ago, -TDRR- said:

Oh well, it was probably going to be too slow to play anyways.

standard doom maps should be playable, i think.

 

33 minutes ago, -TDRR- said:

Yeah i can see why would you hate it, it's rather lax and not as flexible as most other scripting languages.

it is badly designed. like, the whole thing is missing separators/terminators, so i cannot reliably skip something my parser doesn't know about. also, internal commands (like "wait" or "goto") seems to be carefully choosen to fit 4-char sprite name limit, so you can't have a sprite named "fail", for example. actually, i believe that GZDoom jumps through the hoops to make it work, and i absolutely won't do that.

 

33 minutes ago, -TDRR- said:

It shows your exact cone of vision? Would increasing the FOV change anything?

it shows all rendered segs. k8vavoom automap granularity is by seg, not by linedef, so you'll get a quite precise view of what was rendered, it is not an approximation, it is as precise as it can be (because the engine is rendering by segs too).

 

p.s.: you may also notice that looking at the floor renders almost nothing, for example. yeah, running with your head down can help for huge maps. not that you can play this way, though -- it is impossible to shoot monsters while looking at the floor. ;-)

Edited by ketmar

Share this post


Link to post
Just now, ketmar said:

that would be great.

TDBotsV14Vavoom-8-18-19.zip

There you go. (Just in case, this is not the latest version, it's missing some features but first i want to get the core stuff working)
 

Just now, ketmar said:

sorry, i was only joking. my sense of humor is not the best one, i'm afraid. of course, i have nothing against PB running with k8vavoom, i just don't believe that it is possible to fix it. but i may be wrong here. ;-)

Well, it's not so much that, but again, PB Redux is comparatively HUGE vs BDv20. Meaning it's about x4 to x6 times larger, and with many of the same hacks because at the time PA1NKI113R (or however that's spelled) was a bit lazy on cleaning up messes.

 

1 minute ago, ketmar said:

standard doom maps should be playable, i think.

Depends, really, i doubt i will be able to test much of it in this PC. K8Vavoom is reasonably more demanding than ZDoom LE, and even on ZDoom LE i get stuttering and occassional low framerates, so at least for me it's mostly out of the question.
 

4 minutes ago, ketmar said:

it is badly designed. like, the whole thing is missing separators/terminators, so i cannot reliably skip something my parser doesn't know about. also, internal commands (like "wait" or "goto") seems to be carefully choosen to fit 4-char sprite name limit, so you can't have a sprite named "fail", for example. actually, i believe that GZDoom jumps through the hoops to make it work, and i absolutely won't do that.

Yeah, but still, i just grew attached to it ever since i started modding 4 years ago, and there's barely anything i would want to change about the language. So yeah that's the reason i wouldn't use VavoomC to define many actors unless it's something very small.

 

6 minutes ago, ketmar said:

it shows all rendered segs. k8vavoom automap granularity is by seg, not by linedef, so you'll get a quite precise view of what was rendered, it is not an approximation, it is as precise as it can be (because the engine is rendering by segs too).

 

p.s.: you may also notice that looking at the floor renders almost nothing, for example. yeah, running with your head down can help for huge maps. not that you can play this way, though -- it is impossible to shoot monsters while looking at the floor. ;-)

That's really, really neat. In ZDoom, looking down doesn't help the framerate at all, not even in the GL renderer. Nice to know that K8Vavoom has quite good draw culling.

Share this post


Link to post
5 hours ago, -TDRR- said:

There you go. (Just in case, this is not the latest version, it's missing some features but first i want to get the core stuff working)

thank you! i'll take a look.

 

5 hours ago, -TDRR- said:

PB Redux is comparatively HUGE vs BDv20

yeah. that's why i think that fixing it is almost impossible: there is simply too much code to... let's say "untangle".

 

5 hours ago, -TDRR- said:

Yeah, but still, i just grew attached to it ever since i started modding 4 years ago, and there's barely anything i would want to change about the language. So yeah that's the reason i wouldn't use VavoomC to define many actors unless it's something very small.

you're welcome, of course! ;-) i strongly believe that there is no "The Only One Right Way" to do things anyway. after all, built-in BDW and Gore mods are done in decorate too -- because it is easier this way. and there is support for code blocks in decorate too, so you can write simple logic there (just take a look at Gore mod, it is full of code blocks that checks some args and cvars).

 

5 hours ago, -TDRR- said:

That's really, really neat. In ZDoom, looking down doesn't help the framerate at all, not even in the GL renderer. Nice to know that K8Vavoom has quite good draw culling.

i am still trying to design 2D clipper (Doom clipper is basically 1D), but this is quite hard. yet i added some simple checks, so if the camera cannot see midtexture part of a wall, that wall considered solid. and it does quite aggressive frustum culling too.

 

i am also thinking about combined BSP/portal rendering. currently, almost any 2S wall is considered "non-clipping", even if its midtext is obscured by other walls, and is impossible to see. this is because clipper is 1D, and this is what makes some complex map unnecessarily slow. i have several ideas of how to solve it, and i hope to find something that will allow me to do fast and efficient 2D (or 3D) clipping.

 

p.s.: putting non-transparent midtexture helps too. if midtex is not transparent, and has no holes, clipper is usually able to notice that, and it considers such wall "solid". this can be used in huge maps to improve rendering. like, for example, if you have a courtyard with the gates, and you cannot see over its walls, you can put a 2S wall behind those gates, and make its midtex solid. then clipper will be able to clip everything behind the gates (which cannot be clipped if a map is built in "normal" way, because gates doesn't block the view due to their top texture being transparent (usually) to not block the skies).

Edited by ketmar

Share this post


Link to post

so, i finally forced myself to write a simple class checker. now i am almost sure that c++ and vc classes/structs will be in sync. strangely enough, there were no glaring desync bugs. i suspect some bug in the checker.

Share this post


Link to post
On 8/19/2019 at 5:59 AM, ketmar said:

yeah. that's why i think that fixing it is almost impossible: there is simply too much code to... let's say "untangle".

Yeah, pretty much. I cleaned up a lot but no dice on it running on K8Vavoom. Most likely i won't be able to do this, far too many errors at startup.
 

On 8/19/2019 at 5:59 AM, ketmar said:

you're welcome, of course! ;-) i strongly believe that there is no "The Only One Right Way" to do things anyway. after all, built-in BDW and Gore mods are done in decorate too -- because it is easier this way. and there is support for code blocks in decorate too, so you can write simple logic there (just take a look at Gore mod, it is full of code blocks that checks some args and cvars).

Wait, so if and else statements work in K8Vavoom's DECORATE? I thought you were aiming for ZDoom 2.8.1 featureset or something like that. That's really cool regardless.

 

On 8/19/2019 at 5:59 AM, ketmar said:

i am still trying to design 2D clipper (Doom clipper is basically 1D), but this is quite hard. yet i added some simple checks, so if the camera cannot see midtexture part of a wall, that wall considered solid. and it does quite aggressive frustum culling too.

 

i am also thinking about combined BSP/portal rendering. currently, almost any 2S wall is considered "non-clipping", even if its midtext is obscured by other walls, and is impossible to see. this is because clipper is 1D, and this is what makes some complex map unnecessarily slow. i have several ideas of how to solve it, and i hope to find something that will allow me to do fast and efficient 2D (or 3D) clipping.

 

p.s.: putting non-transparent midtexture helps too. if midtex is not transparent, and has no holes, clipper is usually able to notice that, and it considers such wall "solid". this can be used in huge maps to improve rendering. like, for example, if you have a courtyard with the gates, and you cannot see over its walls, you can put a 2S wall behind those gates, and make its midtex solid. then clipper will be able to clip everything behind the gates (which cannot be clipped if a map is built in "normal" way, because gates doesn't block the view due to their top texture being transparent (usually) to not block the skies).

Good to know. Hopefully i can optimize my K8V-exclusive maps to make use of this info (while it works at least :P) as i'm indeed getting FPS dips in various places.

Share this post


Link to post
6 hours ago, -TDRR- said:

Wait, so if and else statements work in K8Vavoom's DECORATE?

yeah. it is still somewhat incomplete, but mostly works. for/while are considered harmful, tho, and k8vavoom will ask you to use special CLI option to enable it (it will tell you). besides, in the last public build assigns in expressions aren't implemented (already fixed), so there was a little sense in `for`, for example -- you couldn't even write an init expression! ;-)

 

6 hours ago, -TDRR- said:

thought you were aiming for ZDoom 2.8.1 featureset or something like that.

i don't have a strict version in mind. it is more like "ok, this mod is not working. let's see... aha, it missing that list of features." then i'm either implementing the features, or "ok, mod, gtfo".

 

6 hours ago, -TDRR- said:

Hopefully i can optimize my K8V-exclusive maps to make use of this info

it may help not only k8vavoom, but other engines too, i think. i believe that at least some other engines are using solid midtex for clipping. and if they aren't, then why? ;-)

 

also, i am planning to implement some caching on backend too. right now, k8vavoom starts each frame from scratch, and doesn't try to cache map parts on GPU. and you have to pass at least 5 floats for each map vertex (minimal case for non-lightmapped surface). yet most parts of the map are static, so if i'll find a way to cache them in VBO somehow, it will be one shortint for vertex instead. should make a big difference. also, the rendering is done with segs (something that should be changed too), so k8vavoom passes even more vertices than you may guess from the image.

 

(with stenciled renderer it is even worser, as it sends map geometry to GPU at least 3 times: for ambient lighting, for texturing, and for fog).

 

the (in)famous Frozen Time Bridge is barely walkable for now. absolutely unacceptable.

Edited by ketmar

Share this post


Link to post
On 7/29/2019 at 11:03 AM, ketmar said:

yeah, heretic, hexen, and strife got almost no love. i personally don't play h&h at all (i haet fantasy settings), and strife... eh, good idea, mediocre implementation. that is, there can be bugs, and many of them. can you provide a screenshot, and map/position, please (mypos will tell you it), so i can check the texture?

 

I know u r not much interested in these games, but since u r okay with accepting bug reports so I have some. These were discovered through basic 2 min testing so maybe expect more bugs that I did not report.

 

Bugs:

- Cheats (as in typing ingame cheats like IDDQD, IDKFA etc.) don't seem to work in non-doom games.

- In Heretic, the wood staff (slot 1 weapon) spawns a little bit of light even in untomed mode.

- In Hexen, mage's starting weapon seems to do much more damage. It is a ripper type weapon, so maybe there is something there.

- Mage's 2nd weapon (frost shards) has a tendency to crash k8vavoom.

 

Share this post


Link to post
10 minutes ago, ReaperAA said:

but since u r okay with accepting bug reports so I have some

thank you!

 

10 minutes ago, ReaperAA said:

Cheats (as in typing ingame cheats like IDDQD, IDKFA etc.) don't seem to work in non-doom games.

yeah, i never bothered to implement them outside of doom. tbh, i don't even remember them for h/h. ;-)

 

11 minutes ago, ReaperAA said:

In Hexen, mage's starting weapon seems to do much more damage. It is a ripper type weapon, so maybe there is something there.

yeah, i recently changed ripping code to make some mods work, and that could break it. i'll take a look. thank you!

 

11 minutes ago, ReaperAA said:

Mage's 2nd weapon (frost shards) has a tendency to crash k8vavoom.

this is BAD. thank you alot, i'll take a look!

 

12 minutes ago, ReaperAA said:

I know u r not much interested in these games

they still should not be broken, so any reports about those are very valuable! i can't promise to fix them quickly, but eventually i will. so, report them, report often, report much! ;-) i am collecting those reports in my internal bug log, so they won't be lost.

Share this post


Link to post

I'm not getting any BFG tracers in the latest version, with both perk's smooth weapons and vanilla.

Share this post


Link to post

Well I discovered some more bugs.

 

in Heretic:

- The wood barrels are pushable in k8vavoom. These are not meant to be pushable. The option "pushable barrels" has no effect on them.

- The wooden staff when tomed/powered does not spawn the blue glow/puff when it hits.

- The gaunlets of necromancer start as tomed/powered even when a tome is not used. However when a tome of power is used and then allowed to deactivated, the gaunlets become untomed.

 

In Hexen:

- Wraithwerge (cleric's 4th weapon) does not do any damage (atleast the spawned ghosts don't seem to do any).

- Bloodscourge (mage's 4th weapon) has a tendency to crash k8vavoom.

Share this post


Link to post

thanks to you both! unfortunately, at the moment i am not able to look into your issues, because... eh... i must help Shelly in her fight!

Share this post


Link to post
Just now, ketmar said:

thanks to you both! unfortunately, at the moment i am not able to look into your issues, because... eh... i must help Shelly in her fight!

 

Playing Ion Maiden Fury right ;)

Share this post


Link to post

yeah. just started it, and so far the game is GREAT. that is what i call "old-school classic FPS"! ;-)

Share this post


Link to post
On 8/27/2019 at 9:01 AM, Khorus said:

I'm not getting any BFG tracers in the latest version, with both perk's smooth weapons and vanilla.

yay, it was TOTALLY broken for a long time! like, absolutely broken. thanks! fixed.

 

On 8/27/2019 at 1:20 PM, ReaperAA said:

The wood barrels are pushable in k8vavoom. These are not meant to be pushable. The option "pushable barrels" has no effect on them.

yeah, i made them pushable before i introduced that option, and forgot to fix it. fixed. thanks!

 

other bugs are still in queue.

 

p.s.: also, if you got a crash, gimme conlog.log file if you can, plz -- it should have a stack trace, which helps alot.

Share this post


Link to post

lazy build from a lazy developer. with a lazy tag.

this build is mostly about paying various technical debts, so not much user-visible changes here. also, several internal things vere changed/rewritten, and i may break something unexpected on my way (as usual). sorry in advance.

 

windows users can run this in cmd.exe: "k8vavoom.exe --help 2>optlist.txt" to get list of available CLI arguments with some brief explanations.

 

 

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

* inventory management (ACS/decorate) code cleanups (and some bugfixes)
* added limited support for maps with multiple polyobjects in one subsector (both render and clipping still may glitch with such maps, but at least they won't crash the engine)
* improved UDMF diagnostics (most errors and warnings will report the offending line)
* UDMF parser is more tolerant to invalid data if it is not used anywhere
* some ACS<->VC introp fixes, too long to explain here ;-)
* added some color coding to Health Bar
* it is now possible to load custom wads with "-iwad" again (thanks, SovietPony!)
* impletented desaturated, blended, and tinted color translations
* optimised decorate codegen (don't create unnecessary anonymous wrappers; don't generate code for duplicate wrappers)
* action methods can be virtual now (doesn't matter for the current code, but may be useful for some TCs)
* (semi)implemented "OldRadiusDmg" decorate flag
* tried to implement "FixMapthingPos" decorate property (absolutely not tested, not even once)
* rewritten decorate expression parser (less copypasta, and slightly more flexible now)
* added support for prefix/postfix increment and decrement, and `op=` in decorate anonymous action functions
* added support for Quake PAK files, for no apparent reason (actually, reworked VFS code to make implementing additional archive formats easier)
* checkpoints now should be loaded with correct skill setting
* improved support for custom rail particle colors (thanks, id0!)
* added "-help" (or "--help") cli arg handling (not everything is there yet, but i am working on it)
* fixed `A_BFGSpray()` (thanks, Khorus!)
* heretic and hexen barrels now respect "pushable barrels" server flag (thanks, ReaperAA!)
* fixed animdef loader bug, so fraggle's miniwad.wad works now
* autocompletion now works for complex command lines (those with ';' inside)
* it is now possible to edit input line for chat and console inputs
* added "con_clear_input_on_open" boolean cvar; set to "0" to avoid clearing input line when console opens
* "use" keybind won't crash the engine if there's no running game (thanks, id0!)
* mod keybindings won't interfere with main/other mods keybindings anymore
* it is now possible to scale crosshair (bigger crosshairs may help people with motion sickness)
* "wait" command now waits for roughly one tick; it also accepts argument, which is number of tics (positive), or milliseconds (negative)
 

Edited by ketmar

Share this post


Link to post
On 9/1/2019 at 11:12 AM, ketmar said:

p.s.: also, if you got a crash, gimme conlog.log file if you can, plz -- it should have a stack trace, which helps alot.

 

Oh man I forgot about it. When I will have free time, I will download the new build u released now and see if game crashes now or not (and provide conlog file if it does).

Share this post


Link to post

Hey guys sorry for being inactive the last couple weeks. Been busy with work and doing more remastering of some old maps. Right now i'm remastering 'Dissolution' and 'Project Slipgate'. Both will be compatible with both K8Vavoom and GZDoom.

 

Thanks again Ketmar for K8Vavoom updates and bugfixes. Send me a message if you have any questions or suggestions on any mods I upload.

Share this post


Link to post

Nice!

It seems to run fine in Windows 10, though I still get that "failed to create OpenAL context" dialog on first run.

I ok it and k8vavoom runs normally.

I'm not sure what causes it, but there must be a debug msg line in code somewhere about it heh.

 

Thanks ketmar! ;)

You Rock!

 

 

Share this post


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

still get that "failed to create OpenAL context" dialog on first run.

I ok it and k8vavoom runs normally.

which is absolutely impossible, tbh. because any OpenAL initialisation error is `Sys_Error()`, which unconditionally bobms out after the message. or you mean 2nd and following runs are ok, and i am dumb? ;-)

 

anyway, i don't have the slightest idea. this message is shown when `alcCreateContext()` failed. which is very basic operation (and i am not even sure that i can get error message at this stage, because errors are kept in the current context). that's why it doesn't say anything more. i.e. this is the thing that basically cannot fail. i am puzzled.

 

i.e. it literally only sets number of sound sources, and that's all. it should either fail each time, or work each time. there's absolutely nothing which can fail *once*.

 

anyway, if it works in 2nd run, let's consider running k8vavoom at least two times a solution. ;-) sadly, this is the best "solution" i can offer for now.

Share this post


Link to post

Yeah man it only did it on first run, it's a small message/dialog box that displays the message.

But only on first run, every time I run k8 afterwards, there's no dialog, and there's no issue.. eg, If I was to run k8 now, I won't see the dialog.

So yeah the following runs are ok.

 

I'm stump too as to why it showed it at all also.. 

I'm wondering what it would take to reproduce it? 

..it only did this after I get a new clean version of k8vavoom..

hmm watch it turn out to be my anti-virus..

I'll test it out on another system and o/s and get back to you!

 

 

Edited by Mr.Rocket

Share this post


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