CTF_red/blue flags returnable to multiple locations ...


(Ifurita) #1

CTF_red/blue flags returnable to multiple locations in no particular order. I want the attacking team to grab one of two objectives, transport them to a North and South launch pad, which will then setstate a func_explosive to default, allowing an engy to plant and destroy the rocket.

If I deliver warhead1 to the south rocket and warhead2 to the north rocket, it works beautifully. However, if I deliver warhead1 to the north rocket, the south func_explosive uncovers.

The problem I am having is figuring out how to make the game recognize which launch site I’ve delivered to obj to. The Trigger_flagonly_multiple recognizes the ‘flag cap’, but as far as I can tell, is only able to execute the script associated with each obj. Here’s what I have so far:

the death routines and the scripts immediately following were my stab at using bitset arguments, but they don’t work since that line would be executed irregardless of location.


// AXIS OBJECTIVES ================================================

//Warhead 1
warhead1_script //enter this as the scriptname value for the team_CTF_red/blueflag entity
{
	spawn
	{
		wait 200
		setstate warhead1_red default
		setstate south_rocket_dyno invisible
	}

	trigger stolen
	{
		setstate warhead1_cm_marker invisible
	}

	trigger returned
	{
		setstate warhead1_cm_marker default
	}

	trigger captured
		{
		wm_announce "The Axis have delivered a warhead to the South Rocket"
		setstate warhead1_red invisible
		setstate warhead1_dropoff invisible
		setstate south_rocket_dyno default

		wm_objective_status 		3 0 1
		wm_objective_status 		3 1 2
	}
}
south_rocket_obj //enter this as the scriptname value for the single trigger_flagonly_multiples entity 
{	
	death
	{
		globalaccum 1 bitset 1

		trigger south_rocket_dyno_activation south_dyno_swap			
	}
}

south_rocket_dyno_activation
{
	south_dynoswap
	{
		globalaccum 1 abort_if_not_bitset 1

		setstate warhead1_red invisible
		setstate south_rocket_dyno default
		setstate south_rocket_cm_marker default
	}
}

//Warhead 2
warhead2_script
{
	spawn
	{
		wait 200
		setstate warhead2_dropoff invisible 
		setstate north_rocket_dyno invisible
	}

	trigger stolen
	{
		setstate warhead2_cm_marker invisible
	}

	trigger returned
	{
		setstate warhead2_cm_marker default
	}

	trigger captured
	{
		wm_announce "The Axis have delivered a warhead to the North Rocket"
		setstate warhead2_red invisible
		setstate warhead2_dropoff default
		setstate north_rocket_dyno default

		wm_objective_status 		5 0 1
		wm_objective_status 		5 1 2
	}
}

north_rocket_obj //enter this as the scriptname value for the single trigger_flagonly_multiples entity 
{	
	death
	{
		globalaccum 1 bitset 2

		trigger north_rocket_dyno_activation north_dyno_swap			
	}
}

north_rocket_dyno_activation
{
	north_dynoswap
	{
		globalaccum 1 abort_if_not_bitset 2

		setstate warhead2_red invisible
		setstate north_rocket_dyno default
		setstate north_rocket_cm_marker default
	}
}


(G0-Gerbil) #2

Well, as far as I can tell you have the following scenario:

2 different carryable objectives, with seperate scripts.
2 seperate destinations, with seperate scripts.

What you should be able to do quite simply, is:

When an objective is delivered:

  • The destination script kills itself - setstate or kill should be fine. This is to prevent it being delivered to again.
  • The objective script calls a function in game_manager. This increments a ’ delivered’ accum. This function then does a:

accum <X> abort_if_less_than 2

and after that you have your 'make destroyable area revealed code.

From the quick glance I did at your script, the only difference I’d say from yours to mine is you are using bitset on a globalaccum, while I’m doing normal incremental counting on a game_manager accum (although that’s a throwback to RTCW when I didn’t have gloibalaccums, you kids never know how good you’ve got it ;)). Also, I tend to funnel most seperate events with a common end result to game_manager. By the same token I also usually have an event_manager script that all target_script_triggers call and then relay the messages, due to seperate script_triggers invoking seperate instantiations of the same script.


(G0-Gerbil) #3

Actually I take that back - you are using each <?>_rocket_dyno_activation script to compare only against the other one’s set bit.
I’d definately funnel them both into a single script which checks for both bitsets before making the dyno area visible.
It’s not that what you are doing is inherently wrong, it should work, but working on a single routine that checks both bits makes bug-tracking a bit simpler.


(Ifurita) #4
  1. Does the scriptname in the CTF_red/blue_flag have to match the scriptname in a team_flagonly_multiple
  2. If not, at what point/event does the script in the T_F_M execute?

Thanks


(sock) #5

I assume this is what you wanted …

2 team flags (rocket parts) delivered to 2 different locations (rockets) in any order and then something happening depending on a team flag (rocket part) being delivered?

If so then this example might help. Ive not actually tested this on a live server with loads of players but it should work fine as its mainly based on the radar script.

http://www.planetquake.com/simland/ldr1_1/samplemap08c.htm

Sock
:moo:

EDIT: One thing about the sample above is the timing of things. It bothers me that the “capture” routine might happen before the exit point trigger routine and then it would not work. Its a wierd setup because 2 routines are being triggered at the same time and there needs to be way to know which one is being fired first.


(sock) #6

Ok, I’ve thought about it again and found a better scirpt solution to my original sample map. I will leave the html page till tomorrow with the old version. This version ignores the “capture” function because its not precise enough and seems to conflict with the “trigger_flagonly_multiple” entities anyway.

This whole script is still based around both parts being transported being the same type of object and only one team doing the transporting of the objectives.

Here’s the updated version:

// ============================================================================
game_manager 
{ 
	spawn
	{
		accum 1 set 0				// Set counter for radar equipment
		wait 50
		setstate rocket1 invisible		// Hide final targets
		setstate rocket2 invisible
	}
	
	trigger final_check
	{
		accum 1 inc 1				// One radarbox home
		accum 1 abort_if_not_equal 2		// all complete??
		wm_announce	"Allies have secured ALL Radar Boxes!"
	}	
} 

// ============================================================================
// Visual Clues for drop off points
// ============================================================================
radarbox1
{
	spawn
	{
		wait 50
		accum 1 set 0				// once only trigger
		setstate radarbox1 invisible		// Show radarbox
		setstate radarbox1trans default		// Hide red marker
	}

	trigger visible
	{
		accum 1 abort_if_not_equal 0		// Only use once
		setstate radarbox1 default		// Show radarbox
		setstate radarbox1trans invisible	// Hide red marker
		setstate rocket1 default		// Show final target
		wm_announce	"Allies have secured the Radar Box 1!"
		accum 1 set 1				// Do not use this function again
	}
}

radarbox2
{
	spawn
	{
		wait 50
		accum 1 set 0				// Once only trigger
		setstate radarbox2 invisible		// Hide radarbox
		setstate radarbox2trans default		// Show red marker
	}

	trigger visible
	{
		accum 1 abort_if_not_equal 0		// Only use once
		setstate radarbox2 default		// Show radarbox
		setstate radarbox2trans invisible	// Hide red marker
		setstate rocket2 default		// Show final target
		wm_announce	"Allies have secured the Radar Box 2!"
		accum 1 set 1				// Do not use this function again
	}
}

// ============================================================================
// Pick up point for Radar Boxes
// ============================================================================
radarbox
{
	trigger stolen
	{
		setstate radarbox invisible		// hide current radarbox
	}

	trigger returned
	{
		setstate radarbox default		// Show current radarbox
	}
}

// ============================================================================
// Exit Points - Trigger brushes
// ============================================================================
exitpoint1
{
	death
	{
		trigger radarbox1 visible		// Perform exit1 tasks
		trigger game_manager final_check	// Inc counter game counter
		wm_announce	"ExitPoint 1!"
	}
}

exitpoint2
{
	death
	{
		trigger radarbox2 visible		// Perform exit2 tasks
		trigger game_manager final_check	// Inc counter game counter
		wm_announce	"ExitPoint 2!"
	}
}

Sock
:moo:


(sock) #7

I will leave the html page till tomorrow with the old version.

Web site has been updated with new script. Ifurita, I assume this sample did not help by lack of reply. Good luck with your project.

Sock
:moo:


(Ifurita) #8

Actually:

From Mean Mr Mustard, who is working with me on this

I took a look at sock’s sample map. Works like a charm (much better than what I was trying to do…) He’s got it set up that the ‘parts’ are stolen from the same location (ala: goldrush) but can be delivered to either of two locations.

I took a break from the scripting and was playing with brushwork and terrain.


(sock) #9

Perfect, thanks for letting me know I was getting restless wondering if the script sample was what you wanted or not. :smiley:

I found your idea a good variant on the existing trigger_multiple_flag system which I did not really get that involved in during development. Look forward to seeing your map once its finished.

Sock
:moo:


(Ifurita) #10

That makes 3 of us. :stuck_out_tongue: I’m busy relearning everything I forgot since the last map. Very interesting working with someone else on a map though


(Erik-Ftn) #11

When experimenting for this:

http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=5513

I found that “death” always preceeded “captured” and concluded that its because “death” is at the actual delivery point entity.


(Ifurita) #12

In fact, I looked for your thread first, but didn’t find it so I made my own :wink:


(Mean Mr. Mustard) #13

Very interesting working with someone else on a map though

Is that good or bad??? :stuck_out_tongue:


(Ifurita) #14

I guess it depends on who you’re working with