Upcoming Tutorial: The Seamless Multi-Map World

[Baker]

TODO:

Think about this some more and how to make it universally compatible with standard Quake with a mild engine modification like rotating brush models.

Rough framework is like this:

1. Since QuakeC support for such a modification would be necessary, have QuakeC somehow tell the engine that a mod wants multimap support --- AND can the QuakeC tell the engine EARLY enough in process?

Or is there a better way? One assumption is that a multimap mod certainly MUST have it's own gamedir. Or would it? (Thinking of sv_progs support here and Universal Server project compatibility).

Ah ... let's just have the engine use a cvar. sv_multimap 1 ... easiest way. Is that cvar name "good"? sv_multimap_travel? sv_persistent_game_world? Whatever ...

Or perhaps better and more natively ... ALWAYS assume multimap support is wanted (ON by default) but if a changelevel doesn't contain a "." then it isn't acted on for that map ... effectively neutralizing the feature for all existing maps but allowing maximum flexibility for future maps.

I mean, this feature looks for an existing "Quake in progress" file and isn't ever going to find it for a traditional Quake map so on by default should be harmless enough. And if the new map name doesn't contain a "dot", it will never be saving one and no existing map names have a "dot" in them.

2. Treat all trigger changelevels with dots in the map name as parsable to extract the name of the spawn point desired.

3. How are save games going to be handled? They practically require their own folder with this.

4. And single player --> new game and typing map in the console would need to clear all the current .qip files.

But there is no reason to have to include all those progsdef.q2 stuff to get this to work ....

/End thinking

[Spike]

please don't pretend that its a filename extension, as that kinda prohibits other fun stuff (like distinguishing between doom(1) and quake maps).

make changelevel accept one or two arguments.
arg1 contains map name.
arg2 contains startspot.
if arg2 is missing, all previous maps are flushed, behaviour is identical to regular quake (doesn't load from archive)
if arg2 is present (or empty, would need to be quoted in this case), the old map is archived and stored somewhere, the new map is potentially loaded.
arg2(or empty) is stored into the new map's startspot string global.

engines that don't support it will not notice the second argument. engines that do can handle it correctly.

the changelevel builtin internally does a localcmd. If it doesn't add quotes, it doesn't technically need modifying, but it should be able to accept two arguments for consistancy.


This is what FTE does. Specifically, old maps are saved to disk, with their names remembered. Maps are reloaded only if they were known. Saved games copys out visted maps.

To make it properly seamless, you also need to be able to carry quad over and the like. FTE supports 64 spawn parms, as well as an alternative mechanism which I'm too lazy to mention.

[mh]

I generally don't like the idea of using cvars for this kind of thing as a player could just pop down the console, change it, and BANG! Bad things happen. The player doesn't even need to be malicious, just simply curious or careless. The cvar system is nowhere near robust enough, and would need engine-side protection added on to it in a manner that prevents this kind of thing from being done but at the same time allows all the default behaviour with other cvars.

Shooting for a pure-engine or pure-QC solution to this is like using a screwdriver to drive in nails. You can do it, but you'll have a hard time and you might create a mess along the way. Better to utilise the strengths and suitabilities of each and get them working together on it.

Likewise going for a fully general solution as V1.0 is a mistake, IMO. You need a simpler V1.0 that can be tested, have all the little wrinkles ironed out, and all the weird edge cases identified and worked around, then build on that experience to implement a better V2.0.

If we start at the most basic level, assuming that the player travelling back and forth between maps is good enough for now, but other entities can wait on V2.0, what we need to do is:

• Save the map state when exiting - the current save code is more or less sufficient for this.
• When loading a new map, look for a saved state. If found, treat that as a load and the current load code is more or less sufficient; if not found just pop the player at the correct start spot (of which more later).
• Modify trigger_changelevel to include a "startspotname" (or whatever the consensus decides is most appropriate) field.
• Modify info_player_start to include the same field.
• During a changelevel (where there is no saved state), link the two and put the player at the right position.
• Find a clean way of implementing save files. Each save file becoming a directory instead is a good start, but there are other interactions that need to be fully worked out (what is you save in s0, progress a little, save again in s1, then changelevel to a map who's state is in s0 is one I can think of right away).

The Quake II and Hexen II systems may not be sophisticated or perfect, but the one thing we do know about them is that they work. They've been field-tested for years among many users, and you can't argue with a pedigree like that.

[Ranger366]

This reminds me of the very old MultiMap/World server idea fo Quake.
If someone would do this for Quake 2 im going to pay.
But thats off-topic.


Still this would be really cool for most of everything.
But i think my words get ignored here so i will not say the rest i wanted to say for now. I already have enough Karma lost, i think...

Add to Scores:
Ranger366 -1

blarg.

[r00k]

I havent read through the majority of this, Spike's method sounds valid. Though, is there a way to use the methods (talking out my ass at the moment) used for SAVED GAME files to save the STATE of the level you are leaving? I'd imagine, you walk up to a closed door, you have to touch the door, or button/lever to open it. This could be the trigger for saving the gamestate, creating a temp file, or drop out point if you quit the game. Im not suggesting using the exact same saved game code but using it as a stencil. Obviously the player_state portion of the game state would NOT be saved to that file, but tucked away somewhere else. Now how this ties into online play who knows, either a SVC_ or such...

Edit: I just read MH's post, sounds like my ass wasnt talking shit after all...

[Max_Salivan]

to PART II: QuakeC

Code: Select all

	if (startspot)
	{
		spot = world;
		pcount = 1;
		while(pcount)
		{
			spot = find (spot, classname, "info_player_start");
			if (!spot)
				pcount = 0;
			else if (spot.targetname == startspot)
				pcount = 0;
		}
	}
	
	if (!spot)
	{
		spot = find (world, classname, "info_player_start");
		if (!spot)
			error ("PutClientInServer: no info_player_start on level");
	}

[ceriux]

this seems like an awesome feature that every quake engine should have. it helps mappers and mod makers alike. baker do you have an engine with this already implemented ? (i would like to see sock work this into his project, would be awesome)

[Max_Salivan]

this seems like an awesome feature that every quake engine should have. it helps mappers and mod makers alike. baker do you have an engine with this already implemented ? (i would like to see sock work this into his project, would be awesome)

i have Fitz Quake with it

[Spike]

rmqe should already support it (at least its on the svn even if there's no public release!).

[qbism]

rmqe should already support it (at least its on the svn even if there's no public release!).

Any advantage to hubbing if the whole thing fits into a bsp2?

[Spike]

graceful autosave points, in that the 'restart' command restarts only the current bsp, as opposed to the entire hub (which is what would happen if you had only a single bsp). There are other methods of course, but this is the more intutive solution for that...
can run on public coop servers without requiring clientside extensions (and can still work in vanilla servers too, but with the caveat that it ends up somewhat like prydon gate's 'hub' stuff if you're take care over 'startspot' not being transfered).
lower ram use (bsps don't have to be loaded in their entirety, ents can potentially be zipped saved to disk between maps).
less active entities at one time (relevent if you use ode or gyro or other cpu-intensive qc stuff).
clearer demarkation of areas.
keeps the mapper aware of just how much backtracking they're forcing the player to do... I hate backtracking.
shorter individual compile times.

I'd state the disadvantages, but:
a) I'm lazy.
b) you didn't ask for those.

[qbism]

Most of the disadvantages seem related to continuity. But monsters frozen in their hubs could be a feature rather than a disadvantage by remaining as the player remembers.

Q2 is hubbed yet still with plenty of backtracking. Especially the palace levels... What was I supposed to be doing again??

[Max_Salivan]

with this

Code: Select all

#if 666
strcpy(startspot, sv.startspot);

// try to restore the new level
if (LoadGamestate (mapname, startspot))
SV_SpawnServer (mapname, startspot);
else
SV_SpawnServer (mapname, NULL);

#else
SV_SpawnServer (mapname);
#endif

i got error "Received signon 1 when at 1"
idk how ti fix that,but i got something:)
may be not good,but its working

Code: Select all

#if 666
strcpy(startspot, sv.startspot);
#endif
// try to restore the new level
if (LoadGamestate (mapname, startspot))
#if 666
SV_SpawnServer (mapname, startspot);
#else
SV_SpawnServer (mapname);
#endif

[Spike]

max, does loadgamestate not contain an internal spawnserver call already?
quake's saved games (and thus presumably also hub system) involves loading a new map then wiping all ents and replacing them with ones from the saved game. only difference between a hub and a saved game is that you don't save+reload the player, player parms, serverflags, or startspot.
(you'll also have to save the other maps into actual saved games too, of course)

[Max_Salivan]

max, does loadgamestate not contain an internal spawnserver call already?

its contain SV_SpawnServer (mapname, startspot);

i think,this system can be better,if port it from Hexen 2 with save/load game system
Hexen's system is awesome:)
i tryed port it,but failed somewhere in changelevel may be..argh