Quake MOD - In The Shadows

[Spike]

Regarding PF_VarString+Quakespasm, I'd personally say its more of a case of laziness-induced paranoia rather than a useful limit to retain.
There are other ways around PF_VarString that will crash the server _or client_. A low limit of 384 in there is absurd.
Really you have to ask yourself 'am I targetting vanilla, or do I already expect a few engine limits to be increased'.

You can still support quakespasm if you change your centerprints to this:
msg_entity = self; writebyte(MSG_ONE, 26/*svc_centerprint*/); writestring(MSG_ONE, stringtocenterprint);
But doing so is crazy.

[sock]

Trying to make a complicated mod work on "all engines" is a waste of your time and kind of like "fool's gold".

I got the impression from Func that engine developers want people to report bugs and get stuff fixed. I can certainly just stick with the engines I know work. If anyone wants my help getting their engine to work with my MOD then contact me.

[leileilol]

In Engoo's case, I get a nice "Mod_ForName: NULL name" error when I run it.

I try to stick the big map limit compatibility into a QSB define because that regresses the dos platform, however even with the raised QSB limits I can't run it. So much for "standards"

[Spike]

I'm not sure what you mean by 'regresses the dos platform'. I assume you refer to bss+ram use issues?

Mod_ForName sounds like a buffer overflow somewhere. Can't think of any other way for that to trigger that wouldn't trigger some other error first.
I'd say 'try valgrind', but I'm not sure how well that really works with large blocks of bss like the sv or cl blocks.

[Baker]

I try to stick the big map limit compatibility into a QSB define because that regresses the dos platform, however even with the raised QSB limits I can't run it. So much for "standards"

FitzQuake 666 protocol is a standard and supported by a quite a few engines. The readme says it requires FitzQuake. This is very common with the single player map releases at Func Msgboard to use FitzQuake as the baseline engine.

I guess I'm not seeing a "so much for 'standards'" angle here.

/One opinion ... maybe even wrong. I'm not often right about these kinds of things ...

[taniwha]

I very much agree with Baker.

The important thing to do is to document which engine(s) you have targeted (which you have!), and preferably what features of those engines so other engine coders know what they need to do if they want to support your mod. Developing for Fitzquake is probably a good plan as it does seem to be the baseline for most extensions (not some of QF's, but I've tried to keep them out of the way of other extensions, or found ways to get them out of the way).

I certainly don't want to restrict my MOD to certain engines

I'm not sure if this is from a misunderstanding, but all I meant about fences is the language itself. ie, while you don't want to restrict your mod to any specific engine (great!), you do want to restrict the engines covered by your disclaimer (as opposed to "only working" on those engines (well, one would hope so: wouldn't want your mod to not work on those engines )) ie, it was all about word placement. In the end, it might be good to remove "to work" from that sentence: "designed and tested with *ONLY* the following engines" (for other engines, YMMV;)) Hey, you program long enough, learn a second language (Japanese for me), these things become important. 10 years ago, I wouldn't have even noticed, let alone commented (I would have even written the same sentence ).

As for the book_fade issue: I had a nice irc chat with Spike about it (anynet, #qc) and he convinced me that quakeworld's method (which I had copied into quake) was not really so good: think should not be able to create an infinite loop. I've modified QuakeForge (both qw and nq) such that SV_RunThink will loop only if nextthink advances but is still less than time+frametime. Your fades now work perfectly.

That wall fade is awesome. Very original. I managed to catch a shot as the wall was fading.


I'd love to know how you got a texture to be both wall and water at the same time. Sure, you could create two textures "walltex" and "*walltex", but the engine would normally treat those as separate textures. It's that "one texinfo has two uses" that triggered a segfault in QF (a bug in my code that you helped me find. I gave you credit in the commit message:)).

One thing I need to confirm: after getting the amulet on the start map, the text in the books gets garbled with long strings of digits. Since they seem to be in strategic places (I believe gold text was there originally for most of them), is this by design? If not, we might need to work together to figure out where the bug is lurking.

Other than book_fade, the wall/water segfault (both fixed) and maybe the text, I haven't found any problems yet. However, there is one thing that QF does that might be against your designs: in s1m1, I can jump onto the book pedestal near the entrance and from there up to the ledge above (where the blue armor would be in e1m1). I implemented that "jump from explode box" feature in QF and decided to enable it by default. If you don't want that, set the sv_jump_any cvar to 0. That said, it seems you've designed the map for that to not matter.

Ah, sorry, I did find another one: an invisible enemy. Is this intended? I had no trouble defeating him, though

[leileilol]

I'd love to know how you got a texture to be both wall and water at the same time. Sure, you could create two textures "walltex" and "*walltex", but the engine would normally treat those as separate textures. It's that "one texinfo has two uses" that triggered a segfault in QF (a bug in my code that you helped me find. I gave you credit in the commit message:)).

That'd also send a software renderer to hell since it only turbulences 64x64 textures. The only workaround software would have is if it had procedural textured rippling ala vquake and half-life

[taniwha]

Well, QF's sw renderer doesn't crash, but you don't see any transition on the eye-walls. Also, the dragon window is flaky: sometimes visible (as a normal window), sometimes not, based on viewing position(?).

Even more interesting: QF's gl renderer only fades the eye-walls in and out: no ripple. The cool ripple effect is available in only the glsl renderer. Same for the dragon window.

I've just come to think that maybe it's a bu^h^h^hn accidental feature in the glsl renderer: any transparent texture gets queued on the waterchain texture chain, which is always drawn with turbulence... Darn, and I thought it was some ultra-cool magic sock had done . Ah, well, time to figure out how to turn it into a deliberate feature.

[taniwha]

Actually, I should add that after fixing a bug in the sw bsp renderer (rewritten R_RecursiveWorldNode overflowing its node stack), it doesn't crash. Just that room alone really pushes the sw renderer.

Still, all four of QF's renderers handle ITS just fine, it seems.

[sock]

@leileilol, I've got no idea what would be causing that kind of error. My mod breaks a lot of the original Quake map/engine limits so this does not surprise me because I assumed your engine was sticking really close to the original Quake. I do like want you have done with visuals being pixel vision.

@taniwha, Thanks for the QC patch, I applied everything except the random() update. I went through all my code and made sure all random() statements are setup correctly, this was my mistake not something that an engine should fix. The stealth walls being liquid and wall texture types at the same time, as you probably guessed was an accident. I just setup the front face with the texture and all the others faces using a skip texture which gets moved around inside of the bsp file later. It does sound cool the wall warping and fading instead of just fading.

I think my next project will be to optimize the particle system to use a fixed amount of spawn entities and not constantly keep generating new one's. All my particle emitters go through one function so it should be easy to hook up an entity chain list and cycle the list when a new particle is required. I could even grow the chain list gradually so the map start is not flooded with a huge request to spawn so many entities at once. Plus having a fixed entity list means I can hook up an impulse to fine tune the amount of entities being used across the map. Hopefully this will fix the crazy demo file problem I got at the moment.

The error with the book text not displaying properly is because I am taking advantage of the centerprint overflow bug. I read that the centerprint can handle 12 lines of 40 characters so I created books with that much text to display. It works fine with fitz/markV engines but it seems a lot of engines have blocked or fixed this overflow bug and text for books is either corrupt or truncated depending on how the engine deals with it. In an ideal world I would love a new centerprint command that can safely display that much text. It would be perfect if the QC can detect the extra command and then use it, otherwise stick with the previous centerprint instead.

[taniwha]

sock: odd, qf's centerprint code is not supposed to overflow at all. I just took a minute to verify and QF indeed can't overflow: dynamically allocated buffers are used. I guess I should look at what fitzquake does with long centerprint strings, but no time for that now: I have to go to work.

[r00k]

I've almost got this working in my engine. I can play demos that were posted here but tracking down some bugs for single-player.

Sorry about the screen size, though notice my pixely lightmaps

[Dr. Shadowborg]

Okay, done playing.

Had more fun playing this time around. Stealth tutorial updates helped a lot, though I still have some gripes with it. S1M2 plays a lot better for the stealth gameplay than S1M1 does though, largely because S1M2 "opens" more passages for you than S1M1 does. Start map also plays a lot better than the earlier version. Found out how to access a lot more areas, including the Well of Bones.

Only bugs I noticed was some book text had misspelled words, etc. This isn't a big deal for me though as I'm not a grammar nazi, and the gist of what was being said got across just fine.

Really liked seeing the monsters navigate the level to find you.

Thoughts regarding stealth mode:
1. This mode seems to discourage combat and killing, or at least discourages attempting to do so directly. As a result, it tends to punish you more for being seen. This is largely mitigated in the 1.1 demo, though you might consider a few more weapons oriented towards giving the player an edge when discovered, like a flash, concussion or poison / smoke bomb.

2. Using Enviromental Hazards is encouraged, but something I would really like to see is some way of pushing monsters around. (airfist or something, then monsters being aware of slime and lava would be oh-so-much-sweeter because you could shove them in to die. Or push them off cliffs into spikes and deathzones >=D)

3. The Shadow Cult seems to be somewhat Ninja / Assassin-esque, so why don't you give players a grappling hook or something so you can hide in the ceilings? (granted this can break gameplay routes, but then again, stealth mode is all about finding routes through areas...maybe do what Half-Life: Opforce and RMQ do? i.e. "grapple points" in certain spots of the level?)

4. Poisoned monsters only seem to attack other monsters upon initial poisoning, unfortunately this means that once they kill their inital target, they don't do anything more. Since the poison logically causes hallucinogenic effects in targets, you should make them attack other monsters even after killing their inital target.

5. No poison fatality? i.e. shooting a monster with multiple poison bolts should kill them.

All in all, I can't wait for the next version to come out. I really wanna fight that badass death knight with the oversized shield.

...Uh-oh, playing this makes me want to work on Hellsmash again.

[taniwha]

There is poison fatality: in the start map in the area with the statue there are two guards. I'd shoot one with the poison arrow and he'd attack the other guard. If he survived the fight, he'd die shortly after from the poison. Occasionally, he'd gib in the process. Poisoned dogs will die.

Grappling need good grapple physics, which most engines don't provide (fte and dp might). Also, grapple would royally mess up the current maps. Grapple points would help, but then you get the problem of "why would anyone put a grapple point there? are they insane?" (story pov). Something the Wii version of Zelda got right (imo): grapple points could be anything: grating, vines on rocks, (certain?) tree branches... I think anything that could be a grapple that the designers didn't want you to use was put out of range (ie, careful map design). All that said, grapple would indeed make for some interesting possibilities in the game play.

Airfist would and should be destroyed by the amulet . Now, being able to lure the enemy near the hazard, then making them accidentally jump/fall in by surprising them with a well placed bolt would be interesting.

The game is about sneaking around, maybe backstabbing. Essentially, it's about a vastly underpowered lone stranger trying to survive in a land very antagonistic towards strangers. If you don't like dieing, don't get caught! And don't bump into the guy you're trying to backstab, that really doesn't help.

Really, I don't think the game play needs to be changed at all. My one gripe so far is that the poison bolt is on 2 while the distraction bolt shares 1 with the axe. I find it to be rather counter-intuitive to have a ranged item on 1 and a precious item on 2. For me, it breaks the rule of least surprise.

[Dr. Shadowborg]

There is poison fatality: in the start map in the area with the statue there are two guards. I'd shoot one with the poison arrow and he'd attack the other guard. If he survived the fight, he'd die shortly after from the poison. Occasionally, he'd gib in the process. Poisoned dogs will die.

Not quite what I was talking about...I'm thinking more along the line of you hit them with enough poison to instantly overdose them and they die immediately. The bigger and tougher the monster, the more you have to shoot them to get the same effect.

Airfist would and should be destroyed by the amulet . Now, being able to lure the enemy near the hazard, then making them accidentally jump/fall in by surprising them with a well placed bolt would be interesting.

*shrug* there's always the repulsion device from Hexen II.

The game is about sneaking around, maybe backstabbing. Essentially, it's about a vastly underpowered lone stranger trying to survive in a land very antagonistic towards strangers. If you don't like dieing, don't get caught! And don't bump into the guy you're trying to backstab, that really doesn't help.

Or don't pick up the Amulet. Then you just blow the place up, with the local hostile residents being unable to do much more than die before the unstoppable onslaught of the mighty Ranger. >=D (heheh, Aramis / Berith has NO idea what "bringer of destruction" REALLY means)

Really, I don't think the game play needs to be changed at all. My one gripe so far is that the poison bolt is on 2 while the distraction bolt shares 1 with the axe. I find it to be rather counter-intuitive to have a ranged item on 1 and a precious item on 2. For me, it breaks the rule of least surprise.

^ This. I'd gotten used to cycling to it by now, but you should definately consider changing this.