Question about FFA/TFFA spawn points.

[ZeroRaven]

Hey guys, I have a slightly noobish question for you.
In regards to FFA and TFFA spawn points, when making a map for multiple game types, do you put both the generic FFA spawn points as well as the Team based spawns into the same map? Or create 2 versions of the same map with the spawn difference?
I know its a noobish question but none of the tutorials I've found have helped me solve it.
And also just to verify what is the spawn point limit in JA? I remember hearing somewhere it was a fairly low number like 16?

[MoonDog]

I usually just place team based spawns only; in order to handle both situations. It's not a HUGE deal in JKA, but it's still a wise practice to carefully consider the amount of space and the layout of your level when placing your spawns. A common mistake for a community made competitive map is misunderstanding the importance of spawn placement.

 

As for the limit of spawns, I'm not sure. I know the entity limit is 1023( +1 Required Worldspawn ). 

[ZeroRaven]

Will the team based spawns also spawn normal FFA players then?
And again for my reference the spawns are info_player_start_blue and info_player_start_red correct? What is the info_player_start for then? SP?

[MoonDog]

info_player_start functions in MP as well, and can be used. A teamdeathmatch spawn will handle both tffa and ffa

[lil_binger]

It's not a noobish question at all.  It's a little more complicated than many people think.  Placing spawn points is as important as anything else when making a map.

 

As far as creating another map for ctf, I would consider if you want the players to have access to the entire map for ctf or are there areas that you don't want to be accessable for ctf gameplay.  Too many areas in a map for ctf will affect many things and could cause people not to use your map for ctf. 

 

The map I am working on, Binger's Bespin, I have been analyzing routes and keeping in mind where I want flag spawn points to be but I will be making a separate version of the map for ctf.  I'll be keeping red spawn points on the red sode and blue on the blue side.  In JK2 ctf, ctf_yavin is the most popular ctf map and many use the spawn points to kill their self if they are in enemy territory in order to get back to their base to defend their flag.  It's almost common practice to do that in JK2 so making Binger's Bespin I will keep that in mind and place the team spawn points in a matter consistent with ctf_yavin.

 

I may actually make 2-3 ctf versions for Binger's Bespin each with different flag points and possibly different routes.  I will make multiple versions to give other options for players and the version I think might work out the best might actually not be as playable as I think and maybe the 3rd ctf placement might be more challenging for players.

 

The ffa version I am making will have some team spawn points for tffa but it's possible a different version could be made to restrict access.  But then again I do have to watch my entity limit so depending on that number will determine if I will make a separate version for ffa.  I have lots of entities in my map already.  I have 70 path corners for the swtor ballon in my map alone.  A bunch of target_speakers, each tunnel I've made has an average of 3 trigger_push triggers and 3 target_push points.  If you are nowhere close to the entity limit in your map you have no worries.

 

info_player_start will allow anyone to spawn on the spawn point for ctf or ffa etc and I think is mainly used for sp.  At least that is how it works in JK2.  Having only info_player_deathmatch and the team spawns, loading the map in ctf players should not spawn in the deathmatch spawn points.  I am unsure if having the deathmatch spawns in tffa will allow any team member to spwan on that point.  I assume team players only spawn on team points if that is the case but I have not tested to see what happens (or at least I don't remember).

[ZeroRaven]

Well the map I'm working on is going to be designed for TFFA primarily, as will be noted in the color schemes. But I wanted to have it playable for basic FFA as well.
Not so much concerned with the CTF side of it personally.
So I'm tempted to try it out with the FFA/TFFA spawns in map this way I can better distinguish the two sides.

Now for another question. dynamic glows. I have a texture that I want to have a semi surrounding glow, like you would expect a flourescent light to create.
I.E. |fuzzy glow|light core|fuzzy glow|
The shader is as follows

 

{
               qer_editorimage textures/arena/bluelight.jpg
               q3map_surfacelight 10000
               q3map_backSplash 5 16
               q3map_nolightmap
               q3map_lightRGB 0.1 0.3 0.7
                {
                        map $whiteimage
                        blendFunc GL_DST_COLOR GL_ZERO
                        rgbGen const ( 0.10 0.30 0.70 )

               }
               {
                        map $whiteimage
                        blendFunc GL_ONE GL_ONE
                        rgbGen const ( 0.10 0.30 0.70 )
                        glow
               }
     }

 

Will a glow such as described only be visible based on the way the map is compiled?

[MoonDog]

 

 

The ffa version I am making will have some team spawn points for tffa but it's possible a different version could be made to restrict access.  But then again I do have to watch my entity limit so depending on that number will determine if I will make a separate version for ffa.  I have lots of entities in my map already.  I have 70 path corners for the swtor ballon in my map alone.  A bunch of target_speakers, each tunnel I've made has an average of 3 trigger_push triggers and 3 target_push points.  If you are nowhere close to the entity limit in your map you have no worries.

 

 

I doubt you have anything to worry about. That is a small handful of entities. I entity modded the plugin version of my FFA3 mod up to nearly 1,000 entities safely. I left a small cushion for projectiles and other gameplay entities, and never had any issues.

 

As for the other things you said, part of the reason I hate community made maps that "support ctf", is because the person who designed it thought CTF would work as an afterthought as long as the flags are placed linearly in fashion; with supporting logical spawns. It's simply not the case, and is a good deal more complicated than that.

[MoonDog]

Well the map I'm working on is going to be designed for TFFA primarily, as will be noted in the color schemes. But I wanted to have it playable for basic FFA as well.

Not so much concerned with the CTF side of it personally.

So I'm tempted to try it out with the FFA/TFFA spawns in map this way I can better distinguish the two sides.

 

Now for another question. dynamic glows. I have a texture that I want to have a semi surrounding glow, like you would expect a flourescent light to create.

I.E. |fuzzy glow|light core|fuzzy glow|

The shader is as follows

 

 

{

               qer_editorimage textures/arena/bluelight.jpg

               q3map_surfacelight 10000

               q3map_backSplash 5 16

               q3map_nolightmap

               q3map_lightRGB 0.1 0.3 0.7

                {

                        map $whiteimage

                        blendFunc GL_DST_COLOR GL_ZERO

                        rgbGen const ( 0.10 0.30 0.70 )

               }

               {

                        map $whiteimage

                        blendFunc GL_ONE GL_ONE

                        rgbGen const ( 0.10 0.30 0.70 )

                        glow

               }

     }

 

Will a glow such as described only be visible based on the way the map is compiled?

 

 

You can alter the dynamic glow part of the shader as freely as you like, testing different images, blends and values to your hearts content without recompiling. The surfacelight, however will require a recompile. They are baked directly into the lightmap, and therefor need to be recreated to see the results of an adjustment on that argument.

 

JKA doesn't have any sort of true primary dynamic lighting.

[Ping]

Spawn point placement is mostly irrelevant to TFFA. Making them symmetrical in any way, with one team only ever spawning on the one side of the map and the other team on the other, would be actually bad.

[lil_binger]

As for the other things you said, part of the reason I hate community made maps that "support ctf", is because the person who designed it thought CTF would work as an afterthought as long as the flags are placed linearly in fashion; with supporting logical spawns. It's simply not the case, and is a good deal more complicated than that.

 

 

At first the ctf for the map was an afterthought.  But not any more.  I have redesigned many connections to support ctf and taking more of a ctf approach to making the map than was originally intended.  It is more complicated than just linearly placing spawn points with supporting logical spawns, which was in my explanation above.  When I thought I would add ctf gameplay to the map I have started redesigning the map and paths to make ctf work and is more complicated than just adding some spawns.  If you would have kept up with the WIP for the map you could see how much has been redesigned to accomadate ctf.  I have totally redesigned some routes to take for ctf and I have many more ideas to make it work.  That is why I describe above to analyze routes and such for making a map work for ctf.  But I was only trying to describe what I was doing, in part, to help answer ZeroRaven's question.

 

I was also trying to stay on point some and not over complicate my answer for ZeroRaven trying to describe a little what I am doing with my map without explaining myself in detail which you seem to have a problem with Moondog.  I say analyze the map and paths because if you want it to work for ctf you don't want to just place linear flag points and team spawns.  There should be a reason for placing them in a map for making ctf work and be competitive / interesting. 

 

Ctf_yavin for JK2 is the most played ctf map for JK2.  And there are many reasons why it's the most played ctf map.  My map will never be a ctf yavin for ctf but I am trying my best to bring in some of the qualities of ctf_yavin to give ctf'ers a better experience but I am also keeping in mind it will also be for ffa however the ctf redesign has been helping the ffa version because it's allowing me to move players around the map better and quicker than what was designed previously. I have worked ctf into the mix now and will only benefit the ffa version of the map.

 

So ZeroRaven, it's not a noobish question and the question you have goes far beyond just placing spawn points.  I was only trying to describe what I was doing currently that might help with your decision but Moondog wants to pick at my answer because I didn't explain everything in detail because your question wasn't about ctf spawn points and I did not elaborate too much on ctf flag and spawn placements.  Your question didn't really talk about ctf and was mainly about tffa spawns.  So Moondog goes out of his way to pick at what I said rather than trying to stay on point with the thread and I go out of my way to have to try to defend what I said because Moondog misses the point of the thread and my answer.

[MoonDog]

You are very sensitive, and seem to be reacting based on a misconception. I was speaking in generalities to voice an opinion about design. I have not looked at any WIP threads here as of late, because mostly people like you going on tirades, such as you just did, when receiving actual criticism or an opinion counter to their own. 

 

I'm not sure what part of anything I said you misunderstood as any sort of personal attack at your work, but I have not even looked at it. Nor would I, given your little outburst. It discourages me from believing you'd be capable of holding any sort of meaningful discussion regarding design if I gave you real criticism. Unprofessional, counter-productive.

[ZeroRaven]

So during a test compile I recieved an error i've never seen:

************ ERROR ************
MAX_TW_VERTS (12) exceeded

Now most of the lighting in the map is coming from actual light source faces, and i've utilized this before so I dont think thats the problem.
What this error refers to I'm not sure since I can still test the map without any noticable issue.

Presently I'm at a loss.

[MoonDog]

So during a test compile I recieved an error i've never seen:

 

************ ERROR ************

MAX_TW_VERTS (12) exceeded

 

Now most of the lighting in the map is coming from actual light source faces, and i've utilized this before so I dont think thats the problem.

What this error refers to I'm not sure since I can still test the map without any noticable issue.

 

Presently I'm at a loss.

 

 

Do you have brushes that you've clipped a lot of faces onto?

[ZeroRaven]

@@MoonDog No I don't think I do. I used the cylinder tool to make a bending corner on a pipe, but I've used that before and had no issues. The only brushes I cleaved into only turned it into a pentagon, so i'm not sure what the error is.

[MoonDog]

@@MoonDog No I don't think I do. I used the cylinder tool to make a bending corner on a pipe, but I've used that before and had no issues. The only brushes I cleaved into only turned it into a pentagon, so i'm not sure what the error is.

 

 

 

Well, it's definitely an error defined in light trace.

 

 

#define MAX_TW_VERTS            12

 

 

typedef struct traceWinding_s
{
	vec4_t plane;
	int infoNum, numVerts;
	traceVert_t v[ MAX_TW_VERTS ];
}

 

void ClipTraceWinding( traceWinding_t *tw, vec4_t plane, traceWinding_t *front, traceWinding_t *back ){
	int i, j, k;
	int sides[ MAX_TW_VERTS ], counts[ 3 ] = { 0, 0, 0 };
	float dists[ MAX_TW_VERTS ];
	float frac;
	traceVert_t     *a, *b, mid;


	/* clear front and back */
	front->numVerts = 0;
	back->numVerts = 0;

	/* classify points */
	for ( i = 0; i < tw->numVerts; i++ )
	{
		dists[ i ] = DotProduct( tw->v[ i ].xyz, plane ) - plane[ 3 ];
		if ( dists[ i ] < -TW_ON_EPSILON ) {
			sides[ i ] = SIDE_BACK;
		}
		else if ( dists[ i ] > TW_ON_EPSILON ) {
			sides[ i ] = SIDE_FRONT;
		}
		else{
			sides[ i ] = SIDE_ON;
		}
		counts[ sides[ i ] ]++;
	}

	/* entirely on front? */
	if ( counts[ SIDE_BACK ] == 0 ) {
		memcpy( front, tw, sizeof( *front ) );
	}

	/* entirely on back? */
	else if ( counts[ SIDE_FRONT ] == 0 ) {
		memcpy( back, tw, sizeof( *back ) );
	}

	/* straddles the plane */
	else
	{
		/* setup front and back */
		memcpy( front, tw, sizeof( *front ) );
		front->numVerts = 0;
		memcpy( back, tw, sizeof( *back ) );
		back->numVerts = 0;

		/* split the winding */
		for ( i = 0; i < tw->numVerts; i++ )
		{
			/* radix */
			j = ( i + 1 ) % tw->numVerts;

			/* get verts */
			a = &tw->v[ i ];
			b = &tw->v[ j ];

			/* handle points on the splitting plane */
			switch ( sides[ i ] )
			{
			case SIDE_FRONT:
				if ( front->numVerts >= MAX_TW_VERTS ) {
					Error( "MAX_TW_VERTS (%d) exceeded", MAX_TW_VERTS );
				}
				front->v[ front->numVerts++ ] = *a;
				break;

			case SIDE_BACK:
				if ( back->numVerts >= MAX_TW_VERTS ) {
					Error( "MAX_TW_VERTS (%d) exceeded", MAX_TW_VERTS );
				}
				back->v[ back->numVerts++ ] = *a;
				break;

			case SIDE_ON:
				if ( front->numVerts >= MAX_TW_VERTS || back->numVerts >= MAX_TW_VERTS ) {
					Error( "MAX_TW_VERTS (%d) exceeded", MAX_TW_VERTS );
				}
				front->v[ front->numVerts++ ] = *a;
				back->v[ back->numVerts++ ] = *a;
				continue;
			}

			/* check next point to see if we need to split the edge */
			if ( sides[ j ] == SIDE_ON || sides[ j ] == sides[ i ] ) {
				continue;
			}

			/* check limit */
			if ( front->numVerts >= MAX_TW_VERTS || back->numVerts >= MAX_TW_VERTS ) {
				Error( "MAX_TW_VERTS (%d) exceeded", MAX_TW_VERTS );
			}

			/* generate a split point */
			frac = dists[ i ] / ( dists[ i ] - dists[ j ] );
			for ( k = 0; k < 3; k++ )
			{
				/* minimize fp precision errors */
				if ( plane[ k ] == 1.0f ) {
					mid.xyz[ k ] = plane[ 3 ];
				}
				else if ( plane[ k ] == -1.0f ) {
					mid.xyz[ k ] = -plane[ 3 ];
				}
				else{
					mid.xyz[ k ] = a->xyz[ k ] + frac * ( b->xyz[ k ] - a->xyz[ k ] );
				}

				/* set texture coordinates */
				if ( k > 1 ) {
					continue;
				}
				mid.st[ 0 ] = a->st[ 0 ] + frac * ( b->st[ 0 ] - a->st[ 0 ] );
				mid.st[ 1 ] = a->st[ 1 ] + frac * ( b->st[ 1 ] - a->st[ 1 ] );
			}

			/* copy midpoint to front and back polygons */
			front->v[ front->numVerts++ ] = mid;
			back->v[ back->numVerts++ ] = mid;
		}
	}
}

 

 

 

I think you've got some complex objects that need to be split up into multiple brushes/meshes