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

ketmar

Members
  • Content count

    1133
  • Joined

  • Last visited

Everything posted by ketmar

  1. that's exactly what i meant. ;-)
  2. basic UDMF would be easy. but nobody needs *basic* UDMF! ;-) implementing all properties of at least zdoom namespace will require massive improvements in UI (tbh, i don't even know how to do that without either making UI a mess, or making using UDMF properties a PITA; but i universally sux at UI design anyway). also, built-in nodes builder will require fixes for non-integral vertex coords too. also, pk3 support is not maps, it is for resources. and parsing decorate to extract doomed numbers will be great too. p.s.: yeah, this is all in my TODO list... when i'll finish k8vavoom. we know what that means.
  3. ketmar

    Oops! All Techbase - Project Thread

    join the army project, and it will answer all questions! techbases ftw! ;-) (just in case)
  4. if you want your new pistol to appear in player's starting inventory, you have to create a new player class with a new inventory. see this and this. note that you only have to put "Player.StartItem" and "Player.WeaponSlot" there, but also note that inventory is not inherited (i.e. you have to put everything there, including fist and clips). the reason is that decorate replacement is only working for map things, but not for player's inventory.
  5. ok, now we have a perfect topic title: with a brand name, with a quote, and completely uninformative. exactly as it should be in the current year. actually, this topic is about my fork of excellent DooM sourceport Vavoom (original site). you can find the source code for my fork here. (logo idea by @wrkq, artwork by ar888) if you really want to know why you may want to try k8vavoom, it is becase of its unique lighting systems. k8vavoom has two renderers, one does lighting with lightmaps (think of Quake here), and another does lighting with the same algorithm DooM3 is using. try them both, you may like the emperor's new clothes. ;-) by the way, Janis knows about k8vavoom, and he is happy that Vavoom is not dead. he even mentioned us on the official Vavoom site! PLEASE NOTE that public builds are not "stable releases". while i am pushing out new builds when i consider everything "working good enough", and not by random, the builds are still developement versions. so expect occasional bugs here and there. sorry. also, please note that k8vavoom is NOT Vavoom! i am trying to keep the spirit alive, and stick close to the original Janis' intents (as i understand it), but k8vavoom and Vavoom are not interchangeable! thanks to my high INT stats, i found a way to edit posts, and to attach files. so you can find 32-bit windows build right here! last win32 binary update: 2019, Sep 06. in case you wonder, it is in this post. just scroll down a little, and you will eventually find it. FOR THOSE LOST POOR SOULS WITHOUT MUSIC: you can get DooM music packs here. just download .zip archive, and use CLI argument like "-file doom2_sc55_ogg_v1.2.zip", it should Just Work. MUSIC WARNING: if you want to play original MUS files, or custom pwad music, you will need a good soundfont. default windows soundfont doesn't work good with k8vavoom. you can download SC-55 soundfont from duke4. all you need to do is unpack archive in the directory with k8vavoom.exe. the engine will automatically load .SF2 file, and your ears should be safe. sorry for inconveniences. WARNING! network code is completely broken for now. i am planning to fix it ASAP. sorry. some interesting command line arguments for k8vavoom open spoiler to see two simple images of two k8vavoom lighting modes. please note that i deliberately chose a dull area, usually you will see much more eye candy! (see 3rd screenshot in the list) let's start with a brief overview of project goals. k8vavoom is basically my personal playground. i am not trying to chase featurefull sourceports like GZDoom, i just want something i can hack, and something i can use to play some random PWADs. yet original Vavoom supports alot of things (including two kinds of dynamic lighthing and shadowing), and it aged surprisingly well. basically, Vavoom is missing some new ACS opcodes, and some Decorate actions, but otherwise it is mostly on par with today source ports. so i am slowly adding missing things, fixing bugs, and improving (read: breaking) everything else. i must admit that i am not trying to make k8vavoom compatible with as many pwads as possible. that is, compatibility is "good enough" to play many different pwads, but AI, LOS checking, collisions and such are not set in stone. so if some map rely on exact engine behavior, it may, or may not work, and i may, or may not fix it. there are enough ports for "purists", and i prefer to keep k8vavoom open to various experiments. yet don't be afraid: i am using it to play pwads (of course!), and i am still playing at least one-two maps a day, so i won't suddenly break everything just because i can. ;-) IMPORTANT NOTE! PLEASE READ! i really-really-really-really need at least one more developer. one that knows decorate (and don't afraid to read GZDoom source to decipher what decorate action really does; but i can help here, and it is not frequently required). 'cmon, people! Vavoom C is very much like C, only better and easier! don't be afraid, i am always here to answer your questions (that is, if i know the answer myself ;-). improving decorate is fun -- you can immediately see results of your work, feedback cycle is very short (you may don't know that, but k8vavoom compiles the whole Vavoom C codebase at startup, almost 3 MB of source code! it is THAT fast!), and seeing previously broken mods working is a joy. i want to concentrate my efforts on low-level engine parts (improving Vavoom C compiler, adding JIT, rewriting renderer, writing faster GC, and such), and i really need someone to take decorate duties. if only somebody will step in, you will soon see features you've never ever seen in other engines! i have some secret plans on my table, but i am short of time -- there are too many things to do. JOIN THE DARK SIDE, WE HAVE VAVOOM C! now, a small and incomplete changelog. first things first: what i removed, for The Great Justice. as for Heretic/Hexen/Strife (and other DooM-based games): i am not playing those games, so their code is mostly untested. that is, everything should work, but sometimes internal engine changes can break things, and i may not notice that for a long time. feel free to report broken things here or via PM. and some new things, in random order: some future plans: known renderer/coldet bugs: ok, i am not a best writer on the planet, and this is prolly the best i can do to introduce k8vavoom. feel free to ask me any questions. as for binary builds: windows builds can prolly be done with MSYS2 and MinGW, but the only environment i tested is MXE cross-compiling toolchain. i have no dedicated web site for a project (and no windows system at all), so windows binary attached to this post was tested only with wine. i will be updating binary from time to time. there is a small README in the archive to make your life slightly easier. put your iwad files to "iwads" directory and run "vavoom.exe", or check README if you don't want to copy wads. enjoy. ZDL launcher should work too. MY FAVORITE MOD IS NOT RUNNING, K8VAVOOM.EXE JUST CLOSED! WUTTA?!!! engine's decorate/acs/mapinfo support is not complete. you probably hit something unimplemented. there is "conlog.log" file with console log and error messages. you will probably find some (many) errors there. for curious: decorate scripting is not fully implemented yet. but we are working on it. latest win32 update: 2019, Sep 06. brief changelog follows. k8vavoom_540906.7z just for fun: Spelunky Classic remake with k8vavoom technology! ;-) spelpub_531102.7z please, consider making a bitcoin donation: 3GRuM9AtXzuueiQaSbbLpkCJkCwNK3V7gA why would you want to donate? open spoiler to know my reasons! ;-)
  6. it usually means that your map has something missing. like "oops, there is no adjacent "shortest texture" sector for one of the tags", or something. Vavoom (and k8vavoom still) is very sensitive to the missing things other engines tend to tolerate. i.e. it expects a "perfect" map, without any error, even a slightest one. especially for extended actions, like boom's. this is something i usually fix when i hit it, but i need a map to see what exactly is wrong. if you can PM me a map (don't bother with additional monsters/textures/etc. if they're not required to trigger the bug), and give me "mypos" output, so i can teleport to the bad place and trigger the bug, this will be enough, i think.
  7. ah, it was fun! you almost made me believe that there is a Very Strange Bug in ACS engine! i even opened the map in the editor... and still didn't noticed the missing flag. gimme more such bugs! ;-)
  8. ah, that was fun! ;-) your map spots aren't marked to spawn on UV skill. and k8vavoom's default skill is "UV", not "HMP". so no map spots were spawned, and no monsters were placed. run it with UV skill in any other sourceport, and you'll see the same effect (or on HMP in k8vavoom, and the monsters will appear).
  9. @damned thanks for testing with k8vavoom! it is quite possible that there is a bug in the engine, or the engine is too strict following the rules. ;-) if you can provide a small sample that triggers the bug, i'll try to find out what is wrong. tbh, that boom support code is quite a mess, and it looks like at least some parts of it were copy-pasted for different actions. on top of that, i tried to clean it up without real understanding of what it does, which doesn't help too. so if you'll be able to produce a minimalistic sample, it would be of great help. thanks for dropping a note anyway.
  10. no, it writes config only on exit (or if you explicitly asked it to do so via menu/console command). there is some logic to deactivate possible mouse capture and clear some internal variables when the window loses focus, tho. of course, i believe that it cannot cause any unexpected behaviour (which usually means that it can ;-).
  11. oh, i see. statusbar didn't expected "no weapon in hand" case. to be more precise, it wants to draw mana levels, but has nothing to get them from. will be fixed in the next build. thank you! and nothing in logs too? (minimising/alt-tabbing on windows always was a problem for some reason; works like a charm on GNU/Linux and in wine, so i can only guess...)
  12. even more that that: the API is not guaranteed to be stable across builds. enjoy and have fun! ;-)
  13. @therektafire no, there are no tutorials yet -- i still have to write them. ;-) sure, you can create wads with new VavoomC code. creating new actors is not really different from creating other VC customisations. this is basically a normal "server VC mod". also, the whole VC code is compiled by the engine when you run it, so you don't have to run a separate compiler, a-la ACS. but to write something that is not possible with decorate, you have to know how the game works, and be familiar with it's internal API. it is not that easy, because there are some quirks, and things like "you have to do it in this way only, even if it looks like you can do it in another way". i am planning to write some tutorials, but tbh, it is not a high priority task. i'd prefer people to use decorate anyway, to keep things compatible with other sourceports. that is, you have to be absolutely sure that you only want to target k8vavoom if you'll go VavoomC route. ;-) of course, one can try it out of sheer curiousity. but for now, you're on your own with this. you can take a look at bdw/gore mods to see how they're added their VavoomC code, and look into progs/ to learn other things. alas, this is all we have now. p.s.: VavoomC itself is quite similar to other C-like languages, though. it is also statically typed (like ASC), and its basic syntax is mostly compatible with C. there is also this text that briefly describes some VC syntax.
  14. @-TDRR- i'll take a look. i still didn't looked into `A_LookEx()` issue too. i remember that RRM was working fine some time ago, so it looks like i broke something...
  15. by the way i added built-in support for chex (original wads, and chex3; not heavily tested, though), and for hexen deathkings of this-name-is-too-long. sure, you were always able to run hexdd by simply adding it to a command line, but now it has an official option (-hexendd), and the game will know that it should look for hexdd.wad where other iwads live. otherwise, nothing interesting happens: i am still cleaning up and rewriting the code, so i had to resort to a cheap trick of implementing some one-line decorate actions just to fill the changelog. p.s.: also, "games.txt" (the file that is used to describe various games -- iwads, filters, etc.) has a new format now. because it is fun to break things, of course. and because old format sux. and new format can be parsed by any external utility without figuring out all the commands, because it has consistent syntax, and non-optional command terminators.
  16. 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.
  17. this is still not an excuse to provide inaccurate facts. especially when it is that easy to check them. things like that makes me thing if any of their facts are really facts, or the same kind of BS. dunno, maybe i am overreacting, but i abandoned reading "game sites" exactly because nobody there caring about facts. and stop watching youtubers when i see that they're don't mind lying. not that i really watched their show, but now i won't for sure.
  18. ketmar

    [WAD/MAP, DOOM 2, VANILLA] My first map

    thank you for reading it too. you have a good start here! i also love techbases, so it is great to see someone sharing that love. there cannot be enough techbases, we always have room for more! ;-)
  19. ketmar

    [WAD/MAP, DOOM 2, VANILLA] My first map

    not bad at all! of course, rooms are rectangular, and no height variations, but they aren't simple rectangles, you added details to make rooms look like something that has a purpose. that's great. the map is too symmetrical too. especialy at the outdoor area, where rocks somehow made almost identical landscape on both sides. doortracks aren't properly pegged, so they slides with the door. you provided cover from hitscanners, this is another good touch. good use of detailing and decorations. hiding a blue key behind an impaled body was a fun move, you almost tricked me! ;-) overall, looks like a good start. you seem to know how to detail a map so it looks interesting, and resembles some real place. ah, "height variations"... it is not only about having some floors/ceilings with different heights, it is also about "playing planes". if you'll put some monsters higher than others, the player will be forced to think in three dimensions. original id maps does this alot, by putting imps into "wall alcoves" which are much higher than the player. this way the player has to fight with "floor" monsters, and in the same time remember to avoid imp fireballs coming from above. that is what we usually mean with "height variation". your outdoor area with imps on those rock walls is what i mean, for example. make those rocks little higher, and maybe drop imps onto crates too -- and it may work even better. p.s.: using ordinary door as level exit is... questionable choice. it is not "bad" or "forbidden", but the door doesn't look anything special. i think putting the usual exit switch behind that door will work better for map flow.
  20. i can't add much to what already been said, except that i have a feeling like it is a three maps glued together. visuals are ok, it's not about abrupt style changes or something, it is more about a flow. maybe it is just not a my style of maps, or maybe i just didn't expect it, but it feels like i have to do too much for one map. but this doesn't mean that the map is bad, no. i enjoyed it. it is just a small feeling, and it doesn't make the map bad.
  21. 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)
  22. ketmar

    Things about Doom you just found out

    they clearly has no brain to remember what they're doing. ;-)
  23. most rectangles can be made unrecognizable (as rectangles) with details. cut some alcoves for lamps, put stairs with an armor in the corner, add some computer panes by the walls... and suddenly, your boring rectanglular room is not so boring anymore. id used that trick alot, btw.
  24. ketmar

    Things in modern gaming that you dislike

    that's why simulation timer should be capped at ~30 msecs! ;-) (but really, most of the time it is enough, and "smooth 60 FPS" can be done with interpolation.)
  25. ketmar

    The Doom Confessional Booth

    and to this.
×