Not sure if this is a QS-related, mapping-related or perhaps even TrenchBroom-related issue, but: I've just made my own version of this test map by Rick, and when I try to load it in Quakespasm, QS just immediately quits and says "Segmentation fault". Other maps etc. still run fine.



(On another (possibly related?) note, I always have to add "-zone 4096" whenever I start up QS, otherwise I get
ERROR-OUT BEGIN


QUAKE ERROR: Z_Malloc: failed on allocation of 4100 bytes

I once read the "-zone 4096" tip somewhere and since it works, I've been using it ever since ... but I don't actually know what it does and was wondering whether it is normal that I can't even run the stock id maps without it. Does it mean there's something wrong with my QS installation?) 

it's been a few years, but iirc, zone is a special space in memory different from heap where textures and such go. in qs, zone is used for strings, so if you have a mod with a lot of text, it runs out of space to store it there. other engines use other parts of memory, so you don't always need more zone space. 

The fact that this even matters is another artefact of Quake's MS-DOS origins. No virtual memory, no multitasking. In Quake 2 "zone memory" is just a wrapper around malloc and the issue of potentially running out of space never even comes up. 

I'm guessing the answer to my first question (whether it's possible to list just the maps from the current mod directory) is "no"...
afaik that's correct, there's no way to list just the mod's maps.

The most common reason I get engine segfaults when loading maps is:
- if you have no brushes in worldspawn (all brushes in func_group) + compile with tyrutils (my version at least), the bsp will segfault when loaded in engine. That's a bug in tyrutils I haven't got around to tracking down.

If that's not the cause of your issue, post your map source and bsp, and QS version. :-)

Re: -zone 4096, it sets the size of a memory pool in the engine to 4096k (4MB). The latest QS release 0.91.0 does this by default. It seems wrong that you get a crash on launch without -zone 4096, though.
IIRC, QS keeps the mod/map filenames for tab completion in zone.
Are you compiling QS yourself btw? 

Yeah - I have a patch similar to your i3d tutorial on replacing zone with malloc. Should probably do that, as well as the cache one.. 

ericw: Thanks, that was exactly it! I had only func_groups in that map, and when I ungrouped one of them, it worked. :)

I'm running QS 0.90.0, so I guess I need to update ... once I manage to remember how one does that. It's possible I compiled it from source (it's been a while), but if so then not without help. A lot of what I'm using I got up and running by following instructions on this board and elsewhere without really understanding the commands I'm typing.

Is it possible I did something wrong and that that's why it won't work without -zone 4096? 

Oh wait, can't I just download the first Linux precompiled, uhm, package (or whatever the correct term is) from http://quakespasm.sourceforge.net/download.htm and stick somewhere in my home directory? I think that's what I did to get 0.90.0. 

The xinput support is great!

The only thing I would suggest is acceleration functionality, where you don't instantly reach the top turning speed but rather ramp up to it over time, even when the stick is all the way in a direction. That way you can have fast turning but retain precision aiming. It really helps it feel more natural.

Pretty much every console shooter makes use of this. 

Heee, the zone memory system comes nearly straight from Doom. Fun times... 

Is it possible to add as an option? All I really want is orange lava balls, but it might be nice to have color light available for everything. 

All I really want is orange lava balls

What a marvelous sentence. 

No trojan warnings for me with the latest windows defender definitions (March 8). Weird. See if updating Defender fixes it (that worked last time, right?) 

ericw... you have made america great again.

im off to do my happy dance. 

Needs splitscreen in order to receive his free handy j 

It would be great if this engine had an option, or default, so it handles stairs like Q3 does.
Or more so, really small edges, so when you jump up some stairs, you can't get stuck in them.

I know this isn't a thing in Q1, but it really improves the movement 

That would improve gameplay on those maps with unclipped overcomplicated floor design. 

Is gooning with the player physics not a crossing a bit of a red line? 

Yes, I was thinking that too. But the reason why I choose to mention this is cause I don't think that would be crossing the line, this small specific "fix".

I can see if even more things were added, like double jump, ledge leaps, etc etc.
I think Id added this small thing so you wouldn't get stuck as easy when jumping too close to something.

Actually, I'm not sure what the difference really is, I mean, it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it, but in Q3 you can jump around in stairs and not get stuck. 

it's not like you are jumping close to a ledge in Q3 and magically just appear on top of it

Not sure if it is related but q3dm13 mh? 

Maybe you are right, can't try it now.
In any case, it's not an issue in Q3 afaik =) 

makes it harder to run some maps 

is a little twitchy. I personally hate that a floor connected to a slope will often stop you dead as you transition onto the slope. It's like there is a forcefield stopping you. 

In quake2 and darkplaces you can do this, i think in darkplaces it's called "air step." It's a nice feature because you won't get snagged on things like running across the floor grates in dm4.

I added it to Fitzquake early on, but deleted it before releasing because I realized it changes gameplay too much. The player can jump onto much higher crates with the feature -- ~40 without the fix, ~56 with the fix. Of course it's tunable, but the lower you tune it the less beneficial it is. 

Fifth, I noticed that in ad_zendar, when you climb the bricks at the start and go up the slope, there is an invisible wall blocking you at the top of the slope. It doesn't happen in DarkPlaces though - maybe LH fixed a bug in the collision code.

QS probably errs on the side of leaving everything vanilla; touching physics can have unintended side effects like metl mentioned. 

modern quakeworld servers have airstep enabled via the pm_airstep cvar.
even small airsteps of 1 or so should help work around the invisible barriers issue that results from bsp hull precision (tbh I don't actually remember quakeworld ever having that problem).

you could also only allow it when near to the ground which would fix steps (but also mean people could bunnyhop far too easily) without making ledges too easy.
that bunnyhop thing is why its not enabled by default in fte. I believe it is enabled by default in dp.