except it is a cheap hack. it will cause an inconsistency in how channels work for a specific few cases which can cause confusion and annoyance later down the line for some poor bastard modder who isn't aware of one guy's attempt to 'fix' behaviour that was working as intended. a sound is expected to override the previous sound playing on a channel.

if it bothers you, fix it in qc (channels 5, 6 and 7 on the player are rarely, if never(?) used-- they could easily be used for a second item channel) because it's a qc bug. you can even play the pickup sounds on the items themselves, although the left/right won't be balanced because the sound isn't emanating from the player, but that solution is probably the most easiest to implement. 

That made a far better case for your point than your previous post ;)

I guess my frustration wasn't really due to you calling it a cheap hack (because I'm not disputing that); it was more the feeling that you were dismissing it outright. The truth is I respect you for all you've contributed to the Quake community, so it's people like you I need to hear from to help me see things from a mapper/modder view. So thanks for the followup.

For me, the annoying thing with a bug like this is, here we are, 13 years later, and the QC hasn't been fixed (afaik; maybe you guys did in Quoth, but that would still leave a few hundred mods that are potentially affected, plus the thousands of maps that people don't run under Quoth).

One part of your post I didn't quite get was the "play the pickup sounds on the items themselves". Were you talking about reworking the QC to call sound() in an item-specific touch function rather than the generic one? Or were you talking about the engine making use of the .noise field? 

I'm not actually convinced that it is a bug, because they added the idea of specifying a channel to qc specifically so that the sounds could be overriden. Perhaps a few sounds should be split off into their own channels, like the landing sound and the item pickup playing seperately. But I can see the sense of not playing multiple "item pickup" sounds on top of each other, because it would create a pretty nasty echo effect. The current system of cutting off and resetting the sound on the same channel is probably easier to parse when you listen. 

sound(other, CHAN_ITEM, self.noise, 1, ATTN_NORM); from health_touch()

it plays the sound on 'other' which in this case, is the player who touched it.

if you change this (and the other items) to play the sound on 'self' instead, multiple pickups will all play sounds of the item itself, not the player.

the only problem is that if you pick up items from the side, the sound will not be centered like it is when you play sounds on the player. sounds that the player makes are always centered (they come out of the left and right channels equally).

and no, i didn't fix it in quoth (and i don't think preach did, because i don't remember noticing it when i played quoth2 stuff).

this is really a preference thing, but it never really stood out as something that really needed fixing to me. i never even noticed that it would be a problem because i always took it as a matter of course that multiple items being picked up at once results in blocking some sounds out. it's either that or, as preach mentioned, a cacophony of different pickups all at once which is just as difficult to make out.

also, be wary of using CHAN_AUTO (channel 0) because the engine just picks whatever free channel it can find. that can be the weapon channel sometimes so you'll be in the same spot with say your shotgun blocking out the quad pickup sounds now instead of the nail box. :S

this is just my opinion but i think bringing in cool stuff from more modern engines like doom3 such as proper scripting, proper rotating brushes (the rotating entity itself causes collision without needing to hack in invisible collision brushes) and hierarchical entity binding, all done engine side would be completely bad ass. you will notice i'm am avoiding things like real time lighting, bump mapping and such. to me, as a mapper, i'm less interested in those things than i am with stuff that can increase the creativity of the maps being created. 

Anyway, I did look into the rotation stuff a bit. Would the Hexen II code be good enough? Very little change on the engine side, but the collision is quite rough (it just expands the bbox so it's big enough to contain the entity at any angle).

Regardless of the method, the tricky part might be deciding when the enhanced code should be used. Maybe a new SOLID_ or MOVETYPE_ constant? Also, there'd have to be a way to check for engine support via QC, probably via the checkextension system (just checked - DP's DP_SV_ROTATINGBMODEL extension may be the one).

The other features you mentioned sound intriguing, but right now I'm really trying to resist the urge to add new stuff, and just finish what's there (not nearly as much fun...). I'll keep it in mind for the future though.

And you don't need to worry about me adding visual fluff - my GL skills are at about a 1997 level :). Plus, I like my Quake to look like Quake, dammit! 

mostly the reason i suggested that stuff was because i've yet to see it done so far.

once i got into creating things, i always felt the real impressive thing about doom3 was the script engine but i imagine it's probably many times more difficult to create something like that because it means creating a compiler and interpreting as well as making syntax or whatever that's intelligent. 

quake had quakec, which required a syntax, a compiler, and an interpreter, too :) 

the big difference here is that it's integrated into the engine and that a map doesn't need to be a mod to implement quite a range of custom scripted events.

but implementing it in a custom engine when no one else has done it (custom engine modifications for scripts) is sort of self defeating because although you may not need a mod to run it, now you need the engine. :S

i should have thought it through before mentioning it, hehe. :P 

Thinking about scripting and metlslime's post reminded me of an idea I posted to the Quoth 2 thread (post 347):

http://www.celephais.net/board/view_thread.php?id=60173&start=347

The examples I gave were silly one-step things, but what I envisioned was a chain of these "operation entities" used to perform a sequence of actions; in essence, a script!

Maybe add some conditional operations (if equal, if greater, etc.), and you'd have some rudimentary scripting ability. 

purely theoretical discussion at this point but:

what you're describing is essentially what any modder does every time they compile a progs.dat.
stuff like, for example in hipnotic with the sound playing entities or the lightning shooters.

scripting in doom3 renders all those things obsolete. you have your rudimentary entities like func_doors and trigger_multiples for stuff you reuse all the time, but if you wanted to make a lightning trap, you don't need to make a whole new entity.

it's maybe not a big distinction, but i never liked the huge amount of scripting 'entities' that you get in say, hl2. it's many times easier to plan and work on a complex scripted event when you have simple lines of code in front of you instead of 5 trigger relays and half a dozen doors and plats all connected together.

but as i think on it, i feel i'm probably in the minority here. a lot of new guys on doom3world never even touch scripting because it has a steep learning curve. 

necros

We evolved the UnrealEngine to use a visual scripting system, Kismet, because we were tired of trying to string together triggers and events for complicated stuff. It really is an archaic way to go these days and makes debugging and absolute nightmare. 

but the scripting did seem like the most interesting new thing to me as well 

*godly chorus sings*

i r wins 

i see how a visual language makes debugging much easier :) 

So occasionally the navigation of quake monsters is inadequate. Although they walk entirely blind, feeling their way along walls, usually they get blown to pieces too fast for the player to even care. As people who have read through the AI Cafe tutorials will know, the monsters can either walkmove() or movetogoal(). The latter function will hug walls and attempt to navigate a bit if an obstacle is hit. This does take a bit of control of the navigation away from you.

Walkmove is more of a direct command, to move in a direction, to a distance. When a monster is blocked while trying to walkmove, it is worth knowing two things:
1. The monster does not move at all, walkmove is all or nothing.
2. The walkmove function returns FALSE, instead of TRUE.
The return value of the function would be very handy, as if it returns false, your monster would know that it is blocked, and perhaps make a decision based on that (to try and jump, or hide, or strafe from side to side maybe).

The trap here is to go and write a function which replaces ai_run, the usual function which instructs a monster to move towards their enemy. The problem being that ai_run does a lot of other important things for a monster - checking that the enemy is dead, or whether they should start attacking, and so on. You might end up copying the entire function apart from the last line, which you change to the new walkmove code (and reaction to it returning FALSE).

Then if you change ai_run in the future, you need to remember to change your copy of it too. And duplicating code is pretty wasteful too. You might try and refactor ai_run to let you choose the navigation after, but doing that is a lot of fuss.

So a fairly neat solution came to me yesterday, which is why I wrote this whole thing up. Just write a basic function which will move in the correct direction, check the return value, and react if you are stuck. It does not need to replicate the other functions of ai_run(). Then the key trick is to call it from only one of the running frames of your monster. The rest of the frames should all call ai_run() like usual. Every 6 or 8 frames your monster thinks about something else, and the rest of the time it's business as usual.

If you really wanted, you could call ai_run() and your new function from the same frame, splitting the distance to travel between them. If so, think carefully about which function you want to override which. If you would prefer for your monster to attack as normal, put the call to ai_run() last, and vice-versa.

Okay, all told. 

I ran into this exact situation last night. My solution was to call ai_run(0) every frame, and then call my_walkmove() every frame to do the actual movement. 

Glad to see I'm at least thinking about problems people care about, even if it's too late to be useful : - p 

Gets cogs turning.

Ways to get the fiends more agile. 

there is something maybe you can help with... is there any way to prevent flying enemies from sometimes going inside solid walls? 

If someone could reliably reproduce it, with a testmap and a 20% or so success rate, then it would be helpful. I'm sure it's just a check that isn't done carefully enough - and it should be really easy to spot because of the isolated nature of the code for flyers. It is something that I've wanted to crack, but I don't know yet... 

Its to do with navigation by point as opposed to bbox - but flyers and swimmers aren't stuck to the floor in order to move.

Points to a coding can of worms though, if it is that. 

i might, i'm currently testing a flying monster in a room with a large crate in the middle. There was at least one test session where they consistently worked themselves inside the crate, while testing on nightmare mode.

This monster has a custom move function which calls walkmove() and if that returns false, calls movetogoal(). In order to control their vertical movement, I give them a self.enemy that is either 1000 units above them, or 1000 units below them (otherwise they will always seek the same horizontal plane as the player and stay there, which i don't think is very interesting for a flying opponent.)

Anyway, if i can get a reproducible case, I'll let you know. 

it's not possible to detect if the player is pressing movement buttons is it?

something that would be true if he wasn't pushing any buttons but he was sliding down a slope, for example. 

i may not need to worry about this after all, i just found out the player's velocity is considered 0 when standing on a platform or whatever and it's moving you. 

Is this is the for the same mod where you wanted to create a chasecam? If so, the usual trick is to proxy the player. To do this the actual player entity an invisible movetype_noclip entity, and in playerpostthink, keep resetting the origin to that of the camera entity(to prevent visibility problems). Then through reading the offsets of this dummy player, you should be able to deduce the key presses.

This assumes that you have an entity set up as the chasecam viewpoint, and that you're willing to make a 3rd entity which serves as the visible player. But that is usually acceptable for the kind of mod where you'd want to read the inputs.