#10255 posted by negke on 2010/09/23 20:04:35
Sounds more like a func_ without a brush. To be safe, load the map in Bengt Jardrup's enhanced Glquake in developer mode - if there are rogue entities, it will show a console warning.
Big Monsters Won't Teleport
#10256 posted by Rick on 2010/09/23 21:10:41
Sometime ago I found some weirdness in Quake. I could push entities, such as ammo and medkits, through solid walls using doors. Well, now I've found another. I'm trying to lower monsters on a door through a trigger_teleport. It works fine for the smaller ones (knight, hellknight, scrag), but the bigger ones (ogre, fiend, vore) don't work. When they hit the trigger they immediately flip from 0 to 270 degrees, the teleport particle effect fires, then the monster dies. It plays the damage sounds like they're getting crushed. Weird.
I'm using Fitzquake 0.85, but it also happens in GLQuake (the one modified by Bengt Jardrup)
I guess I'll try pushing them through sideways.
Megalodon
#10257 posted by madfox on 2010/09/23 21:21:44
sorry, I update it.
^v^
#10258 posted by necros on 2010/09/23 23:13:23
that's odd, but why not just delay trigger the teleporter instead of lowering it through a normal teleporter? would avoid having to use a door entirely.
Got It Working Finally...
#10259 posted by Rick on 2010/09/24 00:05:14
The idea was to have monsters flying out of a teleporter one after another, multiple monsters using the same teleport destination.
I tried pushing them through (well, sliding through on top of a sideways moving door) but I got the same result (again, only with the larger monsters). Interesting discovery was that scrags wouldn't ride the slide walk and the next monster in line wouldn't push the scrag. When the door eventually moved out from under that monster, it fell to the floor. That monster happened to be an Ogre and by pure luck I happened to have a copy of the trigger_teleport down on the floor, and lo and behold Mr. Ogre ported. So that was the solution to the problem.
With the teleporter on the floor, I just lined the monsters up on top of the door in the order I wanted them to port in and everything works. The monsters begin bunching up against the wall as the door slides out of their holding room and as the door moves out from under them they begin dropping into the teleporter, one by one.
You can control the rate they port in by changing the speed of the door. They will however telefrag each other, the assumption is they will be immediately moving after the player and get out of the way of the next monster. I put a trigger_monsterjump at the teleport destination, just to help them along :)
The only problem would be with scrags, since they won't fall. If I decide to keep them I think I could just add a little pusher bar to the door and arrange them their own trigger_teleport.
Pretty nifty little construction I think.
One of the reasons I'm really enjoying using Quoth is that it is very easy to recreate Doom style monster zergs. Because it can easily spawn monsters active in a far off box, they will automatically run toward the player. Put a teleporter on the wall facing where the player would be, and doors or forcefields between the ranks of monsters that block their progress. If you make the teleporter the height of the wall, flying enemies should also go through.
Quoth also allows you to flag teleporters as preventing telefragging, so they might bounce around on the teleporter trigger for a while but they won't just gib each other :)
Have You Tried The Func_hoardspawn?
#10261 posted by RickyT33 on 2010/09/24 12:46:11
Thats a great entity for "teleporting" a bunch of enemies into your map :)
I think the (now pretty dodgy looking) fgd I have doesn't include the hordespawn. It has a 'groupspawn' I think, but I tried it and didn't do anything.
Not particularly fussed though really. And seeing the ranks of enemies lined up is kind of fun :)
Anyone Got A Copy Of A Good .fgd
#10263 posted by RickyT33 on 2010/09/24 15:08:46
for Quoth 2.1? I found preach's one here:
http://www.btinternet.com/~chapterhonour/quoth2.fgd
But it doesn't contain func_hordespawn.
But It Doesn't Contain Func_hordespawn.
#10264 posted by spy on 2010/09/24 21:44:54
why do you need a func_hordespawn???
just leave it alone......
@ MadFox
#10265 posted by megalodon on 2010/09/24 22:47:17
Thanks. Yes, that's a way to do it. Perhaps I misunderstood the BSP tutorial, but I thought the idea was to use the sky texture on the brush that is supposed to cast the shadow.
But this is a cool effect nevertheless. I'll keep it in mind.
Func_hordespawn
#10266 posted by necros on 2010/09/25 00:50:01
is less useful in quoth2 as preach broke the code that makes monsters wake up (the trigger_awake spawnflag is equally broken).
so when you use them, the first monster spawns but subsequent ones won't until the first monster is awakened by sight.
this is why the hknights that spawn in the end battle of ne_tower spawn on a little pad outside.
they originally were supposed to spawn inside the tower that the walkway connects to and run out chasing after the player. the idea would be that you'd never see where they came from, as if they were just charging out of the tower instead of teleporting in.
To Be Fair,
#10267 posted by necros on 2010/09/25 00:50:52
i don't blame preach for either accidentally or intentionally breaking the monster wakeup code as the implementation in quoth was very very bad.
Megalodon:
#10268 posted by metlslime on 2010/09/25 02:00:15
in e1m5, i think there's a "Q" made out of solid brushes, inside a sky brush. The sky doesn't block light, but it does prevent you from seeing the Q shape in the air.
Func_hordespawn
#10269 posted by Preach on 2010/09/25 03:01:56
The func_hordespawn doesn't appear in the fgd because it's been "rebranded". Because it's a point trigger, not a brush, the official name for it now is the info_groupspawn. The func_hordespawn name still works for legacy maps.
And yeah, I broke the awake monster code, so sorry about that again!
Quoth Sauce?
#10270 posted by jt_ on 2010/09/25 06:01:38
Any chance of a release of the quoth sources?
:D
Hehe
#10271 posted by necros on 2010/09/25 06:03:22
i remember arguing over that with kell.
his reasoning was that infos are point entities and func_s are brush models.
my reasoning was that funcs accomplish a function (ie: do something) where infos are merely for positions and such (player starts and teledests and all that).
:P
Where Is Kell?
#10272 posted by generic on 2010/09/25 14:00:55
I miss him.
Jpl
#10273 posted by madfox on 2010/09/25 17:52:06
There 's a copy of the quoth.qc on my harddrive.
I'm not sure if it is what you search,
only that I agreed to not share it on third parties.
It's from 2005, when quoth was released.
#10274 posted by necros on 2010/09/25 22:09:38
madfox is talking about http://qexpo2005.quakedev.com/booths.php?tag=necros which is the Lost Chapters source code. it contains (iirc) the drole (pre-nerf), flying polyp, night gaunt, voreling and the vermis as well as some other sundry code such as spawning.
i would recommend not basing a mod off that source as my coding was extremely shoddy in those days. it still is, in some ways... -_-
it's really rather embarrassing, especially when we've got some professionals running around here.
MadFox
#10275 posted by JPL on 2010/09/25 23:42:59
I'm sorry but I never asked about Quoth sources... I guess you are not addressing this post to the correct guy (who's name is jt_).. I guess you misread :P
Anyway, thanks a lot for the support to my "incomplete clone" ;)
Madfox
#10276 posted by jt_ on 2010/09/26 01:10:46
That's too bad.
Lost
#10277 posted by madfox on 2010/09/26 02:53:15
my specs..,
#10278 posted by necros on 2010/09/27 03:49:57
is there any q1sp with kingpin textures? including speedmaps.
taking a break and decided to try kingpin out for fun. turns out there's a huge amount of textures (and a lot of trim!). very cool and fun.
So Many Dude!
#10279 posted by Drew on 2010/09/27 04:27:51
I did a SM with those once. 105, I think.
most of Than's early speedmaps used them, and I think he used them most creatively/ interestingly.
|