k8vavoom: no good thing ever dies!

[ketmar]

15 hours ago, saibog said:

could you add a chevron/caret as one of the crosshairs?

you can do it yourself with a simple mod. all crosshair graphics is "graphics/crosshaiN" lumps, where "N" is a digit. as for inclusion in default set... all default crosshairs are drawn for 320x200 resolution. your crosshair shape simply will not look good with that small size. and i don't have plans to bump default crosshair picture resolution for now.

 

15 hours ago, saibog said:

could the center for the overlayed automap be toggle to have a mini version?

it is technically doable, but i'm not convinced that the feature is worth inclusion at the present time. i mean, i have plans of "widgetization" of most HUD elements (so players will be able to configure fullscreen HUD with drag-n-drop), and automap will be converted to resizeable widget too. automap code has hard-coded fullscreen logic, so it should be almost completely rewritten first. i'd better leave this rewrite to the time when i will do complete HUD overhaul.

 

i.e. your idea is not rejected, but it will have to wait... a little. ;-)

 

15 hours ago, saibog said:

capable of running the biggest most complex map for classic doom. for example, a true to scale 20x20 miles (400 square miles) open-world map (read "open-hell" map) on a low end computer.

sorry, but this is out of project scope. supporting huge overdetailed maps with acceptable FPS is something that will require a complete engine rewrite, and this is also something i'm not really interested in.

 

that is, i never wanted to turn k8vavoom into "universal idTech1 engine for creating TCs". at least not open-world TCs with alot of non-doom effects. idTech1 is not a good choice for such things anyway, due to alot of internal architectural limitations which cannot be changed without losing compatibility with... well, with all existing idTech1 games. ;-)

 

the most limiting thing is that it is impossible to run playsim on multiple CPU cores. and the engine should run playsim (including physics emulation) for almost every entity on the map. i recently introduced alot of hacks to skip full physics for entites that look like "dormant", but it is still a hack, and it won't help "open-world" maps, because there will be alot of things roaming around, or doing some game logic (almost everything in the game world is done with invisible entities -- moving lifts, closing doors, even scrolling textures; and there is no way to skip those computations).

 

also, rendering huge detailed maps is CPU-consuming task too, and it will also require a good GPU. idTech1 is very GPU-hostile, and the engine has to do alot of work to keep acceptable framerates on complex maps. yes, the box that can render modern Crysis in solid 60 FPS can have single-digit FPS on something like Frozen Time bridge scene. there is nothing we can do with that, at least not without completely dropping compatibility with existing idTech1 games. GZDoom is trying hard to utilize CPU and GPU as good as possible, and it is still struggling with Frozen Time. and GZDoom renderer performs alot of tricks under the hood, including using multiple CPU cores to process geometry and feed GPU.

 

tl;dr: it will require rewriting most of the engine code just to get a "nice to have" feature that will hardly be used by anyone. i simply don't have physical resources (time and energy) to do that. it will require several man-years of hard full-time work. sorry.

 

15 hours ago, saibog said:

the maps could have weather cycles, wind effects (have debris flying, moving fog, etc).

advanced physics like glass shattering, rocks breaking, water ripples, etc.

this is something that can be emulated with VavoomC, at least for some extent. the whole playsim (including physics) is written in VavoomC, and can be modified if necessary without recompiling C++ code.

 

of course, it is hard to do, because there is almost no documentation on VavoomC and engine internals. but this is partly because i don't want people to use VavoomC. mods with VavoomC code will create a kind of "vendor lock-in" -- they absolutely cannot be portable to other sourceports, and i strongly believe that cross-port compatibility must be one of the primary targets of the sourceport. i.e. using VavoomC (or ZScript, for that matter) to create a gimmick (which the map rarely needs anyway) will prevent people to play the map in other sourceports. it is ok to add new linedef specials, or DECORATE actions, because they can be emulated in other engines. but VavoomC cannot be "emulated", because you have to rewrite your engine to be exactly like Vavoom to allow VavoomC mods. (and yes, to "emulate" ZScript you have to be exactly like GZDoom).

 

that is, maps that are designed to use k8vavoom lighting can be playable in other sourceports. they will not look right, but they will still be playable. 3d polyobject feature i'm working on now can be implemented in other engines too; it may be hard to do, but it is doable (and i will try to provide "good enough" specs, so 3d pobjs can be implemented in compatible way simply by reading the documentation). yet if the map is using some VavoomC code for its logic/playsim... this is game over. if one day i'll be hit by a bus, all such maps will become mostly unplayable over the time.

 

also, i don't want people to use VavoomC because i'm often changing engine internals, and keeping compatibility with existing VC mods will be a PITA (if possible at all).

 

of course, if somebody wants to start a huge TC/standalone game based on k8vavoom, i can provide some help. but most of the time people want k8vavoom to be "GZDoom with k00l lighting modes", and there are alot of GZDoom features i will never ever implement.

 

 

sorry for this huge rant, that mostly has nothing to do with your suggestions. ;-) thank you for trying k8vavoom, and for giving a feedback! even if i can't implement your ideas "as is", they're still valuable, and giving me some food for my thoughts; it may inspire me to implement more features to make the engine better. so don't hesitate to drop even your most crazy ideas here. one of them may "click", who knows... ;-)

[ketmar]

also, i think that the public build is very close. i need to test some non-pobj related changes and such, but everything i wanted to have is there, and seems to work. 3d pobjs is an experimental feature anyway, and it will be improved later, but i want to be sure that if i documented something as "allowed with 3d pobjs", it will work as expected, and you won't have to fix your maps later. just don't do anything that is not explicitly allowed in specs, and you should be safe. the documentation and demo maps will be included in the next public build. i still have to decide what will be the best for some small implementation details, and document some unobvious things, but there should be no major release blockers anymore.

[ketmar]

i mostly finished with 3d pobj specs (first draft, v0.99 ;-), so there is a hope to see the public build in the next week 7 days. ;-) still need to create some simple demo maps, as those i'm using for development are quite messy.

 

i tried to add alot of checks, so the engine should reject most invalid configurations. i.e. the map with invalid 3d pobj will not be loaded most of the time. i think this is much better than silently accepting almost anything and then try to make maps with UB work. of course, there is more than one way to cheat the checker code, but i hope that it won't become a new mapping challenge. ;-)

[Remilia Scarlet]

41 minutes ago, ketmar said:

i tried to add alot of checks, so the engine should reject most invalid configurations.

Honestly, I kinda like stricter checks.  Feels more forward-compatible when I know that what I do is correct, not just "accepted".

[ketmar]

47 minutes ago, Remilia Scarlet said:

Feels more forward-compatible when I know that what I do is correct, not just "accepted".

yeah, that's the idea. i'm trying to make sure that if the engine accepted something, it won't suddenly break in future versions due to some UB. i won't make the same mistake ZDoom did! ;-)

 

of course, checks aren't ideal, and cannot catch everything, but it is still better than totally nothing, i believe.

[Mr.Rocket]

Yep..

[ketmar]

5 hours ago, Mr.Rocket said:

Yep..

pre-release testing. ;-) just look at git log -- no major changes, just small fixes here and there. still have to create demo maps for 3d polyobjects. of course, i have those i used for dev and testing, but they're very barebones. maybe i'll still use them, tho. not the best way, i wanted something much more interesting (like rotating cogs a-la Duke3D, and aerial lift with several stop points), but...

[ketmar]

On 4/21/2021 at 5:26 AM, terminator said:

could the center for the overlayed automap be toggle to have a mini version? the mini version of the automap could be moved anywhere on the screen (via coordinates in k8vavoom options) and the display area of the automap be customised (via size parameters in k8vavoom options) like the mini-automap in the screenshot below? the mini automap could also be zoomed.

...and i though: 'cmon, why not? i can always reimplement it later for the new UI, so there is no reason to not add it right now. and i implemented a configurable minimap (no menu configuration yet, only cvars; but i hope to implement simple visual configuration later this day, or tomorrow).

 

screenshot. ;-)

Spoiler

 

[Gunrock]

Ketmar you are going full "beast mode" on K8Vavoom. Perfect time to use it on my upcoming Project Slipgate: Remastered. One quick question....how are donations handled?

[terminator]

9 hours ago, ketmar said:

...and i though: 'cmon, why not? i can always reimplement it later for the new UI, so there is no reason to not add it right now. and i implemented a configurable minimap (no menu configuration yet, only cvars; but i hope to implement simple visual configuration later this day, or tomorrow).

 

screenshot. ;-)

  Reveal hidden contents

 

wow! thanks, @ketmar. love it :)

[Arl]

@ketmar may I ask why do you thought Vavoom to be the best. I'm intrigued.

 

Also, what are your ideas for your fork in the future? more graphical goodies? some custom mapping format? more compatibility with existing pwads? stand along game engine?

 

 

Great job, I'm loving it.

[ketmar]

9 hours ago, Gunrock said:

how are donations handled?

food and internets. ;-) my stable income is zero, so the less i have to care about living expenses, the more time i can spend on k8vavoom development. if you want me to work specifically on some feature, it is negotiable too. if the feature is not ruining my dev plans, and your project/idea is interesting enough, i may do it. in this case donation may improve the speed (but no, you can't "hire" me this way ;-).

 

tl;dr: donations are used for living. i hope to get enough for booze and hookers everyday, but this is still a dream. ;-)

 

if you'll look at git commit log, you'll see that i am pushing commits almost every day. and there are more private branches where i'm experimenting with new ideas and such. basically, i'm woriking on k8vavoom as "full-time project" (and even more), only mostly for free. ;-)

 

 

6 hours ago, terminator said:

wow! thanks, @ketmar. love it :)

you're welcome. even i don't know when some interesting idea may "click", so bring more, please! ;-)

 

 

6 hours ago, Arl said:

may I ask why do you thought Vavoom to be the best.

very clean codebase, good architectural design, features that some engines started to implement only about decade after Vavoom development suspended. if you'll take the original Vavoom source code, you could see that while it is definitely not finished, there is the careful planning behind it, it's not just features randomly dropped in (yeah, ZDoom, i am looking at you). Janis is programming genius.

 

i don't care about having "next-gen gfx" in Doom engines ('cmon, it's Doom we're talking about!), yet Vavoom rendering is still unique too -- this is the only engine with lightmapped lighting a-la Quake (even with overbright support). currently, lightmapped mode got less love than i wish to give it, but it is not forgotten. i just don't have enough hours in a day to code everything i want to code. ;-)

 

6 hours ago, Arl said:

more graphical goodies?

graphically, i don't think that i will go much further. i definitely won't implement any kind of "PBR" (i.e. no materials, normal maps, etc.). i don't think that with Doom low-res textures it looks good, and i don't like hires textures at all (i'd happily nuke support for hires textures from k8vavoom, but i can't, because it already was in Vavoom, and i'm usually not removing features until it is strictly necessary). implementing shadowmaps was planned from the very beginning, tho, so i did it.

 

so, don't expect fancy shiny materials or custom shaders. graphically k8vavoom is mostly like i wanted it to be. i will still work to make rendering faster, tho, but without sacrificing features, and preferably without bumping required OpenGL version (currently, you should be able to run k8vavoom with OpenGL 2.1 + GLSL120 capable GPU).

 

still, there will be floor/ceiling decals (the renderer can do it, it's the logic that is not there yet). also, k8vavoom is the only sourceport that can render decals on masked walls, afaik. this is because i LOVE blood splats, and want them everywhere! ;-)

 

6 hours ago, Arl said:

some custom mapping format?

no, we already have UDMF, it is very extensible. custom UDMF namespace? yes, sure. i have plans to give mappers more control over lighting, and maybe some more.

 

6 hours ago, Arl said:

compatibility with existing pwads?

you already can play alot of pwads with k8vavoom, and i'm constantly improving things. it's not possible to be 100% compatible with everything (especially with maps utilising vanilla renderer hacks), but i am doing my best. don't expect k8vavoom to be demo-compatible or such, and don't expect it to emulate every vanilla quirk, but it is still Doom, it feels like Doom, it plays like Doom.

 

sure, i added alot of gameplay-changing features (like headshots and criticals, or higher friction for player mobj), but all such features can be customized/turned off, to give the player "mostly vanilla expirience" if they want so.

 

DECORATE support is very important too. i did alot of work to improve it (Vavoom had nuts and bolts in place, but it was last touched 10+ years ago...), and i'm still working on DECORATE, to make even more mods playable.

 

6 hours ago, Arl said:

stand along game engine?

even Vavoom could be used like this, and k8vavoom made this even easier. almost everything in Vavoom/k8vavoom is written in VavoomC -- this includes AI and even physics. VavoomC source is compiled by the engine on the fly, so it is possible to create a completely different game with k8vavoom tech without ever touching C++. most of other engine definitions are textual files too (including most of the menus).

 

but this is not the goal of the project, it is just a side effect of the engine architecture. k8vavoom is, and will always be the engine to play Doom (and Heretic, Hexen, Strife). this is what i am using it for (i love to play Doom!)

 

6 hours ago, Arl said:

what are your ideas for your fork in the future?

oh, i have a huge TODO list. i don't want to promise things i may not be able to do, though.

 

there will be a widget-based HUD with visual drag-n-drop customisation (the core widget mechanics is there; you may not notice it, but Vavoom UI built with full-featured hierarchical widget system).

 

i will eventually add tools to help mappers too. you'll be able to open in-game map editor, and tweak alot of things. i'm not sure about changing geometry yet, but everything else should be tweakable. the first thing i want to implement is real-time lighting editor, which will be of great help for making maps look great, i guess. i mean, no editor is capable of rendering the exact picture, and with rich set of Vavoom/k8vavoom rendering modes i don't expect editors to catch up. yet the engine can do lighting in real-time, so editing the lighting inside the game looks natural.

 

i have plans to finish bot AI too. currently, there is a foundation for it, and some very rudimentary code. but i want bots to be able to finish most "normal" maps on themselves. i.e. the bots should be able to understand the map and various switches effects, plan their routes, and use long-term goal planning.

 

there are alot of other things i'm experimenting with, but it's too early to talk about them. let me just say that my TODO/roadmap for k8vavoom is big enough that a studio of 5-8 people should work fulltime for around 3-5 years to implement everything i want to do. and i'll inevitably add more ideas to the table. ;-) of course, as i am doing almost all design and coding by myself, i have to prioritize things, and sometimes spend monthes paying techincal debts (code cleanups and such, to keep the thing maintainable), so implementing even the things i described above may take years. but i'm not in a hurry anyway. ;-)

 

i'm full of ideas, and full of enthusiasm. i was working on k8vavoom prior to puiblic announce, so it makes 3+ years of work now, and i am even more excited than i was when i started. don't expect k8vavoom to die again! ;-)

 

ah, and i'm always ready to add gameplay features that people may want. if somebody want to create a map, and can think of some engine feature that may help, don't hesitate to PM me. even if your request will be rejected, i'll try to explain why exactly the feature is impossible, and we'll try to find a workaround. or you can simply drop your ideas right into this thread, and something may stick. ;-)

 

6 hours ago, Arl said:

Great job, I'm loving it.

thank you! and stay with us, we have cookies demons and shotguns!

Edited May 9, 2021 by ketmar

[Mr_SquarePeg]

Hey @ketmar I have a question or two for you. Is there any documentation or cookbook style examples (how to make X or how to do Y) for VavoomC? I have been learning various C based languages recently. Mainly C# and C++. I want to start working with VavoomC for a few projects I am working on. 

 

How many players can play in a single multiplayer game with K8Vavoom?

[ketmar]

i could postpone it forever, adding more and more features, but sometimes somebody should come and say: "stop!" so i looked at the mirror, and saw a writing there. it was "STOP!", with big red letters.

 

so, here is the new build for you all!

 

note, that this build has alot of code changes under the hood, so it may have small unexpected glitches here and there. i tried to test is as much as i can, but shit happens sometimes.

 

if you're interested in 3d pobj specs and simple demos, look into "specs/3dpobj/k8vavoom_3dpobj.html" file for specs, and "specs/3dpobj/simple_wads/" for some demos. sorry for demo wads quality (or, rather, the lack of). they are mostly slightly cleaned up test maps i made during 3d pobj development.

 

PLEASE, READ THE SPECS CAREFULLY, AND DON'T DO ANYTHING THAT IS NOT EXPLICITLY STATED AS ALLOWED/DEFINED IN THE SPECS!

also, if you'll make some maps with 3d pobjs, please, report any behavior that contradicts the specs.

 

brief changelog:

Spoiler

* WARNING! your saves may be broken again! sorry! (renamed VavoomC `Level` class to `VLevel`)
* alot (ALOT!) of internal code changes required for the next three bullet points
* implemented t-junction fixing code for lightmapped renderer (there should be no more Space Ants in any of rendering modes! except for polyobjects. ;-)
* new polyobject management code: polyobjects now aren't restricted with the original Hexen rules
  (i.e. they can have any shape, cross sector boundaries, and can reside in any sector)
* experimental 3D POLYOBJECTS implementation: they have height, can move in all 3 dimensions and rotate, and they can carry things on top of them!
* lightmapped mode may lit 3d polyobjects wrongly, or not lit at all; this is known problem that will be solved later
* 3d polyobjects may have some Space Ants; will be fixed later too
* experimental support for UDMF user fields (VavoomC and ACS API included)
* implemented ACSF `DamageActor()`
* fixed bug in `A_RadiusThrust()` (it should not damage actors)
* added options for fine control of sprite shadowmaps (thanks, Firebrand!)
* added SF2 selector (with presets for each selected SF2) to sound options menu
  (drop all your SF2 files where the binary is, and you'll be able to switch between them with the menu)
* crop brightmap textures if their base textures were cropped (thanks, id0!)
* completely rewritten surface generation code (should have less visual glitches with various 3d floor configurations)
* new texture mapping calculation code (not fully finished yet, but slightly more correct than it was before)
* do not switch Doom title screen while title music is still playing
* fixed small memory leak in game saving code
* added proof-of-concept of "advanced damage indicator" (options -> hud -> damage indicator)
  it shows horizontal and vertical direction of the incoming damages;
  vertical direction is shown by smaller bars; inside bars means "down", outside bars means "top";
  you'll get used to it (i hope ;-)
* fixed long-standing hitscan bug -- hitscan attacks could miss some walls and things in some very special cases
* you can bind up to 4 keys/buttons from control options menu now
* experimental game controller support, with hotplug (but hotplug works only with one controller yet)
* added some TPlane methods (3d algebra) to VavoomC
* better sorting of translucent surfaces vs sprites (still not perfect, and may glitch with translucent 3d slopes, but hey, translucent slopes are not officially supported anyway)
* textures with solid and translucent pixels now rendered in two passes, so solid pixels could be lit and cast shadows
* added separate autoaim control for hitscan and projectile weapons (with possibility to force autoaiming)
* automap controls are fully configurable now
* implemented "CheckSwitchRange" mapinfo and linedef flag (experimental)
* fixed off-by-one month in save dates (lol) (thanks, Steinkrauz!)
* added "+k8MuzzleFlash" actor flag to mark muzzle flash actors (this is used in some light calculations; it is not necessary, but recommended to mark such actors)
* implemented `SoundSequenceOnXXX` ACSFs ("on sector" is only partially) (thanks, Remilia Scarlet!)
* corpses should not slide off from 3d floors anymore
* sprite precaching should work with sprite brightmaps and psprite cropping now (i.e. it should be safe to turn it on)
* added HUD options to draw map stats and name when not on automap
* added simple minimap widget (controlled with "minimap_*" cvars, and new options menu)
* fixed pk3 filtering system ("filter/" directories) -- they weren't working for several builds (thanks, id0!)

 

[ketmar]

27 minutes ago, Mr_SquarePeg said:

Is there any documentation or cookbook style examples (how to make X or how to do Y) for VavoomC? I have been learning various C based languages recently. Mainly C# and C++. I want to start working with VavoomC for a few projects I am working on.

sorry, there is no proper documentation yet. also, while you can use VavoomC for writing standalone programs, it's not that easy. you have to build vccrun from the sources (and this may be a really complicated task for windows), and you have to know where to put core .vc source files, and which ones. the language itself is very similar to C# (and to D), but its standard library is not very big, and mostly consists of things i need for k8vavoom.

 

in the future i may release a standalone vccrun version and some samples, tho. it is quite easy to write simple gfx apps with vccrun, so it may be a fun testbed/playground.

 

and if you want to write a mod for k8vavoom using VavoomC... oh, abandon hope, all ye who enter here! ;-) you have to know much more than the language itself -- the deep knowledge of k8vavoom engine architecture and internals is required too. and of course, there is no documentation on it either.

 

sorry if all this sounds disappointing. VavoomC is very powerful, but it is not well-suited for learning. to make it more friendly i have to write alot of documentation, and i simply don't have enough time and resources for this.

 

still, if you're curious, you can look into basepaks. the engine compiles VavoomC code from the sources on startup, so basepaks contain full and unobfuscated VavoomC source code. just don't modify it. ;-)

 

also, you can PM me if you really want to create some TC that requires VavoomC code. we may find some solution.

 

27 minutes ago, Mr_SquarePeg said:

How many players can play in a single multiplayer game with K8Vavoom?

8. the engine is capable of more, but currently maximum number is hardcoded as 8. also, please note that MP code is not as good as i want it to be, and lacks many features (like client-side predictor, for example). i have plans to improve it, but the priority is quite low, as i'm not playing MP games at all. MP games should work OK over the LAN, but playing over internet, especially with high ping, may not be a pleasant expirience.

[Mr.Rocket]

I think at least the base commands should be compiled and documented, for now. :P

[ketmar]

started working on floor/ceiling decals:

Spoiler

 

as i said, the renderer is able to draw 'em, but there was no high-level support code. now the code to handle "flat decal lists" is there. still alot of things to write, tho, including more-or-less proper decal spreading to/from walls, some new options for decal definitions, and so on.

[ketmar]

proof-of-concept "flat decals" from blood and rockets:

Spoiler

 

[ketmar]

19 minutes ago, MidnightMage said:

OH MY GOD! I'm convinced this port does everything!

not yet... but i'm doing my best. ;-)

 

we have SUCH SIGHTS to show you!

[ketmar]

wrote more "flat decals" code. yep, transparent 3d floors can get some blood and scorches too.

Spoiler

 

[Mr.Rocket]

F**king awesome man!

@ketmar, you never ~ seize to amaze me.

 

[ketmar]

@Mr.Rocket thank you! as i said before, the renderer doesn't really care on which surface it should paint decals. it's the high-level code that spreads decals over subsectors and such that was missing.

 

i'm not finished yet, tho. ideally i want decals to "naturally" spread, i.e. wall decal should continue on the floor if it is big enough, and vice versa. but this can wait a little, because i need to redesign the whole decal attaching code first. so "flat" decals are not as good as i want them to be, but hey, at least rockets, fireballs and gunshots can leave scorch marks on floors and ceilings now! and such marks are usually way cheaper to process than floor sprites.

[SovietPony]

Hello again. I present fresh Android build based on latest stable PC version (560511).

For now it includes simple launcher and ugly hardcoded touch screen controls.

Right touch screen area emulate mouse, so settings like mouse sensitivity also applied to touch screen.

 

Previous post about android port

Download APK

[ketmar]

btw, Strife is broken (crashing at startup) in the current build. i know about it, and it is already fixed. sorry, my fault. will release patched basepak.pk3 if anybody need it. or just wait until the next build. ;-)

[ketmar]

experimental palette tonemapping (dunno if i'll keep it, and it seems that it needs some more adjustments):

 

rgb:

Spoiler

 

palette:

Spoiler

 

[Redneckerz]

4 hours ago, SovietPony said:

Hello again. I present fresh Android build based on latest stable PC version (560511).

For now it includes simple launcher and ugly hardcoded touch screen controls.

Right touch screen area emulate mouse, so settings like mouse sensitivity also applied to touch screen.

 

Previous post about android port

Download APK

Just want to say thank you for this :) I appreciate things like these coming out of the woodwork from developers such as yourself. Ill try it out on my phone (Snapdragon 460 based/Adreno 610) these days.

[boris]

Those 3D polyobjects are pretty neat. I noticed a small glitch, though. When you shoot projectiles right above the bottom, the projectiles just vanish: https://streamable.com/up886j

 

Another peculiar thing I noticed is that k8vavoom saves its config file in the directory it was launched from, not where the executable is located at. For example if I drag and drop a .WAD from my downloads folder onto the k8vavoom executable, the config will be saved in the downloads folder. Is that intentional? I'm on Windows 10.

 

[edit]

Also, is there a way to move and rotate a 3D polyobj at the same time?

Edited May 22, 2021 by boris

[ketmar]

7 hours ago, boris said:

I noticed a small glitch, though. When you shoot projectiles right above the bottom, the projectiles just vanish

thank you! yep, techincally, it hits the floor of 3d pobj, and don't have a proper "hit line" (i forgot to set it ;-). the engine doesn't expect this, and simply removes the projectile. thanks, i'll try to fix it. (the whole `CheckRelPosition` code and `tmtrace_t` should be completely redesigned, tbh, but...)

 

7 hours ago, boris said:

Another peculiar thing I noticed is that k8vavoom saves its config file in the directory it was launched from, not where the executable is located at. ... Is that intentional?

no, this is definitely a bug. thank you, i'll look at it!

 

7 hours ago, boris said:

Also, is there a way to move and rotate a 3D polyobj at the same time?

oops. i forgot that pobj actions cancels each other, and thought that they will stack instead. ;-) so no. i'll add new ACSF in the next build, thank you!

(technically it will still be "move, then rotate", of course).

 

also, i forgot to document it, but avoid rotating complex structures for now. i mean, they will rotate without problems, but the player/other entities may stuck. this is because bounding boxes are always axis-aligned, and may stuck in pillars or alike on rotation. i.e. rotate only simple flat platforms for now. i'll try to do find some solution for the next build.

Edited May 22, 2021 by ketmar

[boris]

Played a round a bit and made a small test map. It's really impressive how the polyobjs have no problem interacting with other gemoetry, flawlessly overlapping it.

 

 

I noticed that PolyObj_MoveToSpot doesn't work correctly with 3D polyobjs , it doesn't move them on the z axis. Is that intentional? The new PolyObj_MoveToSpotEx works, of course, but it seems slightly buggy. In that video you can see one platform move in a diagonal line. It's actually supposed to move between 4 spots in a clockwise order, but the position checks seem to do something wrong. When I move the map spots slightly on the y and z axes it suddenly works (but then the positions are off, of course).

And even that diagonal movement doesn't seem correct, movement on the x/y axes seems too fast compared to the z axis, so that the final x/y position is reached before the z position is reached.

 

Example map attached.

3dpolyobj.zip

[SyntherAugustus]

Is there portal support in this port? It would be neat to make a map that features both portals and these 3d polyobjects.