Why all the hate? You both helped me to solve the problem, and that is what is important. Forums + help = more fun in the game.
Go settle your dispute in some one-on-one frag action. :drink:
Thanks you both for your help. Regardless of who is right or wrong, the new scripts work…
–Mortis
See Reyal rarely makes helpful posts
most people saying that would have it inside [sarcasm] tags.
reyalP tends to post in a fairly concise and neutral manner, you can choose to read into it whatever you like. Your posts on the other hand dont leave the reader room for making such a judgement.
I apologize to everyone…maybe I did read into things.
But he did insult my integrity…I like coming here to help out and be helped but having someone repeatedly state the same thing which I proved wrong - is annoying.
Never did he prove me wrong…he only proved a theory of his own right. But he chose to state I was wrong .
I tested the script…and he still doubts me without testing it. THAT IS SPITEFUL.
I find that extremely arrogant and hurtful too. shrug
My apologies to all members and staff…and even you Reyalp. Even though you should have apologized first.
P.S. I must have deleted the sarcasm tags by mistake…I did have them originally. ooops
One thing I’m curious about as an aside, is why this bug happens elsewhere.
I’ve only seen it once admittedly, but I have seen the spawnbug happen on Radar - allies grabbed flag in the warmup (of a clan match IIRC), and half of the axis team spawned back, which was equally as annoying as it is in Supply Depot.
If I get the gist of this thread right, the fix was just to drop a wait time so that the autospawns were set the right time, or at least, should be a lot lot more often. Is the bug still there, just massively less likely to occur? (though that would still be a huge improvement, and for all intents and purposes ‘solve’ it)
A new bug was discovered in supplydepot2 that caused the secondary autospawns to not autoupdate unless the flag was captured by Allies during the game. It was due to debugging comments “//” that I left in the supplydepot2 script by accident. This fix only applies to supplydepot2, the supplydepot1 script has worked flawlessly fromt he beginning. Thanks to all those involved in helping me to debug and, test, and update the supplydepot spawn bugs.
SupplyDepot http://www.bsdterritory.com/img/Mortis/supplydepot.script
SupplyDepot2 http://www.bsdterritory.com/img/Mortis/supplydepot2.script
–Mortis
I have never seen this happen on radar, but it could, because the radar script has a 500ms wait :moo:. You might ask why this normally works on radar at all and even worked most of the time on supplydepot. But it isn’t entirely random, as it depends on things that are fixed (the order of wobj entities in the .bsp) and variable (how long it takes to spawn each client).
If I get the gist of this thread right, the fix was just to drop a wait time so that the autospawns were set the right time, or at least, should be a lot lot more often. Is the bug still there, just massively less likely to occur? (though that would still be a huge improvement, and for all intents and purposes ‘solve’ it)
The bug should be completely fixed by a low enough wait, because the enigine is supposed to wait 6 frames (300ms) before spawning any players. As long as the setautospawn happens before those 6 frames are finished, then the supplydepot bug shouldn’t happen. However, the setautospawn can’t happen instantly, because the entities won’t be fully initialized when the spawn section of the script starts running.
Another thing that can cause people to spawn far away is if there are more players than forward spawnpoints, although that seems unlikely in a clan match. Manually selecting a spawnpoint (either in the UI, or with /setspawnpt) also caries over, as it is in the client session data, rather than entity data.
edit:
Whether the game actually waits 6 frames every time is not certain. I didn’t measure that in my simple test, and I would be particularly unsurprised if listen (dedicated 0) servers did weird things.
Yeah, I wonder if a “wait 150” entry would fix that. I have never noticed any bugs in the radar spawn, but I have heard people talk about it. I don’t think it happens very often…
If the timing change doesn’t work on that either, just replace the allies autospawn location to the ‘abondoned villa’.
Then it will have no choice -except to place the spawns there unless you modify some other part of that script.
If the timing change doesn’t work on that either, just replace the allies autospawn location to the ‘abondoned villa’.
That makes no sense. Where the allies autospawn is set has no impact on where the axis spawn.
SCDS, just do it for once instead of claiming it won’t work…go test it and if it doesn’t work…then tell me I am wrong.
I told you nicely, obnoxiously,hatefully and now I am telling you to just open your eyes…test it before you deny it.
Do you doubt everything in the world??? -----There is a complete association between the common sense used for supplydepot scripting fix and this situation. Mortis has not had 1 problem, go figure…So why not try the same thing here?
[SARCASM]Let me answer myself for you…OK ?
SCDS’s next reply by EB and to EB:
You are wrong --makes no sense…you are wrong…you know nothing.
[/SARCASM]
There, now you don’t have to reply!!!
:chef:
Test what ? In all the time I have played, I don’t recall radar ever spawning me in the wrong place. So how would I verify your “fix” ? By the same token, how can you be sure of a fix to an intermittent bug, unless you have understood the underlying cause ? I could propose all kinds of random changes as “fixes” and they would be very hard to disprove. But I have long since realized that debugging by guesswork should be a last resort.
Since I can’t reliably reproduce the bug, I look at what the gamecode does instead. Look at g_scriptaction.c G_ScriptAction_SetAutoSpawn and g_team.c SelectRandomTeamSpawnPoint From this I know setautospawn for one team has no effect on where the other team spawns.
I certainly don’t know everything about ET (never mind the world :D) but this particular area, I know quite well.
SenF greens were involved in a cup match with dhb when they spawned rear on Radar instead of the front bunker after Allies blew the main entrance. Its the only time I had heard of it before now…
i dont know that much bout scripts but the bugfix that www.et-scene.de has put out is not the solution for the problem. changing the autospawn is NOT the right way.
i guess theres something wrong in the map itself. the script seems ok the only thing that i wondered about is
trigger force_allied {
accum 0 abort_if_equal 1 //Abort if allies own
accum 0 set 1
setautospawn "Axis Depot Spawn" 0
setautospawn "Forward Bunker Spawn" 1
alertentity forward_wobj
alertentity forwardspawn
}
plz tell me scriptn00b why this accum is needed. (accum 0 set 1)
btw. the only thing that helped me fix this kind of bug in my maps is setting the wait time longer. the autospawn must be set to the captureable flag for both teams. else they will spawn at the startactive other spawns.
P.S. i had the radar bug 1 time playing but it was really only 1 time. once on radar i was on axis side an was using the mg in the side entrance. then suddenly i got crushed cause someone somewhere build some other mg. :eek: i never could reproduce those bugs…
Making the wait long is not a solution. It is 100% certain that if the initial wait is too long, the autospawn cannot work correctly. 500 is too long, 150 is not. There must be some wait.
The accum may be needed, because alertentity toggles the state of the named entities. That means if force_allied somehow got called when the allies already owned the spawn, then the wobj and spawn points themselves would get set to the wrong state.
Regardless of why it works now, both scripts do work. The supplydepot 1 script worked the whole time. I had two bugs with supplydepot2 due to previous efforts by the original author to correct the spawn problem. He had commented out the flag capture portion of the scripts, and the initial autospawn was wrong. I removed the comment “//” marks from the force_allied and flag capture portions of script, fixed the autospawn, and reduced the wait time.
I have personally tested all scenarios I could conceive of on my home server to test the scripts, both for supplydepot and for supplydepot2.
I have not tested the script to see which factor was the most important key reason that the script works (whether it is a timing issue, or whether it was necesary to force the autospawn to the Allied Start entity…)
FWIW, The ‘bug’ in force_allied only cropped up because you changed the initial autospawn. In the script distributed with the map, the autospawn only needed to be set at the start, so the other autospawn calls were correctly commented out.
Yes, when I fixed the supplydepot1 script, I had more time to pore over the script.
The supplydepot2 script I just checked for the entry names and timing, but I (stupidly) forgot to check for any other changes the author had made…
–Mortis