SupplyDepot map script error

(SCDS_reyalP) #21

Erm, the scripting and entity states all get reset when warmup expires (G_ShutdownGame and G_InitGame get called). If it doesn’t something is very wrong. Think what would happen on every map if this wasn’t true. Session data is saved, but the entities get completely restarted. So your ‘explaination’ really doesn’t make any sense.

The only thing that has to do with warmup is the fact that if the allies cap the flag in warmup, you cannot manually click on it (you can still /setspawnpt), but this isn’t the root of the problem with the map.

Note that mortis also changed the wait times, so the fact his script works on full servers doesn’t imply that you are correct, and if the gamecode comment is to be believed, the 500ms wait shouldn’t work.

edit:
and FWIW, I’m not trying to pick on you. I’d just like to make sure we figure out and record the right answer, so the community doesn’t have to endure more buggy maps :moo:

(Threshold) #22

EB—

Ginc from 20ID made the map. I don’t think he plays ET anymore but I know he made it per one of his old clan mates…

(EB) #23

Thread 1
#1. the wait of 500 has no effect on the situation with the change…THAT DID NOT NEED TO BE CHANGED…Mortis changed it because you suggested it. I knew that it would make no difference, so I kept quiet. (maybe changing just the timing would have fixed the whole thing too. ) But the two together does not make a difference. [The 500 before the setautospawn is just a wait- it works. The 1000 after the setautospawns didn’t have anything to do with the spawns]
Waits are there in the scripting to tell the game how long to wait before reading the next line of a script section.]

#2. I did not fully anylyze his script or the way he set things in the map…I just found a cure.

—>All entities reset at game start…so why then did it screw up ?
– As the wobj was alerted, it was giving the reverse effect of the planned script. I did not make it do that, I did not write the original script, I did not ask it to do me a favor and malfunction. I ‘plain and simple’ ran the map, re-created the errored situation and made adjustments accordingly to fix it. He may have something else set in the map scripting that caused it.

I saw a reversal of the wobj when alerted, if the allies caught it, the axis flag would rise on the limbo map, but you were not allowed to spawn there as an axis, and likewise oppositely for the allies. It is too much to explain, if you have a question…just ask it…please don’t putter around and be vague.

Otherwise, if you feel like dissecting the script and the map…go ahead because there are going to be more questions on ‘spawns’ and in different situations. I want to make the things work rather than write a tutorial on spawn scripting based around an error in a map. I hope you understand. Feel free to run wild and explain the world of errored spawn scripting to the public.

=========================================================================
Thread 2

As for the pk3 thing…well it would be easier to make the pk3 with just a script, but wouldn’t it be nice to make it just one download for the people who will want it on their servers now ? It can be done both ways. I think we wasted more energy talking about that than I would have spent making all the different pk3’s. lol

-----cheers :fluffle:

(SCDS_reyalP) #24

It should also be obvious that if the player spawns before the autospawn part of the script runs, they won’t be affected by it.

Since I didn’t have 14 people handy, I put some debug printfs in the gamecode instead. I’ve snipped out some unimportant verbage.

supplydepot2 with with 500ms wait:


GAME_CLIENT_BEGIN 0
...
Setting Axis autospawn to Forward Bunker Spawn
Setting Allied autospawn to Forward Bunker Spawn

Note, GAME_CLIENT_BEGIN 0 happens before autospawn is set. This means that client 0 (me) is very likely to spawn before that part of the script takes effect. The fact that I happened to spawn at the flag after that was only semi-random chance.

supplydepot2 with with 150ms wait:


Setting Axis autospawn to Forward Bunker Spawn
Setting Allied autospawn to Forward Bunker Spawn
...
GAME_CLIENT_BEGIN 0

Notice, GAME_CLIENT_BEGIN 0 happens after the setautospawn commands. Thus where client 0 spawns will be controlled by what setautospawn did.

For kicks, here’s oasis (also 150ms wait):


Setting Allied autospawn to Old City
Setting Axis autospawn to Old City
...
GAME_CLIENT_BEGIN 0

Exactly what I predicted, and it doesn’t require ignoring the fact that the entities get reset when warmup ends :moo:

Case closed ?

(deej) #25

Let’s hope the ETPro team includes this script in their 3.2 release then :slight_smile:

(EB) #26

.
let it go…it works…the thread was solved.

(SCDS_reyalP) #27

I posted proof that my fix was correct, based on showing what the game code actually does. You posted and explaination that would require time travel to be correct. Clearly you are wrong.

shrug

(mortis) #28

After extensive testing, I have discovered the following:

The supplydepot mapscript works perfectly.
The supplydepot3-ladder version works perfectly

The supplydepot2 mapscript has some new unknown bug that is causing the improper spawns, I will fix it.
The supplydepot3-ramp.pk3 has the same issue, as it uses the same script.

So, try the regular supplydepot map and see if that works correctly for you. It should. DO NOT use supplydepot2 until I fix the bug.

–Mortis

(mortis) #29

After extensive testing, I have discovered the following:

The supplydepot mapscript works perfectly.
The supplydepot3-ladder version works perfectly

The supplydepot2 mapscript has some new unknown bug that is causing the improper spawns, I will fix it.
The supplydepot3-ramp.pk3 has the same issue, as it uses the same script.

So, try the regular supplydepot map and see if that works correctly for you. It should. DO NOT use supplydepot2 until I fix the bug.

–Mortis

(SCDS_reyalP) #30

The supplydepot2 script you posted won’t set allies forward spawn correctly, because you changed the autospawn, but don’t set it when the flag changes hands. Just fix the wait and don’t change anything else (from the original script). Alternatively, you could uncomment the code that sets the autospawn every time the flag changes hands.

There should be no harm in setting both to autospawn in the same place, because this does not control the enable/disable state of the spawn points. That is controlled by the spawnpoints themselves. You can /setspawnpt to a wobj owned by the other team, without any problems. Autospawn should do the same thing. ET will just spawn you at the closest enabled spawnpoint for your team. The ownership of wobjs is used for the UI, and also does not control where people can actually spawn.

(mortis) #31

A portion of the spawn entries were commented out in supplydepot2…causing the odd behavior. I have fixed the bug and now both scripts are working and tested on my home server…

Known good scripts found here:

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

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

Thanks to those who identified the supplydepot2 bug and alerted me to its presence…

–Mortis

(mortis) #32

double post oops

(EB) #33

I thought he was just being a jerk to me…but it turns out that everyone is on his list!!!
The fix was a fix with the timing or not…

(EB) #34

I have never posted a “Rub it in your face” type post before, AND I AM HAPPY TO DO IT to ReyalP !!!

I recreated the situation that created this thread, but ONLY with the ‘wait’ timing changed (like reyalp said)and it still goofed itself !!!

CHEERS !!! :chef: :chef: :chef:

(SCDS_reyalP) #35

If you demonstrate that I was wrong, I’d love to set it. Big fonts aren’t a particularly convincing demonstration.

I know and have proven the timing issue is real. It is certainly possible there are other issues. No matter that you think I’m just repeating stuff I read, I actually know quite a bit about the gamecode. You obviously do not. That isn’t intended to be condescending, it is just a simple fact. If you doubt I know anyting about code, feel free to look at the radiant changelog or credits file :moo:

(EB) #36

You obviously do not. That isn’t intended to be condescending, it is just a simple fact
What gave you the balls to say that ?
How the hell do you think you know what I know ? I tried to explain something in an easy way since I do not know what you know …so I made it relative. DO NOT TELL ME WHAT I DO AND DO NOT KNOW…YOU DO NOT KNOW ME AND YOU ARE STILL BEING CONDESCENDING and I am still being defensive!!!

.Go and test the map yourself, you’ll see…as if I’d make a false statement and one you can test at that.

(Brevik) #37

EB, how about replying in a reasonable manner? You’re shouting at reyalP to grow up and yet you’re the one acting like a hysterical child. Also, using homophobic insults makes you sound like a jerk - any credibility you have gets blown away when you act like that.

It would be nice to have a “third party” verify what the actual fix is, to me (although I’m no scripting guru), reyalP’s explanation makes the most sense, but that may be because he’s taken the time to explain himself better.

(Loffy) #38

Thunderdome.

(EB) #39

hold

(SCDS_reyalP) #40

Brevik:
I would certainly like to know if just changing the waits solves the problem with supply depot. I’m pretty sure it will, but the proof is always in testing. As I said before, there certainly could be other problems.

What I do know, 100% for certain, is that the 500ms wait is too much. With that, players spawn before the setautospawn happens, which is not desirable, and would cause the kind of problems that supplydepot had. So anyone making maps like this should use less. Since 150 works in oasis, and in my testing lets the players spawn after the script runs, that seems like a good number to use. You do need some wait, or other entities might not be spawned yet.

EB:
I haven’t intended to insult your intelligence. You made some statements which were clearly incorrect. I pointed them out, in the hope of preventing others from being mislead. If that upsets you, so be it. If you have found other problems in the supplydepot script, and would describe them clearly and logically, everyone would benefit. Or you could rant.
shrug