Looks Cool :)
Yeah if there was a stamina thing it would make it quite a cool little upgrade in normal Quake for low ammo type maps. Why not just display your blocking stamina on the weapon's ammo counter? I suppose that wouldn't be great if you plan on including Hexen style weapons that are melee but use mana :E
Also would be cool if the sound of actually hitting something was more meaty. Also would be fairly entertaining if strong strikes would gib. Feedback is the best thing about the Half-Life crowbar and such :)
---
Video of my own, playing with video uploading, this time it's a better resolution. I knew the video was too dark but didn't realise it would fuck up the compression, but anyway hope you can see what's happening. It's fairly obvious I think.
http://www.youtube.com/watch?v=6eg97zrg-Uw
Hmmm.
#7324 posted by Shambler on 2011/01/31 17:36:07
I tried to add &r_fullbright=1 onto the end of that link, but it didn't help. From what I could hear, it needs more Vorelings...
Necros FFS
#7326 posted by negke on 2011/01/31 18:36:26
I expect your cath/dragon/oblivion episode yesterday!
Please don't give up on that Doom 2 map, either. It's practically finished minus a few details.
#7327 posted by necros on 2011/01/31 21:22:24
with all the qexpo talk lately, i'm holding off to see what happens. it'd be pretty cool to release everything over the course of qexpo.
Btw
#7328 posted by negke on 2011/01/31 23:33:55
Are those custom realistic door swing physics?
#7329 posted by Zwiffle on 2011/01/31 23:39:20
If there were a QExpo this year, I would work to finish my Quake map by then. It would be a quick, tiny map but at least I would finish it.
#7330 posted by necros on 2011/01/31 23:46:24
Are those custom realistic door swing physics?
yep! :D i'm pretty proud of them. both players and monsters can push them and they emit sound depending on speed. i'm thinking of adding random sway for wind effects, but angle precision is too low for that kind of thing unless you use DP.
Cool
#7331 posted by negke on 2011/01/31 23:57:14
That's the saloon variety. Now add a use (grab) mechanic.
Huh
#7332 posted by necros on 2011/02/01 00:14:06
i don't know if that's fully possible without engine extensions.
you could haxor in a use key, but it wouldn't be perfect.
i suppose you could make the 'fire' button contextual for swinging doors, but that risks getting in the way of shooting.
Swinging Door ?
#7333 posted by delor on 2011/02/01 00:22:38
nice! I'd need them for a saloon in a western mod I was planning but aborted.
So how can I obtain that effect ?
#7334 posted by necros on 2011/02/01 01:27:02
it's not overly complex, actually. i was surprised no one had done it before when i realized that.
you basically reverse the functionality of the func_movewalls and func_rotate_door.
drop the func_rotate_door into an endless loop and then set movewalls to use a touch function that sends the player's velocity to the rotate_door. from there, use dot product to figure out how fast to move based on angle of door.
there might be a smarter way to do this actually. calling the rotation code directly from the touch function for the first time or something instead of just leaving the door looping all the time, even if it's not moving.
for monsters, it's a little trickier. they will never proc a touch function on a solid_bsp like movewalls because movetogoal and walkmove will detect if it *would* hit, and just not let it.
luckily, the rotate_object has a nice bounding box sized to cover the entire area that it will rotate (i think that's done automatically by qbsp?).
so you give a touch function for the rotate_object and then use this math: http://mathforum.org/library/drmath/view/54823.html to figure out if the monster is 'touching' the door or not. from there, it's a simple matter of deciding which way to push the door based on monster position.
Necros
#7335 posted by Tronyn on 2011/02/01 07:17:59
cool video, I liked the block function as well. nice looking map, good atmosphere with the storm and creaking doors, good combat.
Dudes
Don't use that "math" to figure out if a point is in a rectangle (or bounding box). It's slow and awkward compared to the simple solution, which is to check if each point coordinate is within the min and max vectors of the bbox.
Also, for checking whether a point is within a polygon, I prefer the "shoot ray from polygon and see how many polygon segments it hits" method because it is not computationally heavier, it is simpler and it deals with non-convex polygons as well. This method is esp. simple if you translate your polygon by the negative point (which then becomes the origin) and check whether the polygon becomes the origin.
To do this in 3D, project onto one of the coordinate planes (preferrably the plane where the projected polygon has the largest area).
Err
becomes == contains
Stairs Clip
#7338 posted by ShadoW on 2011/02/01 09:36:20
Guys, should I turn all my stairs into func_wall, and cover them with clip ramps? I mean, is there any reason I shouldn't do that? I think it would be better to exclude stairs from mesh merging process, as they bring a lot of unnecessary splits. And in case I can do that - ramps or rather stairs shaped clip?
I Would'nt Do That
#7339 posted by RickyT33 on 2011/02/01 10:58:16
I dont think it's common practise. One of the querks of Quake is the ramp-jumping effect (if you jump whilst running up a ramp you will fly quite far), and doing what you describe will not reduce the complexity of the mesh that much, and the behaviour of the stairs will be weird.
Players are used to looking at stairs and knowing that you can't ramp-jump up them.
All of the vertexes of the bmodel stairs will still be counted towards your vertex limits (and some marksurfaces). You wont's save many polys.
You're All Invited To ..
#7340 posted by delor3 on 2011/02/01 20:16:42
I Would Spend A Bit More Time Putting
#7341 posted by RickyT33 on 2011/02/01 21:11:15
some shading on the skins
Sleep
#7342 posted by necros on 2011/02/01 21:29:12
Don't use that "math" to figure out if a point is in a rectangle (or bounding box). It's slow and awkward compared to the simple solution, which is to check if each point coordinate is within the min and max vectors of the bbox.
you can't. first because as the door rotates, the bounding box's accuracy varies from completely so to completely not. you have to continually check from a rotated box, not a static one. if you could just use the bbox, then you could simply set it to a touch function and leave it at that.
on top of that, since we're using the rotate_object as the trigger field, modifying the bbox would change the way the rotating brush is displayed. qbsp seems to create it with a bbox that is larger than the bmodel itself. it seems to make it as large as the bmodel would be if it was rotated 360 all at once from it's origin entity.
Also, for checking whether a point is within a polygon, I prefer the "shoot ray from polygon and see how many polygon segments it hits" method because it is not computationally heavier, it is simpler and it deals with non-convex polygons as well. This method is esp. simple if you translate your polygon by the negative point (which then becomes the origin) and check whether the polygon becomes the origin.
To do this in 3D, project onto one of the coordinate planes (preferrably the plane where the projected polygon has the largest area).
i didn't understand what you mean here. anyway, the check i use is not 3d. the pushable doors only work for y axis doors and have seperate code from x and z axis rotation. (or they would if i needed that and bothered coding it).
doing it in 2d is pretty quick, just a few subtractions and a division. also, i have no idea how to do it in 3d.
Ah I See
In that case, your method is in fact better (and faster).
Thanks :)
#7344 posted by necros on 2011/02/01 22:41:07
it totally is a case of hackery such that it only works in one specific way. i'm not smart enough to generalize it to work for all cases. ^_^;
I Know Rickt23..but
#7345 posted by delor on 2011/02/02 05:00:34
the essence I want to achieve in all my mods is sort of cartoonish style so when I reach a certain level of detail previously planned I stop.
this is my method of mapping or else you could never get any map finished!
..hmm actually I never published anything til now :)
Deep Scars Beta2
#7346 posted by ShadoW on 2011/02/02 09:18:41
Hi. Second beta of my Deep Scars map. It's suppose to be RC now, meaning there are clips, item layout should be final, ligting and textures were fixed in few places and so on. Will appreciate any feedback :).
http://dl.dropbox.com/u/16372046/q1shw2_b2.zip
#7347 posted by negke on 2011/02/02 13:22:50
Check the skull textures. Some of them are cut off in the middle. The stretched textures on all all 45 degree walls look bad. I don't like the base floor textures here; the grey/blue one was better (contrast). There's also another 4*4 tile floor texture in brown.
One thing you got to keep in mind when using 32 unit tiles on the floor is to make sure the dimensions are right on every floor, otherwise they'll be cut off which looks wrong. An example for this is the floor under the GL. However, this can be easily fixed by making the edge trim 32 units wide and replacing the upper texture with metal4_4.
Also note that metal4_4 has distinct seams on each side - this means it has to rotated according to the adjacent brushes.
There's a rogue space behind a brick recess near the lower RL.
The stairs look a bit out of place. They were okay in the first map, but not so much here. Maybe change the texture, or put 16-wide ramps on each side of them.
I think there is too much health. Or at least too unevenly distributed. Quite a few spots that have 2*25 medkits but are also in relatively close proximity to more medkits. Maybe one of the large health boxes from the lower floor up to the LG, and the other ones a bit more spread out, or something.
|