 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Nice, I'd really like to see some larger monsters or bosses/minibosses (that can actually move) in quake. This could be a piece of that puzzle.
yeah, works pretty decent, but of course it imposes some limitations.
you need to 'clip' any area where the monster will be, of course, and that means you have to visualize the hull expansion yourself and implement it. also, currently how i do it is to use the same method that hipnotic did for the func_togglewall and that is to just add '8000 8000 8000' to the origin when you want to turn it off, and then subtract the same vector when you want it on. i don't know how big a deal it is if you had a generic monsterclip entity that EVERY monster in the map would have to toggle back and forth every animation frame. that could be pretty brutal. it's probably better to somehow localize monster clips so only the monsters most likely to actually touch them will be toggling them (hence why i opted for a clipModel->targetname method instead of just putting it in walkmove and movetogoal). (large bbox monsters use a special wrapper for ai_walk and ai_run). quake seems to use start the hull2 bbox from the bottom left (mins) of the monster.
this means that if you use a bbox of size (for example) '-128 -128 -24' - '128 128 64' only the mins up to '-64 -64 64' is used when checking collision. i thought that quake would start the hull2 size from the center of the monster, but this is not the case. this creates a problem now because collision is still messed up. if we resize the monster to hull2, call movetogoal and resize back to the new hull size, collision against the world (and func_clipModels) is fine, but the monster is now able to walk inside the player and other monsters. i'll have to put more thought into this, i guess... Wait, how do shub and chthon work? They have large (stationery) bboxes and players seem to collide against them correctly.
yeah, the collision of other bboxes is fine.
it's the collision against the world that is messed up. and that's the big problem: movetogoal will function correctly vs other bboxes if you set the bbox correctly. 256x256x128 or whatever. movetogoal will function incorrectly vs world when bbox is set to 256x256x128. if you set bbox to standard hull2 size before movetogoal and reset to 256x256x128 after, monster will move inside player. what i've done so far is left the bbox at 256x256x128 and simply 'offset' the func_clipModel so that sides that the mins hits are smaller than sides that the maxs hits. kind of hard to explain, when i figure everything out, i'll probably make a blog post about it with pictures to explain it properly. also, another interesting (and annoying) side effect: because of the way the standard ai_run code is sandwiched between func_clipModel toggles such that the clipModel is active when ai_run is called, things like the visible() function fail if the player is inside the clipModel since visible uses a traceline to determine if the monster can see it (and since the clipModel is solid during that period, the trace hits the clipModel and determines the player is not visible). another way to look at it is this:
for the purpose of bbox vs world, only the first hull2 coordinates starting at the mins are solid. that is to say: if the bbox was mins: -128 -128 -24, maxs: 128 128 64 world collision is done from -128 -128 -24 to -64 -64 64 (mins + VEC_HULL2_SIZE) because VEC_HULL2_SIZE = 64 64 88 if you set the bbox down to standard hull2 size, it's collision against other entities is wrong. If you leave the bbox alone, its collision box is offset from the correct location.
Two ideas: 1. before moving the oversized entity, make ALL other solid entities (or at least all entities within a findradius) larger by XYZ amount, to compensate. 2. have two entities, one oversize and one normal size, and move them both. If either one is blocked, set both entities to the location of the blocked entity. Not sure if either of these are completely workable. 1. could work, except it's just (potentially) a lot of entities to enlarge.
2. this is better, but the problem is that if one is blocked, and we reset the position, nothing happens for that frame and likely movetogoal will try the same thing next frame. currently what i've done is use bboxes on all the func_clipModels. this means each brush needs to be a seperate entity and we can't have sloped/angled faces anymore (since everything is just a box now). it works and doesn't seem too slow, but we loose a bit of brush flexibility since we can't have any angles any more. of course, you're really just blocking out the area, so this could actually work. i'll leave it this way for now and test it out for now. http://necros.quaddicted.com/temp/dragon.jpg
the collision stuff has been working well without any further problems so far. the really nice thing about it is that for monstrously large monsters like the dragon in that shot where you don't necessarily want the bbox to completely cover the entire model, all you have to do is expand the clipModel entities out further from the actual walls. So I've just spent about a month without internet at home, shame I missed all that stuff about large bboxes, because that's a cool idea. If you're doing a landbound monster with a tall box, then you can create maps which can be bbox-blocked with greater ease. Low walls rarely need to be boxed in this case, just obstructions which are above the head height of regular sized entities but low enough for "the boss" to collide with.
Anyway, that's a digression. In my time away, I had lots of time to get on and finish projects. A fair few of them were quake related, and I'm posting the first one now. It's the tutorial I mentioned a dozen posts up about accelerating MOVETYPE_PUSH objects. Since it involves some formulae which I've done up in LaTeX and a few graphs, I've made a web page for it rather than just copy-paste it straight onto func. Accelerating pushers Also means I can fix typos and other problems, so post them here! i haven't really read your above post yet as accelerating movers isn't a pressing issue anymore, but i just wanted to mention: you should compile all your coding tips you've made in this thread and put them up on a site somewhere. some of them are quite useful and others are downright golden.
I have created a 'trigger' entity. It covers a large portion of the map and instigates certain continuous but randomly timed actions whilst the player is inside the trigger's area. Let's call it an area_trigger.
The events are called by using the trigger's touch function, as in self.touch=do_these_things, so that when the player leaves the area, do_these_things no longer gets called. If he re-enters, the events start again. So far, so good. I now want to 'enhance' this effect so that when the player leaves the area, a separate single event takes place, and this event takes place each and any time he leaves the area, which could be one or more times throughout the game. This event must not take place at any other time. Is there a way to read when the player stops 'touching' the trigger so that I can call this exit event. I maybe could set up multiple triggers around the area_trigger and have them switched on by the area_trigger so that the call to the exit event is operated on a one-way basis but I am hoping there is an easier way. Any views from the coding gurus? A better solution is to have triggers at the entrances to the area. Two in fact, separated a little. The inside one calls the enter function, the outside one calls the exit function. The functions are coded so that they only actually do something on a state change.
actually, it is easy.
on your trigger_area touch function: self.nextthink = time + 0.1; self.think = DO_THIS_WHEN_PLAYER_LEAVES; since touch is called every frame, nextthink will always be set higher than time, so also, since i believe first: i forgot to mention in your
if your trigger_area already needs to have a nextthink and think set for whatever reason, just spawn in a relay entity and do the trick on that entity instead: if (self.owner == world) { self.owner = spawn(); self.owner.owner = self; } self.owner.nextthink = time + 0.1; self.owner.think = DO_THIS_WHEN_PLAYER_LEAVES; then: void() DO_THIS_WHEN_PLAYER_LEAVES = { self.owner = world; //break link with the relay entity and the trigger self.nextthink = time + 0.1; self.think = SUB_Remove; //delay remove }; we set up void() DO_THIS_WHEN_PLAYER_LEAVES =
{ self.owner.owner = world; //break link with the relay entity and the trigger self.nextthink = time + 0.1; self.think = SUB_Remove; //delay remove }; otherwise your only erasing self's owner (the relay entity) and not the Because when you're in a trigger, I don't think the touch function is called every frame.
If that is a problem(it certainly would be if you need to detect monsters)can use force_retouch to help you out there. The simplest way would be to set force_retouch = 2 in the touch function as soon as you've touched the trigger. This would end up polling the heck out of all the triggers in your map while someone touched the middle one, but it would fix that problem.
I think the above is the only way to make the trigger responsive within a single frame (assuming you shrink the nextthink time lots). If you're willing to have your trigger less responsive (a minimum of two frames, but the values we pick here will be 0.2 seconds) then we can end up only using force_retouch once in 0.2 seconds. We need the trigger_detector to have three states: STATE_EMPTY: no player inside STATE_READY: detected a player recently STATE_POLLING: checking if there is still a player If a player comes into an empty trigger we go from STATE_EMPTY to STATE_READY and wait for 0.1 seconds. After that time expires we go into STATE_POLLING for 0.1 seconds. If a player touches the trigger within that 0.1 seconds, we go back to STATE_READY, otherwise we go to STATE_EMPTY (and trigger the leaving event). We don't actually need to explicitly track these states, they are just to understand what is going on. We have a think function called trigger_detect_startpolling along the lines of self.nextthink = time + 0.1; self.think = trigger_detect_fire; force_retouch = 2; When our Finally to hook all of this up, we need the touch function to set self.nextthink = time + 0.1; self.think = trigger_detect_startpolling; which both moves us from STATE_EMPTY to STATE_READY when the player first touches, and back from STATE_POLLING to STATE_READY when the player retouches. On another topic, force_retouch has an important effect on touch/think order which I hadn't considered before. When set, players will touch things they are in contact with before their think functions run (and then possibly touch things AGAIN after physics has run). So anyone who was intending to exploit the order that functions run had better be careful. Also, I'm gonna go see if things really can run touches multiple times in a single frame. If that is the case, then it really will be important to make touch functions idempotent. This is a wonderful term from mathematics for a function which doesn't do anything else when you keep applying it to it's output. For example rint(x) is idempotent - once you get a whole number out, applying rint to that whole number just gives you the same whole number. I'm using idempotent in a slightly weird sense here, the idea being that one of the parameters to our touch function is the value of "time", the frame that we are in. Most of the original touch functions have if(self.nextthink > time) type guards in place to achieve this, but it's something important to think about if you're writing a trigger which can be touched every frame - does it matter if you trigger it many times a frame? i don't know why it has to be so complicated, preach... it works fine the way i said. :P no need for force_retouch or anything.
It's needed in the case of non-player entities which don't link to the world unless they move. If you were trying to detect a monster, you would need the force_retouch. It is more than what mike asked for though, the simple suffices there...
are there any differences in how these three work?
ie: is findradius really just doing nextent(e) if (distance of e < dist), add to or is it faster? for example, if i did a findradius(org, 64) where i'm checking only a small radius, is it faster than if i findradius(org, 1024) or is it the same speed? and if smaller radii are faster than larger ones, at what point does it become better to use nextent rather than a large findradius? i guess that kind of thing would also depend on the total # of entities as well...
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |