How to force default spawn locations before scripting works

(G0-Gerbil) #1

As we all know (and love), you have to leave a little time delay in the spawn{} of game_manager before you can call certain commands.
One of the things that you have to put after the wait are the wonderful

setautospawn

commands.
Now, my problem is, at map start, this means everyone spawns before the default spawn locations can be specified. And unfortunately, the engine is now guessing which spawn point people would like to appear at for the first wave. And it’s getting it wrong!

So, at map start in Helmsdeep, everyone on allies spawns in the caves and there’s bugger all they can do about it. Naturally this is not good.

What are my options? I’m going to try rebuilding the map with the team_WOLF_objective entities in different orders in the .MAP to see if that makes a difference to ET’s guess. I can (if I really have to) mark the cave spawns as ‘not startable’ until after a second or so of the map start, but this is a bit unfair on those who like to XP whore and go and build the defences while the rest of the team plays properly.

How come this isn’t a problem in any of the other maps, IE what’s the secret? :slight_smile:

(Ifurita) #2
  1. Have you tried setting the other TWO’s/spawn points invisible until after the game starts
  2. Have you tried setting the allied setautospawn as the axis starting point? or even creating an inactive allied two at the axis start and setting that as your default autospawn?
(G0-Gerbil) #3

I think you are missing the point - you can’t specify an autospawn until a fraction of a second into the map start, at which point everyone has already spawned.
I’m trying to find out what determines how ET chooses this first ‘default’ spawn location.

The things you suggest can’t be done script-wise until after the brief gap as well, hence they’d only kick in after the initial spawn, so it leaves you no better off than before (other than I can mark the actual spawn points themselves as not available to start with because that’s an entity key value - nowt to do with scripting - but I would rather avoid that if possible).

Thanks for having a think though :slight_smile:

(Ifurita) #4

I’m still curious about setting up a dummy spawnpoint though. I did the objective scripting for Remagen, given it’s a long linear map, but I set the allied spawn point as North Bank, even though that spawn point doesn’t become active until 3-4 phases later, never change the setautospawn, and the allies spawn correctly, progressively spawning further down the bridge as objectives are completed.

(G0-Gerbil) #5

Ah I follow what you are saying. It’s a seperate issue though. Can allies choose their spawn points at map start though?
Even without my other issue I couldn’t do what you are suggesting for HD because it’s not linear - you can never guarantee that the ‘furthest into map’ spawns are ‘furthest distance-wise from start’ spawns.

I just tried manually ordering my team_WOLF_objectives in the .MAP file.
With the following order:
Fort - South Valley - Caves you default to the Fort in the first wave
South Valley - Fort - Caves you still default to the Fort in the first wave :s

Still, at least that’s better than the caves, but puzzling nonetheless :slight_smile:

(SCDS_reyalP) #6

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

Players spawn after 6 frames (300). As long as you set your autospawn before that you are fine.
edit: this post, if you don’t want to wade through the garbage.
http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=11034#106577

(G0-Gerbil) #7

Marry me reyalP :smiley:

BTW funny thread - guess some people don’t like being proven wrong, even if it would help others :s
Anyway there’s one for the book - use a wait of 150. Dunno why I started using 500, but then it’s more strange that I’ve never had a problem with this before.
Still, case closed, and all’s well that ends well.

(Ifurita) #8

\o/

(SCDS_reyalP) #9

A few of the official maps used longer waits in their scripts. Those got copy/pasted into everyones maps. If the entity order is right, it ends not making any difference.

(G0-Gerbil) #10

I guess - and we know entity order in the .MAP file is irrelevant to what happens in the BSP so I’m not entirely sure why I posted up what happened when I changed the order manually in the map - brainfart methinks.
Bear in mind this is the first time it’s happened to me in probably 100+ versions of helmsdeep and all my other custom maps, so I’m not suprised things like this slip through the net until they feel it’s time to show their face with a vengeance.

Cheers everyone once again :slight_smile:

(EB) #11

Different situations call for different things otherwise it would have been fixed long before I had that argument.

(G0-Gerbil) #12

Regarding the wrong spawn thing from that other thread then no, I disagree - the problem was exactly what reyalP said.
The fact that other things may appear to fix the problem boils down to the same reason I’d never encountered this issue before - plain luck.
One of the fun things about the Q3 engine is there are a lot of unspecified results when people do things they shouldn’t. Much of the time they turn out OK anyway, but this really is coincidence.
It’s like when RivrStyx released Resurrection, and missing shaders appeared when it was run on the same server as earlier versions of Helmsdeep. It only ever happened (well, so they thought at the time) in combination with my map, hence everyone went around blaming my map and I got bad press as a result.
Naturally it turned out to be RivrStyx’s fault - he had two versions of the same shader in - 1 correct, 1 missing it’s texture. For some reason, my map forced his map’s shaders to be read in in a different order, producing the buggered ‘result’.

It’s easy to see a problem and think you have fixed it, but the bottom line is things need to be investigated to find the real cause, so that people don’t encounter the problem again, as is what happened in your thread - without reyalP finding the real problem, I’d probably have had to release my map with a nasty hack to get around what is actually a very simple problem. If you have a problem with being proved wrong, well I can’t help that, but sometimes it’s just better to take one for the team and admit mistakes. It’s easy, really, I do it all the time :slight_smile:

(Ifurita) #13

it’s just better to take one for the team and admit mistakes

Agreed, Gerbil has much experience in this department :lol: Lord knows I’ve had my share of them.

(G0-Gerbil) #14

Yup, when it comes to making mistakes, I’m damn near perfect. :banana:

(EB) #15

removed

(G0-Gerbil) #16

Oooooh angry boy :wink:
The point clearly mentioned by reyalP was that autospawns CANNOT affect anything unless they are called before players spawn.
Everything revolves around that.
The fact that something else you did ‘fixes’ maybe just shows how ‘lucky’ the Q3 engine can get at times.
And I respect reyalP’s interpretation of going through the source code to ET (did you do that, is that how you know your changes actually fix the problem, or do you just see the end result which ‘proves’ you are right?) to know if he says X happens at Y period of time, then that’s almost certainly what happens. His knowledge of that issue is exactly what solved my problem.
So yes, I’ve tested his way. And yes, he’s backed it up with fact. And if you are so quick to dismiss someone like reyalP’s knowledge of the Q3 engine, when in fact he’s an EXTREMELY competant coder / mapper and has played with the Q3 engine for years, then in what way does that give your 'knowledge of the Q3 engine any credibility?

You almost make me want to play with supply depot to see what happens :wink: [edit] I went to do just that, but realised I have no way of replicating on my own the problem they were going on about - oh well!).[/edit]

You’ve also got to bear in mind that insulting me has no effect except to make me smile. One of the joys of being able to admit I’m wrong means I can’t lose in this situation. If I’m wrong, I’m wrong, and I just shrug and move on like normal. If you are wrong, well, you’ve just made yourself look like a cock publically. I like those odds :slight_smile:

(EB) #17

::Sigh:: More arrogance.
And there is a way to replicate the problem on your own.
You figure it all out and get back to me, it seems you had it figured out so well to make a flame in my direction.----- How’s it go now ? Oh -Yeah, You don’t know !!!-----
AGAIN I ASK…HOW DO YOU ASSUME I AM WRONG WHEN YOU’RE THE ONE THAT DOES NOT HAVE AN ANSWER ? You’ve mixed yourself into 2 threads and you’re assuming alot.
I dislike it when someone can’t admit when a newer-community member knows more than them.
Relax, I just do. If you can’t deal with it that is your problem. Can we drop this now ?

It’s almost like your Don King picking fights for someone else…shhhhh.

P.S. Was the co&^ statement really nec. ?

(Detoeni) #18

:uhoh:

anyway, this may be a stupid question but why are not useing the startactive flag on the spawnpoints?

(EB) #19

I want to apologize straight away…I do not take kindly to harassment or the like.(<<this is known :smiley: )
There was no reason for me to be brought into this thread, the way I was, as the 2 topics being argued over have seperate issues that GO-Gerbil may not know about.
I hope we can let this go and get back to the topic at hand.

(SCDS_reyalP) #20

Startactive just means it is available. Certainly, any spawns that you want players to spawn at need to be active.

If mutltiple spawnpoint groups (team_WOLF_objective) are available at start (which makes sense on many maps, where some of your team might want to ‘spawn back’) then you need autospawn, and you need it to happen before the players spawn.