k8vavoom: no good thing ever dies!

[ketmar]

(sighs)

12 hours ago, ketmar said:

what i mean is that "Ax+By+Cz+D=0" often used regardless of the sign of "D", so it is a guesswork if the given document is using it "right", or just as a "common way to talk about planes".

 

On 6/10/2019 at 10:15 AM, ketmar said:

escpecially considering that Quake does this the opposite way too (and people may apply "those are Carmack engines, so it should be like Quake" logic).

 

and here, "the opposite way" means "Ax+By+Cz=D", but it is still often incorrecly referred to as "Ax+By+Cz+D=0".

 

and the whole uncertainity can be solved by adding a single paragraph of commentary to the specs. tbh, at this point i am not even sure what we are aguing about.

[Gunrock]

Just uploaded Gothic Dreams: Definitive Edition

 

It works with ZDoom, GZDoom, K8Vavoom, Skulltag and Zandronum.

However, bots are sometimes dumb as shit and fall all over the place. Best to play human on human ;)

[Graf Zahl]

44 minutes ago, ketmar said:

and the whole uncertainity can be solved by adding a single paragraph of commentary to the specs. tbh, at this point i am not even sure what we are aguing about. 

 

You are merely arguing that the spec may be incorrectly documented, assuming that the given formula is correct, there's nothing to argue about.

[ketmar]

28 minutes ago, Graf Zahl said:

You are merely arguing that the spec may be incorrectly documented

where? O_O

 

all i am saying is the specs are little unclear, and it is easy to make the specs clear by adding a simple example. that's all. it is not about changing the specs, or about the specs being incorrect; i am just asking to add an example floor plane, which will remove all and any uncertainity for a reader.

[ketmar]

40 minutes ago, Gunrock said:

However, bots are sometimes dumb as shit and fall all over the place

at least k8vavoom bots are absolute trash. they're waiting for `traceBox()` API, which is not ready yet (the tracer is ready, but i want to use it with movement code, and i still have to find the right API design for that; i just don't want to add some code only to add a slightly changed "almost-a-duplicate" of that code later). so the best use for k8vavoom bots is to spawn them and laugh at their dumb attempts to play the game. ;-)

[ketmar]

it's build time!

 

please, note that i renamed almost everything from "vavoom" to "k8vavoom", to avoid conflicts with the original project. GNU/Linux users: you can rename "~/.vavoom" to "~/.k8vavoom" to avoid loosing your config settings. also note that shared data will be installed in "shared/k8vavoom", so if you have some autoloads in shared data, move them to the new location.

 

* do not play "use fail" sound if anything was used, or if nothing is reachable
* it is now possible to toggle bilinear filtering for brightmaps
* added support for "$musicalias" in SNDINFO
* fixed ancient bug with non-updtating doors in demos/netgames
* fixed bug with fog rendering in advrender
* fixed some bugs in network/demo code; it is still not as good as i want it to be (and you still cannot reliably record a multilevel demo), but it should not produce broken packets anymore (the infamous "channel not open" error)
* also, it is now possible to record a demo longer than 5 minutes (actually, network timeout detection was completely broken)
* fixed (i hope ;-) bug with "flickering lines" on automap (k8vavoom does fine-grained "seen" marking, i.e. it marks segs, not linedefs; and there was a subtle bug)
* doors/lifts with semi-transparent top/bottom textures are better rendered now (mappers shouldn't do that, but...)
* fixed rendering of translucent walls (it is more like GZDoom now, and looks the same in both rendering modes)
* fixed typo in surface creation code -- Silent Steel windows doesn't have missing triangles anymore
* Boom generic door delay is specified in octics, but k8vavoom was using tics
* it is now possible to jump out of the water in any direction, not only when moving forward
* implemented UDMF vertex slopes
* implemented UDMF floor/ceiling planes
* implemented UDMF "moreids"
* "nocrouch" MAPINFO option was changing falling damage flag instead (and some other options were wrong too)
* implemented some missing ACSF opcodes
* fixed DECORATE ammo checks, so some weapon mods can detect "out of ammo" for weapons with reloading again
* fixes to "Transfer Height" special rendering

[ketmar]

...and of course, i found an infinite loop bug in stair building special immediately after i uploaded the build. shit. build updated.

[-TDRR-]

20 hours ago, Gunrock said:

Just uploaded Gothic Dreams: Definitive Edition

 

It works with ZDoom, GZDoom, K8Vavoom, Skulltag and Zandronum.

However, bots are sometimes dumb as shit and fall all over the place. Best to play human on human ;)

I made these bots that are an overall improvement over both Zandro's and ZDoom's bots, they still fall off the edges and such but they can navigate a lot more of the map. I recommend you use them in Zandronum, because for some weird reason despite working 90% of the time better in ZDoom than in Zandro, these maps are indeed navigated better when played on Zandronum. I might make some waypoints for these maps someday.

 

By the way, the maps are absolutely fantastic! I love the lighting, and the look of all of the maps, but my favorite one is MAP03: Melted Steel. Great work!

 

EDIT: Ah, forgot to mention this: Sadly they don't work in K8Vavoom, It would be pretty cool if at least the Zandronum version was compatible. And maybe could help @ketmar get some more support going. But no big deal, because i'm pretty sure the new bots are going to beat mine in a head-to-head competition!

[ketmar]

14 minutes ago, -TDRR- said:

Sadly they don't work in K8Vavoom

yeah, `A_CheckLOF()` and `A_TransferPointer()` decorate code pointers are not implemented yet. will prolly do it later. sadly, "native" k8vavoom bots are still far away. right now i'm going to implement profiling subsystem, because i tired of mysterious slowdowns i cannot trace back to the code. the new public build was done because i want to work on built-in engine monitoring tools, so for some time the engine will be barely usable.

[-TDRR-]

43 minutes ago, ketmar said:

yeah, `A_CheckLOF()` and `A_TransferPointer()` decorate code pointers are not implemented yet. will prolly do it later. sadly, "native" k8vavoom bots are still far away. right now i'm going to implement profiling subsystem, because i tired of mysterious slowdowns i cannot trace back to the code. the new public build was done because i want to work on built-in engine monitoring tools, so for some time the engine will be barely usable.

Understandable. Althrough A_TransferPointer doesn't really do anything and it could easily be replaced by a remote A_ClearTarget activation, so i guess that's one less problem for now. A_CheckLOF could also be replaced with A_JumpIfTargetInLOS("statename", 8), so i'm going to see if i can whip up a new version.

 

I still am pretty excited for the native bots, hope to see some progress on them!

[ketmar]

6 minutes ago, -TDRR- said:

I still am pretty excited for the native bots, hope to see some progress on them!

thanks. after i finish with profiling tools, i'll prolly return to bot code. most of the required mechanics is already implemented in one form or another (box tracing, automatic waypointing, astar pathfinding, draft of GOAP decision system). of course, building working bots from these parts is not as easy as simply gluing it all together, but i know where i am going with all this, and i hope to have quite competetive and intelligent bots as a result. (tbh, i'm going to have The Best Doom Bots Out There, but let it be our little secret for now ;-).

[-TDRR-]

41 minutes ago, ketmar said:

thanks. after i finish with profiling tools, i'll prolly return to bot code. most of the required mechanics is already implemented in one form or another (box tracing, automatic waypointing, astar pathfinding, draft of GOAP decision system). of course, building working bots from these parts is not as easy as simply gluing it all together, but i know where i am going with all this, and i hope to have quite competetive and intelligent bots as a result. (tbh, i'm going to have The Best Doom Bots Out There, but let it be our little secret for now ;-).

I will keep it secret, but you better tell me how that automatic waypointing works!

 

I hope these bots are not too difficult to adapt to other Doom engines, because i would love to see Odamex have something like them too. Anyways, i really like how those mechanics sound and i hope they are every bit as good as they sound!

[ketmar]

51 minutes ago, -TDRR- said:

but you better tell me how that automatic waypointing works!

the idea is simple (but you won't be able to implement it in decorate, you'll need access to engine internals).

 

basically, node builder gives us a set of interconnected convex polygons (subsectors). as they're convex, and each seg can have only one partner seg, we can simply drop a waypoint near the center of each subsector, and voila -- we have a waypoint mesh. of course, there are some checks, like "can bot fit into this subsector at all?" (if it isn't, waypoint builder will try to move that waypoint a little; and if it is impossible to move it, such subsector is considered unreachable).

 

this is very similar to what Q3 does, only we have an advantage: while Quake keeps tree of solids, and Q3 code must build a tree of empty spaces from that, in Doom BSP tree actually holds empty spaces, so most of the work is already done.

 

sure, it is possible to optimise waypoints further, and pathfinder must consider doors/lifts/height changes, but the basic idea is as simple as i wrote.

 

51 minutes ago, -TDRR- said:

I hope these bots are not too difficult to adapt to other Doom engines

yeah, most of the code is Vavoom C, which is quite easy to port to C/C++. other engines will have to take `traceBox()` API, tho (but it is not hard to do too).

 

most of the problems i still have to solve siting in decision making. while i have a working GOAP implementation (the same planner as was used in F.E.A.R.), creating a set of rules for it is a hard task. i am still not sure if i'll really go with GOAP alone, or if i'll try some combination of methods.

[-TDRR-]

48 minutes ago, ketmar said:

the idea is simple (but you won't be able to implement it in decorate, you'll need access to engine internals).

 

basically, node builder gives us a set of interconnected convex polygons (subsectors). as they're convex, and each seg can have only one partner seg, we can simply drop a waypoint near the center of each subsector, and voila -- we have a waypoint mesh. of course, there are some checks, like "can bot fit into this subsector at all?" (if it isn't, waypoint builder will try to move that waypoint a little; and if it is impossible to move it, such subsector is considered unreachable).

 

this is very similar to what Q3 does, only we have an advantage: while Quake keeps tree of solids, and Q3 code must build a tree of empty spaces from that, in Doom BSP tree actually holds empty spaces, so most of the work is already done.

 

sure, it is possible to optimise waypoints further, and pathfinder must consider doors/lifts/height changes, but the basic idea is as simple as i wrote.

 

yeah, most of the code is Vavoom C, which is quite easy to port to C/C++. other engines will have to take `traceBox()` API, tho (but it is not hard to do too).

 

most of the problems i still have to solve siting in decision making. while i have a working GOAP implementation (the same planner as was used in F.E.A.R.), creating a set of rules for it is hard task. i am still not sure if i'll really go with GOAP alone, or if i'll try some combination of methods.

I'm not crazy enough to even begin to consider thinking about making a waypoint system in DECORATE! What i was thinking, is a external program that would do this and spit out a .pk3 file with the nodes on it (As in, ACS scripts that would spawn the waypoints at the desired locations, so no need of a duplicate .wad) which you can easily plug into ZDoom/Vavoom (Not Zandro unfortunately) + the TDBots .pk3 file, and voila! Easy waypoints for almost all maps! By the way, is it fine if i were to use your Vavoom code for this in a separate program? I'm pretty stupid when it comes to messing around with this sort of thing.

 

Vavoom C right? I'm going to see a DECO+ACS port could be somehow doable, that would be neat.

 

I haven't really messed at all with decision making with the TDBots but that's because i'm not sure if there's a noticeable benefit.

[ketmar]

11 minutes ago, -TDRR- said:

By the way, is it fine if i were to use your Vavoom code for this in a separate program?

it wouldn't be easy, because the code (yet to be made public ;-) expects the map loaded and preprocessed, with built nodes. that is, vccrun alone won't help.

 

but you can use k8vavoom as a standalone VC runner! Vavoom C has API to write files; it can only write files to k8vavoom config directory, so it won't be able to trash your drives with shit ;-), yet this is enough. and you can export console commands from within Vavoom C code, no need to recompile engine for this. see where it is all going? you'll be able to write a simple VC mod (or i'll write it for you), and then do something like this:

 

k8vavoom -file mywad.wad +map map01 +exportwaypoints +quit

 

bingo! we just used k8vavoom as a standalone script runner! it will still flash loading screens, but this is not a big deal, i guess.

[ketmar]

@-TDRR- you can take a look here. this is my ongoing experiments with new movement code, bit it also contains one of the early versions on waypointing system in "crumbs.vc". yes, dropping "breadcrumbs" is that easy. there is no code that calculates waypoint connection logic, tho, but it still may be of some interest for you.

 

btw, don't try to run it: it is disabled by default, and it require specially crafted pseudo-UDMF with nodes, subsectors, segs and other data exported too. and it is far from being finished too. but maybe it will give you some ideas.

 

p.s.: if you'll inspect the code closer, you may find out that it contains full-featured optimised OpenGL Doom renderer, even with frustum calculations and geometry clipping code (the very same code is used in k8vavoom itself). may be of some interest too.

[-TDRR-]

1 hour ago, ketmar said:

but you can use k8vavoom as a standalone VC runner! Vavoom C has API to write files; it can only write files to k8vavoom config directory, so it won't be able to trash your drives with shit ;-), yet this is enough. and you can export console commands from within Vavoom C code, no need to recompile engine for this. see where it is all going? you'll be able to write a simple VC mod (or i'll write it for you), and then do something like this:

 

k8vavoom -file mywad.wad +map map01 +exportwaypoints +quit

 

bingo! we just used k8vavoom as a standalone script runner! it will still flash loading screens, but this is not a big deal, i guess.

That's very neat! If you can write the mod yourself that would be much better and i imagine more efficient, you work with it a lot after all. But i guess i could write it if you give me enough documentation. (Just don't try to read the resulting code :D ) It would also be great if there also was a +gothroughallmaps command to quickly export all maps in a wad, which would be nice for a deathmatch compilation of maps.

 

It's perfectly fine if it shows loading screens, i mean, it's something to stare at while all maps are getting processed. Even if it's instant we get some nice strobing lights!

 

1 hour ago, ketmar said:

@-TDRR- you can take a look here. this is my ongoing experiments with new movement code, bit it also contains one of the early versions on waypointing system in "crumbs.vc". yes, dropping "breadcrumbs" is that easy. there is no code that calculates waypoint connection logic, tho, but it still may be of some interest for you.

 

btw, don't try to run it: it is disabled by default, and it require specially crafted pseudo-UDMF with nodes, subsectors, segs and other data exported too. and it is far from being finished too. but maybe it will give you some ideas.

 

p.s.: if you'll inspect the code closer, you may find out that it contains full-featured optimised OpenGL Doom renderer, even with frustum calculations and geometry clipping code (the very same code is used in k8vavoom itself). may be of some interest too.

This is really useful, thanks for sharing. I really needed a breadcrumbs system for the more complex maps, but couldn't figure out where to start, so this comes in very handy.

 

The rendering code might not be as useful (In fact i think it's almost completely useless because DECORATE just isn't capable of making a virtual renderer, at least not without extreme slowdown) but i might find something that could sort out some of the issues the bots have.

[ketmar]

48 minutes ago, -TDRR- said:

But i guess i could write it if you give me enough documentation.

to do that, i need somebody else to give that documentation to me. ;-) k8vavoom really needs to be documented (it is SO powerful... and i doubt that there are even ten people knows what can be done with vavoom engine, alas). but if i start writing documentation, it will take monthes (if i'll be lucky; more like years). sigh.

 

actually, it is possible to export "special UDMF" from k8vavoom itself (with "DebugExportLevel" console command), and use VC prototype i linked to load those exported files, and experiment with them.

 

48 minutes ago, -TDRR- said:

t would also be great if there also was a +gothroughallmaps command to quickly export all maps in a wad,

this can be possible with a little... cheatery. ;-) VC code can stuff commands to console, and it can get list of all maps, so it can just feed console with "map mapname ; exportwaypoints mapname ; map mapname2; ... ; quit" -- and voila, you're there. you can do alot of map processing from within k8vavoom scripts -- and you have access to almost all map data structures. i'll try to write an example. just ping me later (i hope to finish the first draft of profiling code in two or three weeks, and we'll be able to look at waypointing task after that).

 

48 minutes ago, -TDRR- said:

The rendering code might not be as useful

yeah, it is not useful for waypointing, yet it may be just interesting read by itself. if you ever wonder how modern engines does rendering, you can read it to get the idea. it is mostly cleaned up of all complex stuff, being a "barebone" renderer. yet it does BSP traversal, frustum cliping, geometry cliping -- almost everything any modern engine does to render a doom map.

[-TDRR-]

11 hours ago, ketmar said:

to do that, i need somebody else to give that documentation to me. ;-) k8vavoom really needs to be documented (it is SO powerful... and i doubt that there are even ten people knows what can be done with vavoom engine, alas). but if i start writing documentation, it will take monthes (if i'll be lucky; more like years). sigh.

Maybe i will poke around with Vavoom C sometime and document whatever i figure out, but not right now because i'm already doing a balancing act with quite a few projects at hand. When i get some more time, you can be sure i will do the basics in a week or so.

 

11 hours ago, ketmar said:

this can be possible with a little... cheatery. ;-) VC code can stuff commands to console, and it can get list of all maps, so it can just feed console with "map mapname ; exportwaypoints mapname ; map mapname2; ... ; quit" -- and voila, you're there. you can do alot of map processing from within k8vavoom scripts -- and you have access to almost all map data structures. i'll try to write an example. just ping me later (i hope to finish the first draft of profiling code in two or three weeks, and we'll be able to look at waypointing task after that).

Alright, will remind you in a month. I even set up a remindme bot so it reminds me to remind you about this!

Really nice it can do that! That's pretty useful and i can imagine a good amount of things being doable with the ability to access any map, by name.

 

11 hours ago, ketmar said:

yeah, it is not useful for waypointing, yet it may be just interesting read by itself. if you ever wonder how modern engines does rendering, you can read it to get the idea. it is mostly cleaned up of all complex stuff, being a "barebone" renderer. yet it does BSP traversal, frustum cliping, geometry cliping -- almost everything any modern engine does to render a doom map.

I always wanted to see how the BSP traversal and clipping worked, will give it a read and, who knows, maybe i will get an idea or two.

[Beezle]

Is there an option to make the weapons more visible? They seem to be hidden a little bit under the screen, but then again it might be because I set the game at a weird resolution, 1152 x 864. It looks like you fixed the crashing issue, in the last build I had to set the -nomusic command for it to play properly, although I ddn't have that issue in the build before that. The music seems to be a little off as well, not a big deal at all, maybe I just gotta download something for Timidity ++ and adjust it properly, but other than that K8Vavoom has been working great. Nice job Ketmar!

[-TDRR-]

Hey @ketmar, sorry for bothering but i tried to fix the incompatibilities with the TDBots and after trying to play with them, i get a crash. Just start a multiplayer game and then use "addbot" and bam, instant crash. It's the "reference not set to an instance of an object" thing again.

 

Here's the conlog.log file ending:

 

Spoiler

 

(No that message wasn't me chatting, it was the bot)

Log: spawned player with class <DoomPlayer>...
Log: TDRR: I am ready to roll!
Log:
=== VaVoomScript Call Stack (5) ===
Log:   000: linespec.EntityEx.checkIfTargetInLOS (progs/linespec/entityex/EntityEx.Misc.vc:3410)
Log:   001: linespec.Actor.A_JumpIfTargetInLOS (progs/linespec/actor/Actor.StateJump.vc:226)
Log:   002: decorate.BotFunc_LightRoam. (TDBotsV14Vavoom.pk3:decorate.dec:211)
Log:   003: linespec.CustomInventory.TryPickup (progs/linespec/basic/CustomInventory.vc:37)
Log:   004: linespec.EntityEx.GiveInventory (progs/linespec/entityex/EntityEx.Inventory.vc:356)
Log: =============================

*** Sys_Error: Reference not set to an instance of an object

 

 

I'm going to bet it's a bug with my code but it would be nice if you told me what i did wrong.

 

Here's the mod: TDBotsV14Vavoom.zip

[ketmar]

2 hours ago, Beezle said:

Is there an option to make the weapons more visible? They seem to be hidden a little bit under the screen, but then again it might be because I set the game at a weird resolution, 1152 x 864.

there is a known bug with weapons at some resolutions, yet i am not able to reproduce it. that is, it looks ok for me. can you give me a screenshot, please? maybe what i think of as "looks ok" is really "fuckin' broken", but i just used to it? ;-)

 

2 hours ago, Beezle said:

It looks like you fixed the crashing issue, in the last build I had to set the -nomusic command for it to play properly, although I ddn't have that issue in the build before that.

yeah, it should work. yet timidity is a can of worms. i really need someone to add support for other synthesizers (i just have no time to do it myself). anyway, glad it works for you.

 

2 hours ago, Beezle said:

The music seems to be a little off as well

eh, timidity again... it is old and basically unmaintained. you may want to try different timidity sound banks, or sf2 soundfonts with "snd_timidity_sf2_file"; please note that you may need to restart the engine after changing soundfont. also, sf2 support in timitidy is... not the best one.

 

tbh, it works for me with sf2 i once found in teh internets, and i usually don't really care about music, so this code is mostly untouched. adding other synthesizers (opl, fluidsynth) require complete rewrite of midi playing code, and i already have too many things fighting for my time. ;-)

 

for standard doom music you can download vorbis files from the link in the first post, they sounds exactly like the original. for midis from pwads... sorry, i owe you an ear. ;-)

 

thank you for trying k8vavoom, and sorry for inconveniences.

Edited June 15, 2019 by ketmar

[ketmar]

2 hours ago, -TDRR- said:

sorry for bothering

any questions and reports are always welcome. especially when people are trying to make something working in k8vavoom! ;-)

 

2 hours ago, -TDRR- said:

I'm going to bet it's a bug with my code but it would be nice if you told me what i did wrong.

nope, you did nothing wrong, this is my bug. thanks for spotting!

 

i attached updated "basev/common/basepak.pk3". just replace yours with this one, it has the bug fixed.

 

update.7z

Edited June 15, 2019 by ketmar

[Beezle]

Here's the screenshot, but on second look, it actually doesn't look unusually at all, must just be the resolution because normally I have it at 1366 x 705 or whatever Doom Retro has it defaulted at. I read your opening post again and downloaded the music pack in ogg format, and it sounds gret after launching with the "-file doom2_sc55_ogg_v1.2.zip" commmand. Thanks Ketmar!

Edit: Yeah on screen it looks very normal hehe, but in game its just slightly stretched.

[ketmar]

39 minutes ago, Beezle said:

it actually doesn't look unusually at all

no, you are absolutely right, it is actually lower than it should be. you are supposed to see a full hand and a part of the glove (and it looks like that for me). thanks, i'll try to check if there is something unusual in the code. don't hold your breath, though: psprite positioning code is something i never understood -- i just hacked it until it looks ok for me, and then ran away. ;-)

Edited June 15, 2019 by ketmar

[ketmar]

@Beezle you can make your life easier by using k8vavoom autoloading feature. just rename zips to pk3s, and copy them to "share/basev/doom1/autoload/", and "share/basev/doom2/autoload/" (you have to create "autoload/" directories there). k8vavoom will automatically load all wads and pk3s from the respective "autoload/" directory when you're starting the game.

[-TDRR-]

7 hours ago, ketmar said:

update.7z

I can't download that, have been trying for half a hour and it downloads at 3kbps and immediately stops at 50-60% while all other downloads not from here work fine, can you upload it somewhere else? Here is a page you can upload it to without registration: https://filebin.net/

[ketmar]

@-TDRR- ok, let's try with catbox. ;-)

[-TDRR-]

The fix worked well, thanks! Going to wait for the next update to release a full TDBots version for Vavoom. But i got a question:

How do i replace a Vavoom C definition using a .pk3? Say, i want to replace BotPlayer_Base.vc with a .vc file on my .pk3 file, how do i do it?

[ketmar]

1 hour ago, -TDRR- said:

How do i replace a Vavoom C definition using a .pk3?

you can't. ;-) at least not by directly replaceing VC source files.

 

the idea is that Vavoom C mods are extending the objects, not replacing the original source. you can inherit from the existing class, and extend it. for bots, you will need to do something like this:

 

class NewBot : replaces(BotPlayer);

 

and override any methods you want (or completely replace `BotTick()` and `OnXXX()` methods with your own).

 

note `BotPlayer` here -- this is actual bot player class that is defined for each game. `BotPlayerBase` provides common AI code, and then each game customising it. you can do the same.

 

also note `replaces(BotPlayer)` -- this does both inheritance, and works mostly like decorate "replaces" for spawning functions.

 

then you should place your replacement code in "progs/mycode", create "classes.vc" file there (this is the file that the engine will load, you should #include your other sources there), and create "loadvcs.txt" file (it is like "loadacs"). see "mods/bdw/bdw.pk3" -- it has VC mod code, and "loadvcs".

 

eh... this explanation sux. i hope you'll be able to figure it out, but feel free to ask more questions. ;-)

 

p.s.: also, please note that Vavoom C code is case sensitive, unlike ACS, decorate and ZScript.

Edited June 16, 2019 by ketmar