Nashalrath

[Meatwad]

Here's a suggestion:






It explains itself.

 

[The Man In Black]

Here's a suggestion

It explained itself.

>_>

 

[J-M v2.5.5]

My suggestion:
We slap the snot out of the next mapper who gets the stupid ****ing idea of placing spawn points in a spot where there's not enough head room.

Thothie would not even have to waste his time fixing this if mappers were just a little more careful.

 

[Sabre]

Ah, but was it J or Gurluas who is responsible?

 

[Thothie]

There's headroom for 1 player - just not for more than one.

Meh, I could ripent a push brush into there without fuxing with the client<->server missmatch bug, and put in another map verifier string... But really, need to figure a way to get the tospawn function to work on disconnected maps, so either you could /stuck your way out, or it'd just stick you in one of the ms_player_spawns to begin with.


edit

	//********************************* GETSPAWNPOINTS *****************************
	//Thothie JAN2010_20
	//getspawnpoints <var>
	//Stores spawn points in a token string
#ifdef VALVE_DLL
	else if( Cmd.Name() == "getspawnpoints" )
	{
		if ( Params.size() >= 1 )
		{
			msstring thoth_return_spawnpoints;

			mslist<CBaseEntity *> Spawnpoints;

			CBaseEntity *pSpot = NULL;
			while( pSpot = UTIL_FindEntityByClassname( pSpot, "ms_player_spawn" ) )
			{
				Spawnpoints.add( pSpot );
				if ( pSpot )
				{
					thoth_return_spawnpoints.append(VecToString(pSpot->pev->origin));
					thoth_return_spawnpoints.append(";");
				}
			}
			SetVar( Cmd.m_Params[1], thoth_return_spawnpoints, Event );
		}
		else ERROR_MISSING_PARMS;
	}
#endif

Look good to you MiB?

Granted, problem with the script side solution this would lead to, is that a script var can only hold about 10 spawn points, and mappers tend to like to make about a dozen of them per transition for some damned reason. :/

 

[PBarnum]

Is there a way to make it where after you exit a teleport, you are temporarily a non-solid? Until you are out of the teleport brush?

 

[Thothie]

No. But if you put multiple info_teleport_destination's for a trigger_teleport, in theory, the player will be teleported to one of them at random. To test the effectiveness of that, gather together in the Star Gate teleporter in the Shad Palace library.

Not feeling real safe with that, there's always my alternative: two teleporters right next to one another. Also, if you put the teleport destination well above the ground the fall usually stops people from testing the Heisenberg principle. Unlike spawning, players have more control over when they teleport.

 

[J-M v2.5.5]

No. But if you put multiple info_teleport_destination's for a trigger_teleport, in theory, the player will be teleported to one of them at random. To test the effectiveness of that, gather together in the Star Gate teleporter in the Shad Palace library.

This doesn't work either. Players get stuck mid-air in each other when they use the shad_palace teleporter (or any other teleporter for that matter, regardless of the number of destinations).

The info_teleport_destination entity has behaved similar to ms_player_spawn for years now. You can place as many of them as you like, the game will only teleport people to one of them.

One way of really fixing the issue is this: place player spawns in a trigger_teleport that, by means of a looping multi_manager and a bunch of trigger_changetarget entities, changes destination every 0.1 second or so.

That, or enough headroom.
What I meant by enough headroom: the amount of room above a spawn point should be at least that of the player height, because then you can just 'unstuck-jump'. If you look at ww3d, shad_palace, demontemple and nashalrath (see the image you posted), you'll notice that this isn't the case.

 

[Thothie]

I figured that, hence why I use the multiple teleporter method. Just hafta hope player's are smart enough to realize if someone just ran into the left teleporter, they should go into the right, if they wish to avoid being Jeff Goldblum'd.

I think we fixed this with the ms_player_spawn thanks to some enhancements to my ideas from MiB. I dunno if we can rig something similar with info_teleport_destination.

The info_teleport_destination entity has behaved similar to ms_player_spawn for years now. You can place as many of them as you like, the game will only teleport people to one of them.

This is actually not true, if the player transitions from another map, and the ms_player_spawn has the proper message setting, he'll get sent to a random ms_player_spawn. However, if the player transitions illegally (eg. changelevel) or the map has no transition to it (disconnected) then you get sent to the ms_player_begin, and there's no system for multiple ms_player_begin's.

 

[The Man In Black]

Oh, most definitely. ;-)

 

[Thothie]

Well go for it. Just be sure it checks for the destination name. Sending to any old info_teleport_destination within 256 units, regardless of name, would likely fubar some maps.

 

[The Man In Black]

Well duh ;-)

Wasn't planning on checking the 256 units, either.

 

[RockNRollJesus]

theres your problem... look at all those fencers

 

[zeus9860]

theres your problem... look at all those fencers

LoL, good point there, that might change soon though...