quakec input .....

Talk about Quake, Doom, Wolfenstein 3D, or other DC first person shooting game ports and mods for those games in here.
Post Reply
.:ajay:.
Old Git
Old Git
Posts: 56
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Thu Nov 08, 2001 11:46 am
Has thanked: 0
Been thanked: 0

quakec input .....

Post by .:ajay:. »

I've hit an unexpected problem :? , well unexpected due to my lack of knowledge anyway, with my new quake project.
I've posted over at Inside3d.com, as they more often than not will know the answer, but I thought that asking here as well would be useful :)

Anyway here's the problem:
I'm trying to get a particular monster (e.g. ogre) to walk through walls and through the player, I've tried adding the following;

self.solid = SOLID_NOT;
self.movetype = MOVETYPE_NOCLIP;

in ogre.qc, which has acheived my first aim of the player being able to walk through it and shoot through it, but it still turns away from the player and won't follow a path thru' a wall.
It already otherwise "ignores" the player (as in doesn't react to, either when attacked or when the player comes in view) , thru ammendemnets to float() FindTarget in ai.qc, but there still appears to be a recognition of the player elsewhere. Also, although theoretically the movetype_noclip should allow it to pass through a wall, it turns before doing so.
I'm kind of concerned that the code for stopping monsters from touching walls or the player is in the engine rather than quakec, which, of course, would fairly bork this idea in terms of a DcQuake mod.
In terms of priorities, it's more important to me to get it walking through walls, than it is for it to "agree" to walk through the player.
Any pointers/ideas?
cheers

ajay
TheDumbAss
QuakeDev Mod
QuakeDev Mod
Posts: 1233
Joined: Wed Oct 17, 2001 7:44 pm
Location: Indpls, IN USA
Has thanked: 0
Been thanked: 0
Contact:

Post by TheDumbAss »

It may not be exactly what you want to here... but Yes Monster movement ( movetogoal() ) is done in the engine. So of course wether you have it able to clip or not... it will KNOW the wall is there and not walk through it.

I'm not sure but I think you could use func_wall and have the 'thing' walk through it since it's not a real wall... but instead considered a bmodel. (it also would add to the entity count and wouldnt render the shadows or lighting propperly in QuakeDC but would look right in some of the advanced GLquake engines)

Another option is to throw away all use of the original monster movement code. A good place to look for for that is the AI cafe. ( http://www.planetquake.com/minion/ )In particular Im talking about Coffie's Tutorbot and it's accompaning tutorials. In its stock form it uses the monster movement code plus some custom code called coffee move... but the tutorials explain a couple other movement types. (his walk_move() navigation may be exactly what you need) Basicly you'll want to get rid of all use of movetogoal()... by useing tutorbot's coffee_move() and/or his walk_move()

(Tutorbot is crappy as a bot... but is a good base for 100% custom monsters...)

As for how to get the monster to completely ignore the player... I can't remember the exact details... but I did that with tutorbot for the moving targets for my never to be finished Metal Gear VRmissions mod. I think I simply commented or removed all its enemy/target checking. I mean I could walk up and shoot them and they would still ignore me completely. But I dont think they would have fallowed path_corners or waypoints without putting some of the target checking code back in. I can look and see if I can find my 'movetarg.qc' if you need me to... but Im not sure how clean or useful the actual code would be to you. (they were also uneffected by 'gravity')

If you can get on IRC you may want to go to #qc on irc.innergamer.net or irc.gamesnet.net (channels are linked if you enter the appropriate /ctcp in MIRC) FrikaC is there often. Others knowledgeable in QC hang out there as well. (just mentioning it incase you didnt know about it yet)
I'm sure if I screwed anything up... suggested something bad... or if you simply want a second opinion before trying my suggestions then they're you best (and quickest) source for QC help.

I think I know what your trying to do... Sounds Cool. An idea to make it more ghostlike would be to make it have the model disappear (go to a blank model or sprite) and reappear every other think. (would flicker and MAYBE simulate transparency... kinda like the motion_blur tutorial I'd seen simulates a blur by drawing extra models where the player was (approx) .02 seconds ago) You'd have to try for yourself and see if the results are good enough for your taste... (expecially on QuakeDC with its poor intrapolation) In certain custom (PC) engines you can set an alpha value for the models... makeing them simi transparent.
.:ajay:.
Old Git
Old Git
Posts: 56
Joined: Thu Nov 08, 2001 11:46 am
Has thanked: 0
Been thanked: 0

Post by .:ajay:. »

Thnx m8,

I've got it ignoring the player fine, in terms of not attacking or respodning when attacked;
In float() FindTarget in ai.qc, I've just added

if (self.classname == "monster_ogre")
return FALSE;


That adds a NOTARGET kind of response, then, as they're NON_SOLID, they don't "notice" when attacked so that makes them pretty oblivious to everything :) They still follow a path, unless it's through a damn wall........

They still however refuse to actually walk through the player, so on some, probably engine, level, they are identifying the player. If I can get the thru'-wall-walking thing sorted, I can live with them going round, or turning away from, the player

You're idea to get them "flickering" sounds excellent; at the moment I've just imported a greyscale skin, but that and the model (the ogre is a temporary choice) are subject to change.

I'm studying Coffee's work as I type, I haven't fully understood it yet :oops: but I'm getting there....
TheDumbAss
QuakeDev Mod
QuakeDev Mod
Posts: 1233
Joined: Wed Oct 17, 2001 7:44 pm
Location: Indpls, IN USA
Has thanked: 0
Been thanked: 0
Contact:

Post by TheDumbAss »

Glad to help...

As you'll see in the tutor bot tutorials there is a waypoint system there... You can use that to replace path_corner if you like. (Think you'd have to if you use tutorbot)

The walk_move (as the tutorial says) 'pushes' the entity in whatever direction specified. You should be able to 'push' it into/through whatever you want since it shouldnt be calling ANY of the engine coded (or other) AI (like movetogoal) I'd think since you pretty much point it and it goes... it doesnt care what is in front of it... it just trys to go. (My old tutorbot would run straight into me and keep trying to go... but couldnt because I was in the way) Useing it (slightly modified) you should be able to push things through the ceiling and floor as well. (imagine a ghost floating up from below... ) Of course it can be combined with the waypoint navigation... so it does whatever it can to get from point a to b to c. (hopefully even walk through stuff with the solid_not and movetype_noclip... heh)

Something else about those tutorials... A lot of the code is rather modular. So you can just use the parts you want... then replace the calls in the monster your changine with the new ones... (Like replacing movetogoal(); with walk_move();) That way you can continue to use your modified ogre.qc instead of starting all over and redoing tutorbot instead.

Something I did while messing with tutorbot was I had multiple versions of him in the code... (tutorbot.qc, dumbbot.qc, ssoldier.qc, etc) and changed the classname for all but the original to something new. (bot, dumb, sarmy, etc) I just had to make the appropriate additions to everyplace it had something like if (blah.classname == "bot"). I didnt make extra impluses to call the additional versions... but instead adjusted the spawn function to work at worldspawn when loading my test maps. (Proper entitys spawn placements were added to the maps)


Errr.... something I just thought of... are you putting some of the path_corner outside of the level? I mean out in the 'void'? If so then its possible the reason the ogre wont fallow the path through the wall because the path_corners in the 'void' are dropped while compiling the level or at worldspawn. If thats what your doing you might want to put a small box around the path_corner (avoiding leaks into the box) so that the path_corner isn't really in the 'void' anymore. Not sure that would be a problem... but It would be a good idea anyway. (No entity blah spawned outside of level at 0'0'0' blah blah blah removed... [sorry forget the exact error])
User avatar
mankrip
DCEmu Ex-Mod
DCEmu Ex-Mod
Posts: 3712
Joined: Sun Nov 04, 2001 5:12 pm
Has thanked: 0
Been thanked: 0
Contact:

Post by mankrip »

Maybe you can use entity.velocity and entity.angles to make it go in the direction you want, like a missile...

And TDA, are you sure that QuakeDC don't have models transparency? I've heard that the rings transparency in SlowMo works in QuakeDC.
TheDumbAss
QuakeDev Mod
QuakeDev Mod
Posts: 1233
Joined: Wed Oct 17, 2001 7:44 pm
Location: Indpls, IN USA
Has thanked: 0
Been thanked: 0
Contact:

Post by TheDumbAss »

walk_move is a less direct way to control entity.velocity and entity.angles Ajay should have less work to do if he wants somewhat free roaming entities (or ones that fallow paths).

If he does want to do an individual entity and code that it moves X units a Y angle at a velocity of X then after moving that number units changes its entity.angle to B and moves C units at D velocity he could... but if he has 5 in a room and each needs to move differantly then each would have to be coded seperatly. No AI involved... No targeting, Nothing. BUT doing it this way would pretty much insure that everytime you see that entity it will be doing exactly that same thing. (should be able to push through walls and other entitys as well... given SOLID_NOT) Should be the same under any engine on any system.

Fraggers method would be cleaner to code (to a point) if there are very few needed in the mod and movement is minimal (and possibly triggered to go once only... once out of view... info_null )

My ideas and explanations are more generic and for general perpose. If he just wants/needs the entity to do a few spacific movements then I think Fragger's idea would be better.

hmm.... just thought of something... a func_train goes through walls (and eachother)... and doesnt react to its enviornment. It could be made SOLID_NOT too I'm pretty sure... (though that would not be a good idea for func_trains hehe) Maybe a look at that code might help you Ajay.

I dont know about slowmo's simi-transparent bullet rings. Ajay would though... since he's who tested (I think he was the first to).
User avatar
mankrip
DCEmu Ex-Mod
DCEmu Ex-Mod
Posts: 3712
Joined: Sun Nov 04, 2001 5:12 pm
Has thanked: 0
Been thanked: 0
Contact:

Post by mankrip »

I've tested SlowMo right now, and model transparency really not works. The bullet rings are all black all the time. Surely another bug due to the quick porting done by Titanium guys... well, a buggy QuakeDC is better than none.
TheDumbAss
QuakeDev Mod
QuakeDev Mod
Posts: 1233
Joined: Wed Oct 17, 2001 7:44 pm
Location: Indpls, IN USA
Has thanked: 0
Been thanked: 0
Contact:

Post by TheDumbAss »

I'll have to agree... buggy is better than none!

Not sure why the rings would have black textures... seems odd such a small simple model would have problems. Aww well.
My old Sig was broken. Enter the new Sig!
Post Reply