I'm working on a mod and its mostly a multiplayer one. I've started with Quakespasm but it sucks for multiplayer. Is there a good Q1 engine with decent netcode and multiplayer capabilities? I'm looking for something that makes it easy for people to create servers and join with their friends.

I'm even considering switching to ioquake for that, even though i only know QuakeC. :( 

Practical options:

1) Use DarkPlaces as server and Spiked Quakespasm (QSS) as a client. Have a proper Quake client in Spiked Quakespasm, while having proper netcode (DPP7).

2) Use DarkPlaces. But doesn't have the correct classic Quake look.

3) Use FTE. Possibly your best option by far because FTE has nearly limitless capabilities and is very strong in multiplayer.

Practical answer:

You have a huge problem though ...

I'm looking for something that makes it easy for people to create servers

This ain't going to happen. Anyone who has a router (that's most people) --- are there dozens of brands of routers -- is going to have to manually configure their router to allow connections to their server.

That is going to prevent nearly every non-technical person from ever hosting a server.

Doesn't matter what game it is ioQuake or MineCraft or anything else --- the router configuration problem is simply going to prevent an average user from ever hosting a server. 

yes, imho.

FTE has single-socket servers, prediction, master servers, spectator mode, nack deltas, voip, ipv6, splitscreen, qw/nq cross-compat, etc. It even has a plugin that can usually invite/connect/call directly to xmpp friends. It also imho has the most versatile qcvm(including proper debugging) and better model formats than mdl(no more qme!) so its great for mods too.

ezQuake, DP, or QSS[not vanilla quakespasm] are your runner-ups. They all use a single-server-socket, so it should be possible to set up firewall rules without too many issues.

That xmpp thing would be awesome if getting everyone to set up xmpp accounts and enter passwords etc wasn't such a burden. What it does mean is that you shouldn't need to reconfigure any routers - just enable the plugin and invite/join your contacts.
This is roughly equivalent to using steams' contact list to start games, just with a 3rd-party/unlocked chat server.
Obviously this only applies to private games, and its not guaranteed but it should work with 90% of routers (google's stat from their voip-over-ice offerings).

If all else fails, there's nat-pmp/pcp or upnp-igdp protocols that can be used to reconfigure routers. You can set 'sv_port_natpmp 5351' in FTE for the former if you've some mac-friendly router, but I never properly tried to add support for the massively-overcomplicated-and-permanently-quirky upnp-igdp protocol despite it being more commonly supported. Note that programs like Skype constantly rewrite your router's firewall rules using this sort of thing.
So yeah, never say never.

@Baker, DPP7 doesn't provide anything useful to QSS that isn't also provided by the FTE+999 protocol that QSS supports. I added it because I'm a sucker for compat rather than any other consideration (the client side for either protocol isn't particularly hard anyway when you ignore csqc etc, I doubt you'd have issues adding it/them to markv to a similar level, except for the particles anyway). 

Does FTE+999 do prediction? If so, I must have missed noticing that in the changelog.

I was under the impression that FTE+999 didn't do prediction. 

yes, but QSS doesn't, even over DPP7.
Adding the physics changes required for reliable prediction means changing physics, and I didn't want to deal with the politics of that, so QSS retains the physics that mappers are actually comfortable with. My idea was to eventually implement CSQC, at which point the QC would be able to do all the prediction itself, which would save me from the politics (everyone blame whoever wrote the qc!).

But yeah, FTE+999 is roughly equivalent to DPP7, but QSS doesn't support prediction either way. 

I debated whether this should go in the "teaching old progs.dat new tricks" thread or this one, but I guess you could also see this as a request of sorts... So here it is.

If I add a maphack that references another entity, for example the "CastLightning" hack, that references an "enemy" field. I notice that the hack can break if I've added a "not in x skill" flag on an earlier placed enemy.

In this situation the edict / enemy number gets displaced.

Are these handled in qbsp? or in the compile tools chain?

Is it possible to have qbsp process any enemies with these flags last? OR is it possible to give entites a key that qbsp searches for and places them first, before any mobs?

Cheers,

Snaut. 

forgot that I asked a similar question to what was answered in #2350 

See Teaching Progs post #6687
http://www.celephais.net/board/view_thread.php?id=4&start=6687 

ahh 3 skill versions... seems hacky, but acceptable.... or maybe I'll just delete and replace the mobs. 

Has anyone here made a parser for the .MAP-format for games like the Quake and the Quake 2? I've looked into making one myself to allow for wanton random generation of maps (or parts of maps/prefabs). It would be like an upgraded Oblige but with more focus on generating interesting architecture with decent texturing.

The .MAP-file format is pretty elegant TBQHWYFAMs and I don't think it would be a too taxing task to do. 

working on something like that. Forgot who and the name of his mod. You might wanna check the works-in-progress section there. 

I'm sorry but I can't seem to find it... 

Been a while since I saw that. If I stumble upon it I'll let you know. 

fteqw-code/engine/client/r_surf.c:3299:16: error: ‘com_resourcemutex’ undeclared (first use in this function)
Sys_LockMutex(com_resourcemutex); 

cd fteqw-code/engine && rm config.h && make m-rel && release/fteqw -basedir whatever

If that doesn't do it then you're going to need to give more info, like what OS you're trying to compile it for/on. Stuff like that matters when it involves threading. 

Still problems. Ubuntu 16.04 64-bit. 

revision 5134 compiles fine for me on 64bit ubuntu 16.04.

try make clean
revert stuff listed by 'svn status' (or just delete everything listed).
and try 'svn up' to make sure you've actually got the current version (and replace anything you may have deleted above).

other than that, I've no idea - it should just be a case of checking out, switching to the engine dir, and running 'make m-rel'. 

Is there any way to preserve an entity through a "reset" command?

I have an entity called "settings_pig". I'm using him to shuttle settings across saves. It works fine for this, but I need some settings to persist after a reset. Is there any way to do this?

I've been using the temp1 cvar, but I can only use that for a little bit of information. Any thoughts? 

I found a (hacky) solution... I can encode more data than I thought into temp1 

Settings shouldn't persist across a reset.

Type "coop 1; map e1m1" in the console if you want things to remain unchanged after death.

You can even save the games (as long as you don't change maxplayers from 1 to a higher number). 

random()'s purported result is 0-1.

In ID1 the ai_melee function does:
ldmg = (random() + random() + random()) * 3;

Soooo...this means that you could receive 0 damage from a knight slash??? Granted low probability due to having 3 of the random()'s and ai_melee being used on multiple anim frames. 

random()'s purported result is 0-1.

In ID1 the ai_melee function does:
ldmg = (random() + random() + random()) * 3;

Soooo...this means that you could receive 0 damage from a knight slash??? Granted low probability due to having 3 of the random()'s and ai_melee being used on multiple anim frames. 

its worse than that.
the vanilla qcc had a bug that caused any operator with function calls each side to discard one side and use the other for BOTH terms.
so (random()+random()+random()) really just ends up as (random()*3).
(for anyone weak at statistical maths, adding 3 different randoms gives a value biased towards 0.5*3 instead of an even distribution, assuming no qcc bugs)
which is of course more likely to return extreme values like 0 or 1.

whether random() can actually return 0 3 times in a row depends upon the implementation. Some of the simpler ones just use a lookup table and might not have 3 such entries in a row. others might work more on a bit rotation basis and similarly be unable to return the same thing 3 times in a row. true randomness is basically impossible on current hardware, especially if you've no access beyond the userland.

side note: returning 1 is more problematic, at least if you use arrays. array[random()*array.length] = error! you can bias it, but then the last element is less likely which is undesirable too.
so dp+fte never return 1 from random(). they do return 0 though.

other side note: you can die even with health > 0!.. death occurs at health<1 (instead of health<=0). stat truncation results in interesting quirks otherwise. 

Remember that random is really a pseudo-random number generator - a fixed stream of numbers which looks random from one to the next and starts in an unpredictable place. It will once in a blue moon throw out an actual zero, this is the cause of the frozen monster glitch. However, I suspect that the PRNG being used here won't actually have a stream of numbers long enough for three zeroes in a row to ever occur.

Technical details: one of the important details in a PRNG is the "period", how long a string of numbers it produces before it loops back round. While a good quality PRNG like Mersenne Twister has a period with 19936 digits (in binary), that was developed in 1997, a year after Quake came out. Doubt anybody's gone to the effort of upgrading Quake's PRNG in the meantime.

Although I can't be bothered to check what Quake does uses (or gets from the default C libraries) I'd guess it's got a period of 2³². If this was used to generate 23 bit numbers (size of the mantissa in floating point) I would estimate the chance of a particular number appearing twice in a row anywhere within the sequence at 2³² / (2²³ * 2²³ ) = 2⁻¹⁴. So while we'd expect some numbers to occur in pairs, there's no guarantee 0 would be one.

And that's just pairs, when we go up to triples we're looking at something 2²³ times less likely, which is actually exceedingly unlikely to even happen once in the 2³². In other words, chances are the RNG in Quake will never output any single number three times in a row. 

..I take 4 paragraphs to say what spike can cover in just 1