Quakespasm on Steriods

[Baker]

Random thing I noticed.

I made comments in an external .ent file example, Quakespasm and DarkPlaces don't mind the comments but FTE doesn't like them at all.

// Specify custom effect

FTE no like.

Running developer 1, I discovered that the particle scripts at least in QSS don't like // comments.

Removing them.

[Spike]

quakespasm culls entities with 'zero' alpha, hence why r_effect+trails+etc won't work on them.

r_effect spawns particles at the entity's origin. for most bsp models, this means at '0 0 0', though origin brushes or hack-equivelents can be used as a work around for that.
its a shame that it can't spawn particles from non-world surfaces, yes. I rewrote some stuff after porting it to quakespasm, so that should actually be much easier to achieve than in my original implementation (although cleaning stuff up in quakespasm would likely be a nightmare thanks to everything assuming that the hunk is used and the resulting lack of frees).

fte's particle config parser actually uses fte's console (which potentially allows mods to stuffcmd effects to clients). the quakespasm implementation just parses stuff directly line-by-line as I was trying to avoid touching/breaking the cbuf code, so there are fairly significant differences because of that (like being able to use 'exec' in fte and not quakespasm). multi-line comments are thus not going to work too well in quakespasm because of the line-by-line nature not tracking whether its inside a comment or not, while fte accepts semi-colons as line separators too.
single-line comments SHOULD work, although this can result in fte thinking that it reached the end of the console buffer (something I really ought to look in to), so be sure that there's a tab or something before it and not a completely blank line. or something. also if you're pasing single-line comments from the system clipboard, then the \n->; conversion thing means that those single-line comments comment out the entire rest of the paste (not an issue with exec, just ctrl+v).
I think the quakespasm implementation has a bug with not detecting eof properly for files from inside paks, resulting in it reading the following file data too. I've not actually checked, just theorised it. I ought to test namespaces properly too.
fte+quakespasm's effectinfo file parsing should work the same, though they have different Cmd_TokenizeString implementations which will probably affect things in certain ways.

17) tex_sky1 will be used for all sky1 surfaces that don't have any specific mapping. vanilla only ever used sky1+sky4. presumably you wouldn't want rain in space or whatever.

1 that would require some sort of wildcard support. which would make turbs a bit awkward. fte has a mod_texturelist command with mouse-overs that display the actual texture. mappers can just look at the name of the texture that they're slapping on to their various surfaces.
iiuc, single-skies is a glquake bug. its easily fixable with glsl skies, but far too many engines insist on having fallbacks. plus skyboxes kinda mess stuff up too on account of most engines only using global settings for it (yay shaders!). map compilers don't care, and winquake didn't have an issue, iiuc.

[Baker]

Within the next 30 minutes, I have my stuff ready to go and will be posted @ func.

I did end up figuring out a number of puzzles I posted about.

It's pretty good.

The engine does crash if you die with the map demonstration, but as this is meant more as a demonstration and tutorial, that isn't so important.

re: limitations

There's always limitations, like 256 colors of brown.

Nothing is ever "perfect" but the client-side capabilities in the engine are WAY better than what any of the single player mappers are doing now

Light years better!

And they allow non-QuakeC mappers to do useful things Most mappers can map, but use something like Quoth or Arcane Dimensions because QuakeC is entirely different knowledge set.

[Spike]

what's a bug, and what's a limitation?...

I still need to go through and fix the various stuff for an r5. and not just particle related.
I ought to make a checklist of all the stuff that I still need to resolve, but I'm far too lazy even to re-read this topic, let alone the steps that come after that.

I did also mean to make some sort of scripting addon thing using the various qc extensions, but I'm not sure I can be arsed to do that either.

[Baker]

I'm not sure I can be arsed to do that either.

Hehe .. well you'll certainly get no pressure from me.

I'm documenting the particle system because I think it would be bullshit for you to have to do it (and I kick ass at documentation ) because you put the hard work into it.

I think engine coding should be a leisure activity.

I've done posts on the Tragedy of the Commons. My own rule for engine coding is that I will do it when it works for me and I have time to do it and when I want to do it.

Quake can wait. Even for the day that never comes. It's just a game.

It's all open source, right? If someone else wants something bad enough, they could choose to do it if they wanted to, couldn't they?

But those kinds contributors are a dying breed, it may just be the natural order of things.

Anyway, when I started engine coding I had 1 rule: Never, ever privately contact anyone (private message or email) and ask them specifically for help doing something.

Getting into engine coding meant to me never imposing on others and taking it upon myself to overcome the obstacles and appreciate the times that someone did of their own free will help me solve something.

You'll never hear me complaining, haha.

I guess I'm saying ... this is just a game -- you know?

[Baker]

Btw .. I can postpone the tutorial. I haven't posted it yet.

Just let it sleep indefinitely and all that.

The demo/tutorial can wait for a more appropriate time in the future (or even the option of "not all at").

So I'll just let it sit on my hard drive. It's not going anywhere.

The Earth will keep spinning and the Sun will rise tomorrow and the next, I'm pretty sure about that. Hehe

[MadGypsy]

EDIT:

The original is correct but, this is better

script.replace(/\/\/[^\r\n]+(\r\n|\r|\n)/g, "\n")

get // and every character after it that is not(^) in range [\r\n] until(+) (\r\n|\r|\n) //all inclusive - "\r\n|" can maybe be removed, it's DOS based

multiline
script.replace(/\/\*[^\*\/]+(\*\/)(\r\n|\r|\n)?/g, "\n")

get /* and every character after it that is not(^) in range [\*\/] until(+) (\*\/) which is optionally(?) followed by (\r\n|\r|\n) //all inclusive

-----------------------------------------------------------------
@comments broken


remove comment and newline/return
script.replace( /\/\/[a-z\s\t,._\-0-9]+(\r|\n)/gi , "" );

remove and leave the line break
script.replace( /\/\/[a-z\s\t,._\-0-9]+(\r|\n)/gi , "\n" ); //newline
or
script.replace( /\/\/[a-z\s\t,._\-0-9]+(\r|\n)/gi , "\r" ); //return

This will strip ALL single line comments in one call.

For anybody that doesn't understand this, it's super easy.

start a regular expression and set flags to search globally, case-insensitive
/ /gi

escape the comment character - cause if you don't you just made a comment
start search at this.
\/\/

Look for this range of characters (a to z, space, tab, comma, period, minus, 0 to 9) in succession(+) til you hit something that is not in this range
[a-z\s\t,._\-0-9]+

if the character out of range was one of these 2 (return|newline) then it's a match
(\r|\n)

[Baker]

[Spike]

baker, never say never.
mostly I'm just waiting till my interest for it comes back, while giving people time to find bugs, but frankly it seems you're the only one that's interested right now anyway. on the plus side that means very few bugs to fix!...
I do still plan for an r5 and already have stuff for it, but I'm still waiting to see if there's anything else that I missed. I ought to go through each and every extended qc builtin, but meh, its easier to wait for other people to test it and then complain about it.
there's also sprites used with viewmodelforclient which I ought to look into.

either way, I need to get it to a state where the quakespasm people would be willing to accept the patch, because otherwise its basically pointless.

[Baker]

while giving people time to find bugs

The crash on death seems to only occur if an external texture is used. If I comment out the one effect in the demo that uses an external texture, I don't crash on death.

baker, never say never.
mostly I'm just waiting till my interest for it comes back

Well, I contributed my stuff without putting any kind of pressure on you. Allowed me to have the closure of getting the demo out (I hate unreleased complete stuff sitting on my hard drive).

seems you're the only one that's interested right now

Well, the particle stuff almost required me to read the engine code half the time to learn what the commands are. It isn't a lack of interest, it's a lack of accessibility. Also the stuff hasn't been used in a high profile map.

because otherwise its basically pointless.

So not true!! I don't have the time to say the 35 ways it isn't true.

[Baker]

Note: The demo may not get a whole ton of comments since it doesn't include
1) screenshots (casuals can't say "looks cool")
2) many people cannot install mods without the Quake Injector -- just how it is.
3) the engine uncertainty issue

From my perspective that's fine.

If just 1 or 2 serious mappers load it up and see what it does and think "Ah, I can use that!" --- that was my goal. They don't even have to comment.

In fact, if only a small audience of serious mappers check it out, it can increase the "cool factor" in their own map release.

Since I included no screenshots -- as a way of rewarding interested parties with easter egg like surprises when they check out the demo.

(If I was trying to drive you batshit crazy and get 500 people knocking on your door, don't you think I would have done a post here? No.

Anyway, I know how to aim for high interest vs. developer/serious player interest only. I chose #2 for reasons stated above.

[Baker]

I did some thinking ... and I'm going to "acquire" IPv6 and most network enhancements this week. I don't actually have time to do this. So I'll be "making the time".

But on the other hand, your changes are countless weeks (months?) of coding that I don't have to do at some future time. So the right time to acquire it is now, especially while this is still fresh, despite not actually having the time (I'm going to make the time).

Questions/Observations:

20) _Datagram_ServerControlPacket: "getinfo" "getstatus" ... what are those? Does FTE or DarkPlaces send those? A quick look does not seem that QSS sends those, so looks like is support for something the engine doesn't actually do as a client.

21) sv_protocol -15 is ... well ... not ideal. I can't use -15 in a server command line, it gets interpreted as a command line argument (like -window). I tried to do +sv_protocol "-15" and doesn't seem to work. Haven't thought much about command line parsing in a while.

At the moment, I don't plan to acquire FTE+666/nacks/etc or extensions in wave 1. Wave 1 will just be IPv6 and probably single socket server and anything else I have high faith that for sure.

Wave 1 should in theory act as a reference for implementation in a 3rd engine.

So what I'm probably going to do with Wave 1 changes is QSS ---> Mark V ---> ProQuake. Which if I can get that right, the changes more or less could be ported to any engine since ProQuake's network stuff is pretty close to the original Quake in most ways.

22) Lazy question: It looks like the gamedir is communicated to at least some clients in the source.

/Since I don't really have much time, I am going to try to complete this fast.

[Spike]

20) getstatus is sent by the dpmaster program, which lets the master know that the server is genuinely there (and someone isn't DOSing the master+clients with all sorts of non-existant servers).
getinfo also includes player counts, and is what DP expects for servers advertised via dpmaster. this means that you can use protocol 15, swap the com_protocolname cvar around so the server advertises itself as DP, and then DP will show your server in its server list (not done by default, because DP doesn't support 666).
QuakeSpasm just uses its old nq queries. This prevents getting responses from dpp7-protocol servers.

21) both -15 and 15- are accepted. try 15-.
could also add aliases for those magic numbers, vanilla+fitz.
what's wrong with just using 15 as-is? the only reason to disable the deltas is if you're recording a vanilla-compatible demo, otherwise no benefit.
Really it should be a client setting instead, or something, I guess.

22) yes, I did network up some gamedir1;gamedir2;gamedir3 etc thing, but I got lazy. and quakespasm doesn't use it other than for a warning print. OH NOES! YOU'RE USING THE WRONG GAMEDIR! SHIT HAPPENS! blurgh. nq never really cared, so I expect a lot of nq users use different directory names for half this stuff anyway, which makes it a bit awkward. The server should report each mod (eg: "hipnotic;quoth;warpspasm" but skip id1 or engine-specific dirs), but a client doesn't necessarily need to be rewritten in order to deal with the gamedir+configs+etc all switching around on map changes, shit happens.

[Baker]

20) "getstatus is sent by the dpmaster program" --- That thought entered my mind not too long after I posted. The dpmaster source lives on my harddrive somewhere, but obv I didn't check it.

21) "what's wrong with just using 15 as-is?" Ah, you are saying that 15 (15+FTE) is that backwards compatible? Haven't tested that. For some reason I wasn't thinking it was.

22) gamedir "quakespasm doesn't use it other than for a warning print" I'm going to be thinking about that more at some point. Possibly not now or soon. To me, multi-gamedir is clusterfarm of poor design. Especially if you factor in the idea that someone might do a listen server and use multigamedir for merely replacement content. Breaks the whole concept of comparing (via CRC16 or some other algo) content to see if is needed by client.

Complete fiasco + nightmare.

Plus other things like skybox textures, .lits and other similar files and so forth aren't part of precache ... grrr.

23) "the only reason to disable the deltas is if you're recording a vanilla-compatible demo, otherwise no benefit." --- is it possible to record a vanilla 666 demo (that plays back in FitzQuake 0.85) or 15 demo (that plays back in GLQuake)? You seem to be saying that is possible. I can't remember if I tried that against R4.

[Spike]

21) there's a hackshake for protocol extensions. If the client doesn't support them, the server won't use them. Simple as that.

22) its far easier to just shove a pk3 into the gamedir. obviously quakespasm still doesn't support pk3s, but that's not quite the point. either way I don't personally see it as an issue, at least if people are aware of what's going on - my personal preference is for everything to be released as a package and for those packages to be enabled/disabled as needed.
note that downloading packages from servers instead of files means that lits etc are handled gracefully. and bspx support means that v1 lits are redundant for new maps, if mappers were to actually start using it, anyway (did I add that into QSS? I thought I did).

23) sv_protocol -15 will unconditionally disable additional extensions, resulting in a compatible demo, for certain definitions of compatible (although needing to use a server setting for a client behaviour is stupid, but I was too lazy to add an extra cvar). QuakeSpasm has always bypassed maximum message sizes in one form or another, and it will still do so for loopback, which may be an issue if you have a large svc_serverinfo packet with 256 models+sounds. For unreliables, demos don't need to respect the max_datagram size, and so its not a problem if they exceed 1024 bytes, so long as they don't exceed 8192.
The demo that I recorded with R4 worked. Or maybe it had a couple of extra tweaks, but I don't think it did.