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

ketmar

Members
  • Content count

    1133
  • Joined

  • Last visited

About ketmar

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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. 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.
  6. 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! ;-)
  7. 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).
  8. @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.
  9. 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 ;-).
  10. 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...)
  11. even more that that: the API is not guaranteed to be stable across builds. enjoy and have fun! ;-)
  12. @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.
  13. @-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...
  14. 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.
  15. 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.
×