Prize and Door Synchronization

[pyxlz]

As far as prize weights being proportional vs. inversly proportional, is that well established? I was basing it off some !@#$%^&*umptions with the actual prize weightings in the zone.

 

In grelminar's test zone, the weight for brick is 200, whereas the weight for thrusters and top speed is 25. Most of the weights are in the 10-40 range with multiprize at 130 and brick at 200. I !@#$%^&*umed that since you rarely start with a brick (at 500 bounty), it has a much lower probability of occuring than anything else, thus the higher prize weight = lower probability.

 

Unless, perhaps, there is some built in probability !@#$%^&*ociated with an prize type, or if an initial bounty of X is not equivalent to receiving X greens.

[Mr Ekted]

My understanding is based on the VIE code itself. It adds up the weights, calls rand() and mods by total (which is why all 0 weights gives divide by zero error), then walks the weigh array, finding where the random number would fall.

[pyxlz]

I've looked at the door synchronization.  It works like this:

 

In the main game loop, the door function is called with a parameter for the number of game frames that have passed since the last time the door function was called.  Game frames are in hundredths of a second.

 

This is how most of the synchronized stuff work in SubSpace.

 

For each iteration, as I recall, it checks what type of door mode the arena is using, and iterates the door "seed" value, either once or 7 times (depends on door mode).  The seed is used to generate random numbers for the new door states.  The seed changes with each number it generates.

 

Every 2 minutes, the server will send a new timestamp and a new "seed" value to all the clients (same for all clients).  The clients will call the door function with the difference in time since the timestamp, which gives you as good synchronization as you get with position packets.

 

There are a few problems with this method; some are unavoidable without redesigning the protocol.  For instance, when the server changes the seed, the timers used to change the doors is overriden, so the door delay period that straddles the updating of the seed will be shorter for some people.

 

This is just a general overview of how it works.  If you want specifics, just ask.

Specifics would be very useful if you have them.

[Smong]

In grelminar's test zone ... you rarely start with a brick

I have noticed this too. I've come to the conclusion that you can only start with brick if InitialBrick > 0 (lanc = 255).

 

Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c.

 

Edit: typo.

[pyxlz]

Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c.

What code are you referring to? Prize generation?

[Maucaub]

In grelminar's test zone ... you rarely start with a brick

I have noticed this too. I've come to the conclusion that you can only start with brick if InitialBrick > 0 (lanc = 255).

 

Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c.

The specifics of how prizes are granted is handled client-side, not in the server. As for your observations regarding bricks, this is a direct consequence of how the programmers decided to implement prizes.

 

First thing to know is that your ship's initial bounty is treated like a multiprize. Specifically, what ever your InitialBounty setting is, the client grants you a Multiprize with that many prizes when your ship spawns. (The actual Multiprize is controlled via a different setting).

 

Second thing to know is that the VIE client multiprize code doesn't allow certain prizes to be received when picking up a multprize. The prizes not allowed in the VIE multiprize are: engine shutdown, shields, super, another multiprize, warp, and bricks. Hence, no matter what your initial bounty or what your brick PrizeWeight is, you'll never be granted a brick when you spawn. You must either pick it up manually or be awarded it via *prize.

 

The reasons most of those prizes are excluded from the multiprize is pretty obvious, such as not allowing cascading multiprizes. As for the bricks, my suspicion is that bricks were just too valuable/powerful a tool to be allowed to occur in multiprizes, so they excluded those as well.

[pyxlz]

In grelminar's test zone ... you rarely start with a brick

I have noticed this too. I've come to the conclusion that you can only start with brick if InitialBrick > 0 (lanc = 255).

 

Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c.

The specifics of how prizes are granted is handled client-side, not in the server. As for your observations regarding bricks, this is a direct consequence of how the programmers decided to implement prizes.

 

First thing to know is that your ship's initial bounty is treated like a multiprize. Specifically, what ever your InitialBounty setting is, the client grants you a Multiprize with that many prizes when your ship spawns. (The actual Multiprize is controlled via a different setting).

 

Second thing to know is that the VIE client multiprize code doesn't allow certain prizes to be received when picking up a multprize. The prizes not allowed in the VIE multiprize are: engine shutdown, shields, super, another multiprize, warp, and bricks. Hence, no matter what your initial bounty or what your brick PrizeWeight is, you'll never be granted a brick when you spawn. You must either pick it up manually or be awarded it via *prize.

 

The reasons most of those prizes are excluded from the multiprize is pretty obvious, such as not allowing cascading multiprizes. As for the bricks, my suspicion is that bricks were just too valuable/powerful a tool to be allowed to occur in multiprizes, so they excluded those as well.

Ok, so multiprizes are weighted the same as regular prizes, except for the aforementioned items, which are weighted at zero?

[Smong]

Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c.

What code are you referring to? Prize generation?

Prize generation, specifically the contents of the kill prize when a player dies.