I've reduced the spawning down to a single trigger the player walks through, and waves are staggered by doors in front of different groups... but it's only waking about half of the monsters anyway. Added multiple triggers in a line, or a single trigger multiple the player sits in and fires every few seconds, still isn't doing anything. Bit confused :p
ZQF
#11556 posted by RickyT33 on 2012/01/08 15:54:17
This aint a fix, but:
You could just normal monsters with the spawned and alert flags. This way you have 100% control of where and when they spawn, its easier to implement skills etc. I dunno if that would work in your map, but its an idea maybe :S
Yeah I'll mess around with how they are activating... I think I've worked out one factor that's causing trouble, some groups still had different spawn delays, and I think that was causing some telefragging and messing things up :p
Worth A Look
#11558 posted by Preach on 2012/01/08 18:33:18
Even if you do get it fixed, do set aside a copy of the map how it is now and send it to me sometime, I can check there isn't a bug in the code that way.
#11559 posted by necros on 2012/01/08 18:50:14
there's horde gameplay in rage?! :D
My conclusion is it is the spawn delay that is causing the mobs to not activate on spawn. I created a set spawned by the same trigger, two with no delay and two with ten seconds, first activate the second don't :E
#11561 posted by necros on 2012/01/08 20:14:36
isn't the auto-wake feature broken in quoth2? i know it definitely is for the horde spawner.
This so far is the only time I've had trouble with it :E
The reason I've been using it so much at this stage is because when I first started mapping I didn't realise that triggering a monster woke it up, so I didn't know I could have everything in an external closet prespawned. I was learning how to build levels whilst working on this project so it's a huge mess of shit I know how to do better now :/
Patches
#11563 posted by Preach on 2012/01/08 20:34:50
I thought that it was broken in the original release but the 2.1 patch fixed that.
If you could produce a minimal map which exhibits the issue that would be much easier to diagnose.
Finally Isolated It
It's a combination of the delay and telefragging. If a delayed mob telefrags one already spawned, then any other mobs triggered by the same action but yet to spawn (and other mobs spawning at the same time but NOT involved in the telefrag) no longer spawn alerted.
Now I'm aware of it it shouldn't be something too hard to get around, just means being less sloppy about creating spawn closets, but for you to observe it Preach:
http://www.zealousquakefan.com/junk/delaytest1.bsp
Cool
#11565 posted by ericw on 2012/01/08 23:26:34
So if you can guarantee that no telefrags occur, the alert-spawning will work fine?
Looking forward to your map, ZQF :-)
This does explain why it was only affecting one fight, because of the three big fights I used different methods to make the closets :E
Bug Report Accepted
#11567 posted by Preach on 2012/01/09 00:10:43
I'll admit that I had been looking in the wrong place for a potential bug - I was checking the code for the info_multispawn and info_groupspawn for spawning lots of monsters from a single entity. This was a bad assump�tion on my part, as the monsters in the test map are regular monsters using the teleport spawnflags.
Looking in the correct place, it's a genuine and longstanding bug in Quoth. Delayed teleporting monsters ought to save the activator variable in the monster when first used and then restore it once the delay time has passed. Quoth neglects to do this and so the activator in the most recently handled event is applied to the monster!
Usually this is still the player and so the bug goes undetected. But if something else activates an event then the bug is exposed. In this case the telefrags set the telefragging monster to be the activator. Even though they are not activating the monsters, the code acts as if they were. There are of course other ways this bug could arise, but they are probably more obscure. Ah well...
Is it possible to have so many entities that Quake C just starts to fall apart a bit?
Well
#11569 posted by Preach on 2012/01/10 01:14:39
The most obvious way that too many entities can cause problems is if you spawn more than 600 on a standard engine. That causes an instant crash to console though, which is in my book not falling apart "a bit".
If you had enough monsters going at once you might be able to cause noticable framerate slowdown from the amount of ai being calculated, but I think on modern computers you'd be more likely to hit the former limit than the latter.
The most likely falling apart I think you'd see if hitting packet limits. Over a network the server has to send out packets of updates to each of the clients. If too much is happening at once, the packet becomes full before all the updates can be packed into it. This is called packet overflow.
When packet overflow occurs then sounds can fail to play, and entities or particles may not draw. It's worth noting that although this problem is rooted in the network code, it still occurs in single player. Standard engines still have a client and a server in a single player game, the packets just get sent internally. Fitzquake among others has more sophisticated handling to avoid this problem in the SP case.
Anything sounding like the issue?
Not really. I was getting some odd behaviour (including the aggro issue) but after recompiling it went away again. The map has nearly 3000 entities, due to the monster sets between easy/normal and hard being almost completely different and a lot of relays and triggers and togglewalls etc.
Just a thought that I might be pushing it too far on having so much stuff trying to run at once... but it isn't actually causing any frame rate issues, so perhaps again just some flaws in the entity setup I haven't noticed yet. I'll keep quite until I've found something more concrete and reproducable.
Activator
#11571 posted by negke on 2012/01/13 14:00:11
Uh, who's the activator in a logic gate? Here's a button that triggers a spikeshooter with two shootable triggers in front of it. First one is supposed to show a centerprint, and is killed at some point to let the spike pass through to the second one. No message is displayed.
#11572 posted by negke on 2012/01/13 14:29:04
Ok, so the spike becomes the activator. Crap, now to add complicated workarounds.
Yeah...
#11573 posted by metlslime on 2012/01/13 17:01:05
a common problem unfortunately :(
Would like some suggestions on how this area could be lit and such. Going for an 'dark, cavernous and unused for years' kind of feel :E
http://www.zealousquakefan.com/images/base_ep/zqfbase_ep8.jpg
#11576 posted by necros on 2012/01/13 18:51:47
strong but isolated spots casting tons of long spooooooooooooo... ...oooky shadows.
Lighting
#11578 posted by zqf on 2012/01/13 23:15:45
Despite cavernous theme, put more light sources in? Especially along the main walkways. It's not lit well enough. Use delay 5 / wait 0.5 to make light reach further.
"Dark" doesn't work too well in Quake. You have to use pretty powerful light sources to get anywhere. In the end it is a game and the player has to be able to see something - it has to be functional.
Try using equipment as light sources, too - slipgate "powercubes", mobile light props, computer screens and so on.
Use spotlights.
You can also use e.g. candles and fire in base maps as light sources, you just have to make their presence look plausible. ^^
If all else fails, destroy the ceiling and let some sunlight in... only in certain places of course.
Crashed spaceship's thrusters as light sources / traps. Fire and debris. Burning barrels. Anything that gives off light (perhaps coloured) and looks plausible. A blaster test station. Laser traps. Car lights.
Duh
#11579 posted by gb on 2012/01/13 23:16:32
that was posted by gb, @ zqf. Sorry.
|