How to force default spawn locations before scripting works

[Detoeni]

mutltiple spawnpoint groups

Ah, Id missed that bit, I thought folks were spawning at completely the wrong place, rather than the wrong choice of place.

Thanks.

[G0-Gerbil]

Bah ok I’ll stop trolling

In HD Allies can spawn at 3 different locations - naturally 1 is better than the other 2, but like Fueldump you often want XP whores to spawn back and build the defences. Automatically spawning at this location was the issue for me - you’d end up maybe 1 minute’s worth of running from the action

But, to summarize, generally in multiple spawns, pulling in the issues from supply depot (probably!):

1. Having multiple team_WOLF_objectives means you use setautospawn. You MUST do these before players spawn to ensure correct behaviour (IE using a wait of < 300 in your spawn {} )

2. setstating invisible a team_WOLF_objective but making the spawn points it’s attached to still have the startactive flag set will NOT prevent people spawning there - as reyalP noted elsewhere you can still set your spawn point via the console. In this case you must setstate invisible the tWo as well as ensure the spawns don’t use the startactive flag.

Since it also turns out you can set your autospawn location to that of an enemy’s tWo (you won’t spawn there, but you’ll use your spawn points closest to it) I am guessing this is how the ‘oasis old city spawn’ exploit works - as Allies you set your spawn point to that of the Axis base, hence you pop up in the health / ammo cabinet room instead. Off the top of my head I can’t think of any other official map that this might be useful on though, which is a shame.

[SCDS_reyalP]

ince it also turns out you can set your autospawn location to that of an enemy’s tWo (you won’t spawn there, but you’ll use your spawn points closest to it) I am guessing this is how the ‘oasis old city spawn’ exploit works - as Allies you set your spawn point to that of the Axis base, hence you pop up in the health / ammo cabinet room instead. Off the top of my head I can’t think of any other official map that this might be useful on though, which is a shame.

I never thought of this as an exploit :moo:

Theres a good one for axis on oasis too… if you use setspawnpt 4 you can spawn in the side room, so you don’t get blocked and airstriked at spawn. If there are a lot of people, you may also spawn on top. (allies use setspawnpt 1 for the ammo racks)

There is also a good one for allies, on radar. If you pick the CP manually, when the CP is blown, you will spawn at the start instead of the flag, even if your team has the flag. If you use setspawnpt 5 you will spawn in the order CP - FLAG - REAR, which is far better.

[Ifurita]

I don’t really think of this as an exploit. Spawn scripts have been doing this since et beta testing

[mortis]

The supplydepot script had two problems:

1. The active autospawn for Allies at the start of the map called on the “foward bunker”, not the “allied start” entity.

2. The wait state was longer than 300ms.

During warmup, an allied player caps the flag, causing force_allied to be executed. Regardless of whether the flag is recaptured by axis during the warmup (for some reason) Wolfy thinks that the Allies own the flag.

The game spawns. Allies own the foward flag and spawn at 300ms. At 500ms, the autospawn is reset to Axis, but not until after the allies have spawned. Allies still actually spawn in the “allied start” location, but Axis spawn in the fallback spawn, because the foward spawn is not active for them. In the meantime, the allies overrun the spawn and cap the flag.

I also fixed the ‘magic hovering gold’ bug by cleaning up the setstate invisible and adding a short wait time to put it into the next server frame. The gold does not hang out in midair anymore after the allies drive away in the truck.

In any case, the fixed scripts are here:

/quote from my previous thread below

get your working Supplydepot scripts here:

SupplyDepot http://www.bsdterritory.com/img/Mortis/supplydepot.script

SupplyDepot2 http://www.bsdterritory.com/img/Mortis/supplydepot2.script

You need to place them in /Wolfy/etpro/etpromapscripts and do a soft restart for them to take effect.

Your server needs to have set b_mapscriptdirectory “etpromapscripts”

No, it doesn’t work for Shrub. You would need a new pk3 for that. Ginc (the author) has given his blessing to my repair work.

–Mortis

[SCDS_reyalP]

Dear lord, do we really need to re-hash this ? I don’t want to start another flamefest, but I also don’t want to let factual errors stand uncorrected.

If you want to argue, please either quote specific lines of code or steps to produce behavior that contradicts what what I have stated. If you do either of those, I’ll be happy to admit that I am wrong, and happy to have learned something.

The supplydepot script had two problems:

1. The active autospawn for Allies at the start of the map called on the “foward bunker”, not the “allied start” entity.

This isn’t a problem. Autospawn refers to a team_WOLF_objective entity (TWO). The game tries to spawn you as near as possible to the given TWO. In the case of the allies starting in supplydepot, their spawn points are not enabled at the flag, and thus “as near as possible” to the forward bunker TWO is the initial spawn.

Where one teams autospawn is set has absolutely no impact on where the other team spawns. The game doesn’t take that into consideration at all (and yes, I can point you to the exact lines of code in the game that control these things.)

During warmup, an allied player caps the flag, causing force_allied to be executed. Regardless of whether the flag is recaptured by axis during the warmup (for some reason) Wolfy thinks that the Allies own the flag.

No, it doesn’t. warmup ending resets all the entities. The only effect of grabbing the flag in warmup is it means the other team can’t use the UI to select that particular spawnpoint. That is all. Again, if you want me to point out exactly when and where this happens, I can do that. A clients manually selected spawnpoint is preserved through restart, but this has no bearing on where autospawn spawns them. It only controls whether they autospawn, or use a specific spawn point.

Even if you don’t trust my ability to understand the gamecode, stop and think about what would happen if warmup did carry over to to game start. Clearly, much more than just the spawn flags would cause trouble.

Again, if anyone wants to present reasoned, supported arguments as to why any of the above is wrong, please do so. If you are merely going to claim it is wrong, handwave, or spread insults, please don’t bother. We’ve had quite enough of that.

I also fixed the ‘magic hovering gold’ bug by cleaning up the setstate invisible and adding a short wait time to put it into the next server frame. The gold does not hang out in midair anymore after the allies drive away in the truck.

Good work indeed.

[mortis]

LOL, I mean we obviously did solve the issue, but I never did try it with just the wait time adjusted, for comparison.

I was just speculating on why I thought the game was triggering the back spawn, based on my limited understanding of the game engine. Reyal does have a super strong grasp on the game engine, so I’m willing to go on faith on his recommendations.

:drink:

My remaining question is this:

If it is just a timing issue, wouldn’t the error crop up everytime?

For example, if the allies do not cap the flag during warmup, the error does not occur; although sometimes if an Axis player selects the back spawn intentionally, it could cause the whole team to spawn back, even if the foward flag is not capped.

What I would like to know specifically is an explanation of why the spawn works normally when noone touches the flag nor spawns back, and screws up when capped. If I understand your explanation correctly, don’t all the entities reset at the end of warmup? I guess what I am asking is if they reset, why does it only fail under those circumstances?

–Mortis

[SCDS_reyalP]

For example, if the allies do not cap the flag during warmup, the error does not occur; although sometimes if an Axis player selects the back spawn intentionally, it could cause the whole team to spawn back, even if the foward flag is not capped.

It did in fact happen when no one grabbed the flag.

edit:
I’m pretty sure I even have demos of this from matches, where twl had a rule against taking the flag in warmup. Note that if you manually clicked on the flag, then you wouldn’t spawn back, and capping the flag prevents you from doing this, unless you use a setspawnpt script.

[G0-Gerbil]

So erm let me get this straight? reyalP alone was correct in the supplydepot thingy? Heh… I won’t make an insult, but I will smile smugly

As for why it doesn’t crop up more often - I dunno, it’s weird. This is the first time I’ve encountered it and I’ve done a fair few maps (granted not many of them public), and in theory for each new version you build it might occur (HD is well over 100 builds for example). There’s clearly something else going on other than just ‘random’, but even 99% chance of it working right is not as good as 100%, which is what you get with reyalP’s fix. Bear in mind too, that this bug is specific to a particular build - hence if a released map does not immediately display this characteristic, based on what I’ve seen, it never will - so I don’t think it’s something to worry about cropping up on established maps that have been working fine for yonks.

As for those other possible spawnpoints in the official maps, blimey, I never knew!
I only even heard of them the other day, which goes to show how far behind on proper play I am ! I consider them an ‘exploit’ because they are what I would consider ‘undocumented’ (IE not readily available knowledge to the average player - certainly in all my ET hours I’ve NEVER seen any of these used, although I’m probably about to write a quick spawn script and try them out for myself now!), not to mention probably not intended by the map makers, otherwise they would have had a nice click-able TWO icon on the command map.

[EB1]

@Go-Gerbil: To ASSUME only makes an ASS out of U and ME. Get it ? ass-u-me ?

Go to the next page and read.

[SCDS_reyalP]

As for why it doesn’t crop up more often - I dunno, it’s weird. This is the first time I’ve encountered it and I’ve done a fair few maps (granted not many of them public), and in theory for each new version you build it might occur (HD is well over 100 builds for example).

My WAG is that it related to your map cleanup. Remember the players start spawning at 300ms. If the the clients take longer to get things straight (or the server engine to be ready to deal with them), there is more chance they won’t get in tell the autospawn is set. I’m sure everyone is familiar with the lag spike at map reset…

Now the above is pure speculation, but you could verify (or disprove) it looking at the console output on a large server.

EB:
If you could articulate what the other problem with supply depot was, with enough detail to reproduce it, that would interesting. We might all learn something. As I stated before, I’m open to the idea there are other problems, but as yet haven’t seen any described in a way that fits the facts.

If there is a post that describes it (which I might easly have missed in the noise) feel free to point it out to me. The goal here isn’t to make anyone look stupid, but to expand everyones understanding of the game, so we can all make better maps.

[G0-Gerbil]

The best way to drop something is generally not to respond
OK, for fun, in the other thread, detail exactly what you think was wrong (and how to replicate) and what you did to fix it, preferably with proof. - unfortunately re-reading that thread didn’t leave me with an exact idea of what you were going on about.
After all, assuming you are right, then the clearer the answer the better, since it’ll help people with similar problems in the future.

[EB1]

@ReyalP ----I agree completely that we are here to help, that is why I take such drastic/useless postings so seriously. Also, I appreciate the way you have approached this.
Now with that said.

Now problems do not have to nec. be engine related, they could be scripting(as u know). Between the engine following script and calculating everything and keeping things in check, sometimes- somethings are missed. With this being related in; I had changed the autospawn to the ‘allied start’ (in supply depot) to alleviate any sort of re-curring problem for the autospawns as it is NOT a necessity to have them called to the same location. Now having the 150wait and the autospawn change (in a different but well thought order), the engine can only mess up if a timing issue comes into play(i.e. the flag being grabbed at the exact 1/1000 of a second causing this type of problem). Even setting the accums in the game_manger would be another good thing for the reset **if applicable.
Bugs and problems will most likely be around for this game forever if not a very long time.

Please notice the wait 500 prior to the spawn, now these are the original .SCRIPTS included in the pak0.pk3. [Which I think remain the same in pak1 and pak2]
Radar =wait of 500

wait 500
		// spawns:
		// Abandoned Villa
		// Forward Bunker
		// Lower Warehouse
		setautospawn "Forward Bunker" 1
		setautospawn "Forward Bunker" 0

Oasis =wait of 150

// Set autospawn markers <team (0 = axis, 1 = allies)> <message key of marker>
		// Spawns on siwa:
		// Axis Garrison
		// Allied Camp
		// Old City
		wait 150

		setautospawn "Old City"			1
		setautospawn "Old City"			0

Battery =wait of 50

wait 50
		setautospawn	"West Bunker"	1
		setautospawn	"West Bunker"	0

Goldrush =wait of 500

wait 500
		setautospawn	"Tank Depot"	0
		setautospawn	"Allied Spawn"	1

Railgun =Different approach

after it runs through seperated command lines:
trigger allies_set_base
	{setautospawn	"Allied Camp"	1}
trigger allies_set_depot
	{setautospawn	"Depot Yard"	1}
trigger axis_set_base
	{setautospawn	"Axis Construction Site"	0}
trigger axis_set_depot
	{setautospawn	"Depot Yard"	0}

Neither-team owns the depot flag at start.

Fueldump =wait of 500

// Setup the auto spawn points for the map
		wait 500
		setautospawn "Allied Entrance Spawn" 1
		setautospawn "Tunnel Store Room" 0

3 of 6 original maps have a wait of 500 just prior to setting autospawns.
Now none of these quoted below have any wait times prior to the code quoted (within the script).

Now even with the wait of 500 in a few places, there are no errors for these maps except in extreme circumstances, correct ?
Also notice the wait times in conjunction with the autospawn names being the same and different.
Now changing a starting autospawn name is fine to do as both are not needed to be of the same locale.
If I should explain more, just let me know. - I feel these snippets relate well to this situation.

As for the Supplydepot recreation:
The main thing I remember is that the bug still occured with ONLY the wait changed to 150. So use the same map and script, just change the wait prior to spawn to 150.
You may have to test for awhile and with different situations…it will recur. I will test it as time allows me to do so this week and return the specifics.

[G0-Gerbil]

Now even with the wait of 500 in a few places, there are no errors for these maps except in extreme circumstances, correct ?
As far as I’m aware, there are NO problems, for much the same reason that it’s taken me close to 100 builds of Helmsdeep to ever see this problem. It’s build-specific, and more often than not the build works fine. Hence, for maps where it does work ‘automatically’, the wait before setautospawn is irrelevant. However, it CAN potentially, on a per-build basis, go wrong, as happened to me. reyalP pointed out why, and hence to prevent that particular kind of error happening, you should NEVER try to set your default initial autospawns with a wait > (roughly) 200.
My point is that your snippets from the official map scripts merely tallies with what I’ve found out, albiet it took me the entire time ET has been out to have it happen.
reyalP went through the source code and found the EXACT reason that it can go wrong.
However, why it normally doesn’t go wrong is pure conjecture - it might be something to do with the order the entities were created in, for example, or it may not. However, it can go wrong, and it not going wrong should merely be thought of as ‘lucky’, not as the norm (even if it appears to be!).

My reading of supply depot, is simply that the spawnpoints are set to be active, but the TWO is invisible. Capturing the flag makes it visible, people click on it, hence at round start you can spawn in the ‘wrong’ place. This is IMO nothing whatsoever to do with the default spawn ‘issue’ as covered here. This is a seperate, incorrectly built map and is not a bug of the engine. To test my theory, the following should happen in the original supply depot:

Scenario A:

1. The team captures the flag in warmup, and clicks on the TWO in the limbo screen.
2. At map start, that team then spawns in the wrong place, IE nearer the flag they should be defending, giving them the edge.
   This is, as far as I read it, what actually happens and is what people complain about.

Scenario B:

1. The team sets it’s spawnpoint to the location that would be flag’s TWO via scripting, during warmup. The flag is NOT captured.
2. At map start, that team then spawns in the wrong place, IE nearer the flag they should be defending, giving them the edge.
   If someone who actually has supply depot can test this and it happens then the bug is as I’ve said.

If this was the case, then you’d need, via scripting, to alertentity the offending teams’ spawnpoints BEFORE players spawn (IE wait < 200 or so) and alter whatever further togglings of those spawns happens in the rest of the script. I believe this is what reyalP was referring to towards the end of the other thread.

All entities are reset at map start from warmup. The only thing that stickies are stuff like classes and the all-important spawn location - which can be set via the console regardless of map / flag states.
Hence the issue IMO boils down to either the default TWO (which it clearly isn’t in this case), or the start state of the offending spawns, which could be proved by the above scenario B test.

I do not understand your references:

I had changed the autospawn to the ‘allied start’ (in supply depot) to alleviate any sort of re-curring problem for the autospawns as it is NOT a necessity to have them called to the same location.

There’s absolutely no problem with autospawns being set to the same place. Also note that via console commands, spawning at other locations (eg where the supposed offending flag TWO is) is still possible, and hence the problem remains.

the engine can only mess up if a timing issue comes into play(i.e. the flag being grabbed at the exact 1/1000 of a second causing this type of problem)

I don’t really see what possible timing issue there is here, could you explain more please?

Even setting the accums in the game_manger would be another good thing for the reset **if applicable

While I agree it’s good general practice to clear your accums at round start, it’s not as far as I’m aware an essential - all accums are defaulted to zero at map / warmup start. Naturally if you need a non-zero default…

As for the Supplydepot recreation:
The main thing I remember is that the bug still occured with ONLY the wait changed to 150.

Indeed - the irony here is that it looks like reyalP actually found another, entirely unrelated (to that map) bug regarding spawning in the wrong place. Amazing really - and definately worth bearing in mind for any and all future custom maps that have multiple spawn choices at start - use a wait of 150 and all will always be well in that regard I can’t complain since his discovery is what immediately fixed my bug. But the crux of the supply depot bug to me is that spawn point entities themselves are set to be active, so setting your default spawn (which always overrides the setautospawn command) in warmup allows you to spawn there. This is what reyalP was commenting on towards the end of the thread.

Now, out of curiosity and conciseness, what changes did you make to the supply depot script that fixed the problem? (Ideally a before / after comparison would be acetastic) I’m not sure - you never explicitly state it in the thread, so clarification is always good.

[G0-Gerbil]

In fact, one interesting test might be to take out all the setautospawn commands entirely and see where ET chooses to spawn players on it’s own - might shed some light into the interaction between the spawn points and any scripting that may override ET’s initial behaviour.

[EB1]

he’s trying to pick fights. he quotes me and agrees with me but he thinks he is disagreeing with me. wth ?
Go-Gerbil, I do not know what your problem is but you need to stop.

[edit] Are you blind ? >>>

I had changed the autospawn to the ‘allied start’ (in supply depot) ----|---- So use the same map and script, just change the wait prior to spawn to 150.
You may have to test for awhile and with different situations…it will recur.

[/edit]
That supply Depot type bug has happened in radar and oasis…you need to stop before you get yourself in deeper. Please regain your dignity and sit back and breath, k ?
{ I am choosing to ignore Go-gerbils posts from here, I am here to help out, not be hassled. }

Back to subject.

[mortis]

The two changes I made in supplydepot that affected the spawn issue are:

1. Reduced wait time to 150ms.

2. Set autospawn to “Allied Start” instead of “Foward Bunker”.

One of these two changes, or both, must be the reason, since they are the only two things that I changed to fix that bug.

No need to argue about it though, we could easily make test versions with just the timing changed and see what effect that has on spawning, and whether the susbsequent spawns / foward autospawn and permanent capture work properly.

		// Set starting spawns
		// The wait command after is VERY IMPORTANT for correct spawns!
		wait 150
		setautospawn	"Forward Bunker Spawn"	0
		setautospawn	"Allied Start"	1
		wait 350

–Mortis

[G0-Gerbil]

{ I am choosing to ignore Go-gerbils posts from here, I am here to help out, not be hassled. }
And yet you continue to reply
So your fix was solely to change the autospawn?

Yet… the ‘correct’ fix involves changing the default autospawn, then changing the timing so that it actually works.
Mortis - since you actually seem to care about fixing the problem rather than being hell-bent on ‘proving’ yourself right (despite even 1% of anything resembling proof from EB - man he’s got to learn the art of proof!), can I ask you this:

With your script fix, what happens if someone on allies uses the console to spawn at the forward bunker?
I believe that your script fix, while apparently working, only masks (admittedly by far) the most common way of reproduciong the bug - IE if clanners know how, they can still force the spawn locations bypassing the actual flag capture entirely - in otherwords those in the know could still make it happen which is, from what I gather, basically a map exploit on a popular map.

I’m the first to admit I’ve not even looked at the map properly myself, yet given how spawnpoints work, I’m reasonably sure that if the offending spawn points themselves are still active, then the exploit could still be replicated, given what reyalP and others have proved can happen via console commands and TWOs.

[mortis]

I haven’t tried setting the spawn via the console, although I did try capturing the flag manually and then setting the spawn point via the limbo menu (clicking the flag). That should cause the same eefect as setting it via the console, correct?

Doing this (in a few trials) did not produce the bad spawn effect, although I will try this again tonight when I get home from work and see how / if I can trip up the spawning.

[Ifurita]

That should cause the same eefect as setting it via the console, correct?

No, there are spawn points you cannot get to via the limbo menu (e.g., Ammo racks on Oasis, side rooms in Axis Garrison on Oasis)