k8vavoom: no good thing ever dies!

[ketmar]

internally, it is client/server (kinda) even in single mode. that's why it always says "spawning server" when you're entering a new map.

 

but what makes it networked server is magical "+maxplayers n" command. without it, the game will start in "no networking single player mode". "map" command will start network mechanics if maxplayers is set to something.

 

it is slightly more complicated, as "maxplayers" invokes "listen <mode>" command, but you'd better don't experiment with "listen" directly. ;-)

[Mr.Rocket]

I see, ok!

Thank you!

[ketmar]

btw, this should work both with the original Vavoom, and with k8vavoom. so you can support both of them for the price of one. ;-)

[Mr.Rocket]

Yeah I guess I could!

Are there any new command line args besides the removal of software and d3d?

Well I guess I should say, are there any new useful CLA's introduced in k8vavoom that weren't in Vavoom?

 

Thanks

[ketmar]

there are alot, but most of them are for debugging. ;-)

 

you may be interested in "-k8runmap", tho: this command tries to automatically run first pwad map, if there is any. most of the time you can simply do: "k8vavoom coolmaps.wad -k8runmap", and it will drop you directly into the action.

 

you can disable title map with "-notitlemap".

 

"-bdw" will turn on built-in weapons mod.

"-nogore" will turn off built-in blood-and-gore mod.

"-nakedbase" will skip all autoloads (althrough i didn't properly described how to create autoloads; k8vavoom has unique and very powerful configurable autoload system, but nobody knows about it).

 

in single-player mode you can put console cheat codes after "+map mapname" or "-k8runmap", and they will work. i.e.

k8vavoom +map map01 +notarget

will work as expected. note the oridering -- "+map" must come first.

 

if you have both Doom and Doom2 iwads, and want to play with pwad, k8vavoom will try to guess which iwad to load (and most of the time it guesses right).

 

you can omit "-file" if you'll put your pwads before any arguments starting with "-" or "+".

 

you can load disk directory as "virtual pk3" with "-file dirname" (here, "-file" is not optional).

 

there are prolly more of them, but i can't remember anything more for now.

 

p.s.: k8vavoom is able to run pk3s from inside zips (i.e. you don't have to unpack zip file that contains pk3 file to play with that pk3). the engine also can run zips where wad/pk3 were put into subdirectory (most of the time).

 

p.p.s.: oh, there are more. you can use "-skipsounds", "-skipsprites", and "-skipdehacked" if you don't like sound/sprite/deh replacement from some pwad. this way, for example, you can play freedoom with doom sprites and sounds, but freedoom textures -- just use "k8vavoom -skipsprites -skipsounds -file freedoom.wad".

Edited July 14, 2019 by ketmar

[Mr.Rocket]

Ok, Noted, those extras are probably enough for what I'm doing anyway.

Awesome, Thanks! :)

 

Oh btw, are any of these documented yet? I could just look them up in the git repo if they are.

Thanks again!

Edited July 14, 2019 by Mr.Rocket

[ketmar]

1 hour ago, Mr.Rocket said:

are any of these documented yet?

sadly, no. they're scattered across the source code, and i never bothered to write any documentation. sorry.

 

this perfectly fits to a wiki, but alas: k8vavoom has no dedicated site, and no wiki. maybe one day some volunteer will setup one, but until than k8vavoom will prolly stay a hidden and obscure gem. ;-)

[Gunrock]

On 7/11/2019 at 9:08 PM, ketmar said:

@Gunrock here, Graf pointed me at the bug (and as usual, this is The Bug That Cannot Happen). until i'll fix it, i added mapfix workarounds for both SS:R versions (actually did what Graf said, moved mapspot around a little ;-), so both versions will work (and will continue to work when i'll fix the bug -- the fix will break v1.0 without mapfix ;-).

 

now, this is very nasty bug that could hid for ages, and make some maps works "slightly wrong". thank you for reporting it, in the end it turned out to be a huge thing, not a small one! ;-)

Thank you again ketmar and Graf for looking into this!!!

Just some little quick news. I'm almost done remastering Dark Wispers. I added two new maps to make it a little bit longer. It should be done in a few weeks time. I'm aiming for both K8Vavoom and GZDoom compatibility for the maps. Like I said before, I'm going through some of my old projects and remastering them for K8Vavoom (best source port in my opinion;)

[Mr.Rocket]

hmm, it seems as that the +deathmatch 0 and nomonsters 0 aren't work as expected, not sure why yet.

eg: 

+maxplayers 8
+deathmatch 0
+nomonsters 0
+map map01

will load up map01 in DM mode without monsters. Even if I remove the commands and just have:

+maxplayers 8
+map map01

will again load up map01 in DM mode without monsters.

 

Or if I setup a test.cfg as a response file:

-deathmatch 0
-nomonsters 0

and have a batch file like so:

k8vavoom +maxplayers 8 +map map01 @test.cfg

will again load up map01 in deathmatch mode..

 

So I'm not sure what's causing this yet, it works as expected in old Vavoom, though.

Let me know what you think, I'm a bit stumped..

 

Thanks

 

 

EDIT:

This is interesting.. if I do:

k8vavoom.exe deathmatch 0 maxplayers 8 +map map01 

it will load up map01 in a Coop net game as we would expect it to, however if we want to go back to a deathmatch game we do:

 k8vavoom.exe +deathmatch 2 maxplayers 8 +map map01

And we get map01 in deathmatch 2 netgame.

 

So yeah, removing the + from both deathmatch and maxplayers, gives us Coop, then adding a + to deathmatch 1 or 2 gets our DM game back..

Is that strange or what? something fishy about that + and or when it needs to be there with deathmatch and maxplayers, as you will see from my tests.

 

EDIT again:

 

Ah no, it's not picking up on maxplayers, sense it's defaulting it to 1..:(

Removing the + from deathmatch does change it from dm to coop though..but something is still fishy..

 

Ok now let me know what you think.

 

Thanks

 

Edited July 15, 2019 by Mr.Rocket

[ketmar]

@Mr.Rocket yep, "+deathmatch 0" is coop (and this is default). "+deathmatch 1" is "classic deathmathch", and "+deathmatch 2" is "alternative deathmatch" aka "altdeath".

 

in response file, you should use exactly the same syntax as in normal invocation. it is substituted "as is" exactly where "@file" is in command line.

 

also, order of commands matter. "+maxplayers" must be the first. then "+deathmatch", then "+map".

 

"+" is a delimiter, it denotes the start of a console command. everything up to the next "+" or "-" will be passed to the console as command (that one that has "+"), and its arguments. this is literally what arguments parser does, no magic here. ;-)

 

the same is true for "-".

 

the difference between "+" and "-" is simple: "-" arguments are processed by C++ code (or ignored), and everything with "+" is passed to the console for executing. so you cannot freely interchange "+" and "-", they're doing completely different things.

 

i.e. everything starting with "-" and up to the next "-" or "+" is some option for C++ code. and everything starting with "+" up to the next "+" or "-" is console command that will be executed after engine will initialise and load all the game data.

[ketmar]

4 hours ago, Gunrock said:

I'm almost done remastering Dark Wispers.

that's great!

 

4 hours ago, Gunrock said:

I'm going through some of my old projects and remastering them for K8Vavoom (best source port in my opinion;)

thanks. i too think that k8vavoom is the best sourceport evar. we're so close to world domination! ;-)

 

p.s.: i am planning to push a new release soon, if you can wait a little and test new remaster with it, it would be great. i changed some internals and corner cases handling, and it may need some attention. sure, i can fix it all later with maphacks, as with SS:R, but... ;-) some special attention should be paid to things placed on 3d floors, especially on grate-like 3d floors, and in small holes. i had to introduce some hacks for some other maps, and while it should make k8vavoom more predictable and in line with other sourceports (gzdoom ;-), it may require some attention.

Edited July 15, 2019 by ketmar

[Mr.Rocket]

@ketmar, I've tried different orders etc. it doesn't seem to matter, although if I leave deathmatch alone without a + or -, then the command works.

No matter if +maxplayers 4 is in front or back..

eg:

+maxplayers 2 +deathmatch 2   ~  deathmatch works.

+maxplayers 2 +deathmatch 0   ~  it's stuck in deathmatch 2, it didn't change to Coop..

 

But if I do:

+maxplayers 2 deathmatch 0  ~ now it changes to Coop, without the + .

 

This is what I'm saying. :)

 

But now that I have it changing from DM to Coop and back in a slightly obscure way, maxplayers seems to stop functioning, and will show maxplayers 1 in the console instead of 2, as shown in the example above, which I'd imagine is only just a default setting if none is given, as it's not picking up the command.

 

It's pretty straight forward how the commands (should) work, yes. And most all of them do as they should, aside from the ones I'm pointing out above. :\

 

 

 

Edited July 15, 2019 by Mr.Rocket

[ketmar]

@Mr.Rocket ah, i see. that's because i fucked up handling of CLI arguments for network commands. ;-) thank you for noticing, it should be fixed in the next public build. the thing is that i accidentally marked "deathmatch" as "process out of order, before everything else" variable, and it broke CLI. that is, the engine first sets the dm/coop mode, and then goes on with initialisation, resetting that mode to some default. lol i'm dumb.

 

p.s.: btw, there is "+noexit 1" cvar to disable exiting in deathmatch (and coop, lol). i introduced it so my stupid bots won't accidentally press an exit switch. ;-)

[Mr.Rocket]

Ah ok good!

Sweet, I'm glad you found it!

I have this going on: 

if (hostindex == myindex)
	{
		// Parameters for host


		fprintf(af, "+MaxPlayers 32\n");
		fprintf(af, "+Deathmatch %d\n", dc_GetMultiSettingInt(dllGUID, "general", "type"));
  		fprintf(af, "+Skill %d\n", dc_GetMultiSettingInt(dllGUID, "general", "skill"));
		fprintf(af, "+NoMonsters %d\n", dc_GetMultiSettingInt(dllGUID, "general", "monsters") == 0);
		fprintf(af, "+TimeLimit %d\n", dc_GetMultiSettingInt(dllGUID, "general", "timelimit"));
  
  //etc etc

You get the idea. 

Anyway, no worries.

I can't wait to try out the update! :)

 

Thanks

 

[ketmar]

one note: vavoom (and k8vavoom) only supports up to 8 players. and most maps has only 4 dm/coop starts anyway. it is harmless to pass "32", it will be clamped to 8 anyway, but there is really not much sense to pass more than "4". that is, 4 is "safe default".

[Mr.Rocket]

Heh yeah I know 8's max, I just threw it in there to see what the console might say about. ;)

Here's what it needs to look like:

fprintf(af, "+MaxPlayers %d\n", dc_GetMultiSettingInt(dllGUID, "general", "maxplayers"));

 

The ui configuration in the dll will actually say this:

		maxplayers
		{
			caption = "Max Players";
			type = "number";
			default = 0;
			min = 1;
			max = 8;
			step = 1;
		}

I can set the max to 4 if you want?

No worries!

Quote

p.s.: btw, there is "+noexit 1" cvar to disable exiting in deathmatch (and coop, lol). i introduced it so my stupid bots won't accidentally press an exit switch. ;-)

Oh ok! nice I'll make sure to get the new cvars in there too! ~ silly bots.. ;)

 

Edited July 15, 2019 by Mr.Rocket

[ketmar]

49 minutes ago, Mr.Rocket said:

I can set the max to 4 if you want?

8 is ok for max, the engine is capable of that. but many maps has only 4 starting points, and the engine will exit with error if it won't find a spawn point for a player. that is, with "+maxplayers 8" and only 4 spawn points, 4 players can play just fine, but if 5th player will connect, it is a game of luck now: with coop it will (prolly) immediately fail, as there is no coop starting point for this player. and with dm, it may fail later, if all dm spawn points will be occupied.

 

i think set it to 4 by default is ok, leaving 8 as maximum for those people who know what threy're doing. if it is possible to show some warning/tooltip with explanation of >4 max players dangers, it will be great.

 

 

p.s.: it is fun to talk about all that and know that networking code in k8vavoom is absolutely broken now. like, absolutely, totally broken, to the extent of disappearing items, ghost voodoo players, and so on. ;-)

[Mr.Rocket]

Ok I'll just set it to 8. I can always place a caption saying that more than 4 may cause stability issues, but capped at 8.

 

Quote

p.s.: it is fun to talk about all that and know that networking code in k8vavoom is absolutely broken now. like, absolutely, totally broken, to the extent of disappearing items, ghost voodoo players, and so on. ;-)

 

The plan was to at least make it so k8vavoom could be played in Doom Connector, even if multiplayer was somewhat broken, until some network bugs were fixed, then multiplayer could be utilized hopefully later, but I didn't know it was that bad. I mean I suspected it might have some problems, but wow!

 Well, stay optimistic I say! at least we know now that the network code needs some work, hah! :\

 

 

[ketmar]

5 minutes ago, Mr.Rocket said:

but I didn't know it was that bad. I mean I suspected it might have some problems, but wow!

it is my fault: i recently tried to fix some non-fatal bugs in network code, and instead completely borked it. it worked in some previous releases (albeit was unstable). i will eventually make it work again, of course, so your work is not pointless. i have some other urgent things to do right now, but fixing network code (at least make it playable again) is relatively high in my internal TODO list.

[ketmar]

and some good news: i added very simple GZDoom MODELDEF parser. it is still better to provide separate k8vavoom model definition files (if you will ever figure out how to do it, lol), but if you're too lazy to read k8vavoom source code to find out how to define models, it is now possible to use basic MODELDEF file.

 

note that native k8vavoom model definitions has higher precedence, so you can include both definitions in your pk3, and they won't conflict.

 

please, note that MODELDEF support is currently incomplete (mostly due to my laziness, not due to k8vavoom limitations), and some things may not work as you expect. k8vavoom will tell you about most unsupported features.

 

please, note that k8vavoom supports only md2 and md3 models, and you currently cannot select md3 mesh (k8vavoom will use the whole model). this is, again, not a k8vavoom limitation, but lazy converter coding.

 

 

p.s.: with lastest fixes, and MODELDEF support, you will be able to play MMDCXIV - Journey into 27 Century with k8vavoom! it is quite slow, though, but you can trade rendering distance for speed with "gl_maxdist". yet even with big maxdist (8192) and average at 20-35 FPS it is playable. not quite as smooth as you may like, but playable.

Edited July 15, 2019 by ketmar

[Gunrock]

13 hours ago, ketmar said:

and some good news: i added very simple GZDoom MODELDEF parser. it is still better to provide separate k8vavoom model definition files (if you will ever figure out how to do it, lol), but if you're too lazy to read k8vavoom source code to find out how to define models, it is now possible to use basic MODELDEF file.

 

note that native k8vavoom model definitions has higher precedence, so you can include both definitions in your pk3, and they won't conflict.

 

please, note that MODELDEF support is currently incomplete (mostly due to my laziness, not due to k8vavoom limitations), and some things may not work as you expect. k8vavoom will tell you about most unsupported features.

 

please, note that k8vavoom supports only md2 and md3 models, and you currently cannot select md3 mesh (k8vavoom will use the whole model). this is, again, not a k8vavoom limitation, but lazy converter coding.

 

 

p.s.: with lastest fixes, and MODELDEF support, you will be able to play MMDCXIV - Journey into 27 Century with k8vavoom! it is quite slow, though, but you can trade rendering distance for speed with "gl_maxdist". yet even with big maxdist (8192) and average at 20-35 FPS it is playable. not quite as smooth as you may like, but playable.

Thats great news!!! I really want QStuff Ultra V1.2

to work in K8Vavoom;)

 

[ketmar]

6 hours ago, Gunrock said:

Thats great news!!! I really want QStuff Ultra V1.2

to work in K8Vavoom;)

it mostly loads, but sadly: some pcx skin files are in format not supported by k8vavoom. some models are offsetted wrong (this is prolly something i parsed wrong). and the thing itself has quite a number of doubly-defined models, which seems to be all merged in GZDoom, but it doesn't work this way in k8vavoom (k8vavoom can only replace already defined model). but otherwise it runs, renders some pickups and some monsters high up in ceiling, and so on. sooner or later it will run, i think. ;-)

 

p.s.: vertical offsets seems to be fixed now -- k8vavoom applied offsets and scaling in different order.

 

teaser picture (yeah, hand weapon models aren't working yet, but pickup models do):

Spoiler

 

Edited July 16, 2019 by ketmar

[Mr.Rocket]

Looks good, z-heights maybe about 4ish units too low but looking good!

 

Oh btw, I feel Like I'm spamming this link now.. but sense you're working with Qstuff Ultra, here's a Quake1 style map I made a little while back, using QStuff Ultra, it is again what helped inspire me to make the little map: 

Made for Gzdoom under Doom2.wad map01.. will work on other ports that support the data types of course, so I figured it might be a good time to plug it again. ;)

The map will run by its self, without Qstuff, but the normal Doom2 item placement won't so it really needs Ultra with it.

 

Cheers

Edited July 16, 2019 by Mr.Rocket

[ketmar]

40 minutes ago, Mr.Rocket said:

z-heights maybe about 4ish units too low

yeah. i don't know yet if this is my model loader wrongly detected model origin, or this is a leftover from sprite height hack issue. but i will eventually find it out.

 

i implemented support for missing PCX types, so all PCX skins seems to load correctly (i hope) now. there is one bmp skin too -- looks like i have to implement that format (sighs). otherwise it is playable, monsters are animated, and so on.

 

and you're welcome to post links to your work, of course!

 

p.s.: also, as most models are properly closed, they're casting shadows in stenciled lighting mode. sadly, some models has degenerate triangles, so shadows for those models are turned off.

Edited July 16, 2019 by ketmar

[Mr.Rocket]

30 minutes ago, ketmar said:

i implemented support for missing PCX types, so all PCX skins seems to loads now. there is one bmp skin too -- looks like i have to implement that format (sighs). otherwise it is playable, monsters are animated, and so on.

 

Nice!

I can't wait to get ahold of the new version, I always like to see how much things have changed and stuff getting fixed.

It doesn't surprise me about the bmp, bmp's are pretty much an old school standard. I'm not sure what all formats k8vavoom supports yet. I'd imagine tga and png are or will be a priority soon if support isn't already implemented. 

 

Quote

and you're welcome to post links to your work, of course!

Thanks, it is to only help, if at all needed. :)

 

[ketmar]

17 minutes ago, Mr.Rocket said:

I'm not sure what all formats k8vavoom supports yet.

it supports most commonly used formats -- png, tga (all types, including paletted and RLE compressed), jpeg, png, and (currently) 8/24/32 bpp pcx. i never encountered bmp textures until now, so i didn't bothered implementing bmp. sure, i have bmp loading code in one of my other libraries, so i'll port that code to k8vavoom. if i'll ever find .dds texture, i'll implement it too. ;-)

 

 

>I always like to see how much things have changed and stuff getting fixed.

changelog for the upcoming build is quite big. ;-)

[Mr.Rocket]

Quote

if i'll ever find .dds texture, i'll implement it too. ;-)

I've made a bunch of them for a couple Doom3 mods, if you need I'll send a few over.

They started out as tga and then ran a batch conversion to dds, they are mainly for better compression and or color depth on lower resolutions.

If I remember right the alpha translucency won't work as well with dds, i'm pretty sure only transparent solid alphas worked as expected.

 

[ketmar]

3 minutes ago, Mr.Rocket said:

I've made a bunch of them for a couple Doom3 mods, if you need I'll send a few over.

i mean "if i'll see such texture in some mod". i have working DDS loading code too, but too lazy to port it to k8vavoom until it is really necessary. actually, to implement proper support for DDS, the code has to check if OpenGL is capable of compressed textures, and pass DDS to OpenGL driver as-is, instead of decompressing it, and passing it as raw pixels -- that will give the best quality possible. yet this is too much work for nothing (at least for now), and i have alot of other things to code. so i prefer to not implement DDS until it is strictly necessary. ;-)

[Mr.Rocket]

Ok np, just let me know and I'll send a couple over..

If I recall, the reason why I had to convert a lot of the textures I made to dds was mainly because they were larger textures to begin with detail in mind, most of them being bumpmap/normals as they were a larger file size, converting them to dds was so they would load quicker on lower spec systems/video cards, in lower res, otherwise the render "type" wouldn't load a specified image size or file size, and the detail would never be "somewhat" seen on the lower end system. ~ it's kind of hard to explain., they help lower end system have a bit of quality without choking I suppose..

In the process of compressing, smooth alpha translucency was lost, and only solid transparent would work with them, if an alpha was needed for the texture anyway.. 

 

Edited July 16, 2019 by Mr.Rocket

[ketmar]

@Gunrock your wish is almost granted! sadly, some QU model defs are attaching several models to one sprite frame, k8vavoom doesn't support this (yet, maybe ;-). specifically, Shambler and Armagon. and view weapons models aren't working yet. but otherwise it is playable. i played several maps with it, encountered various soldiers, dogs, hell knights, ogres -- and it seems to work.

 

p.s.: lol, the missing skin is not bmp, it is just a bug in model definition: wrong extension. i added more aggressive searching for skin files, and now it loads ok.

Edited July 16, 2019 by ketmar