pyxlz Posted February 12, 2004 Report Posted February 12, 2004 Is there any do-*BAD WORD*-entation out there on prize and door synchronization? From what I've read, the random number generator seeds are used somehow to generate data related to the prizes and doors, but nothing more specific than that. For example, is the prize seed used to generate (x,y) pairs for all available greens, generate prize types (recharge, turn, multifire, etc..)? Are all previously generated prizes cleared after receiving a new seed? Is the door seed used to generate a time on/off for all random-timed doors? Any information would be much appreciated.
Mr Ekted Posted February 12, 2004 Report Posted February 12, 2004 I believe they are both implemented in the MERV core. Both are controlled by seeds/times sent by the server. Doors can be kept in perfect sync on all clients other than time sync issues. Greens were never designed correctly. While the code goes to a lot of trouble to sync the green info, in reality because of independent events on each client, they get way out of sync very quickly. If you had 2 clients running side-by-side and watched the same area of the map, only about half the greens (very rough) would match at any point in time. Both doors and greens could have been done much better. I'm sure when green code was designed they figured they weren't important enough to sync perfectly, which is probably true for more forms of the game.
pyxlz Posted February 12, 2004 Author Report Posted February 12, 2004 Both doors and greens could have been done much better. I'm sure when green code was designed they figured they weren't important enough to sync perfectly, which is probably true for more forms of the game. Do you have any suggestions for how it could be done better?
numpf Posted February 12, 2004 Report Posted February 12, 2004 This is again a case where you should probably ignore SS if you want to do something similar in a separate app. If I remember right, part of the problem with green sync is that it uses dynamic numbers... something like, you interpret the green seed based on the number of players in the arena. This creates a problem for entering players, because when they enter they are updated with the green seed when they enter, which is at a different time than other players. Similarly, I think it depends on how many or what greens currently exist. That's a problem because clients might destroy different greens. On your screen player X flew over green Y, but on mine he didn't. Your client destroys green Y and mine doesn't. If we sync based on whether green Y exists, our green sync is off. Sync like this comes down to very carefully choosing what random factors you use. They have to be random AND all the clients have to agree upon that random result.
pyxlz Posted February 12, 2004 Author Report Posted February 12, 2004 I believe they are both implemented in the MERV core. Perhaps you can point me in the right direction on this? The only implementation I of door and prizes that I found deals with seed synchronization. There doesn't seem to be anything regarding actually generating greens or turning on and off doors.
numpf Posted February 12, 2004 Report Posted February 12, 2004 all the code for greens is in prize.* in backup.zip - I don't see any code for doors in merv.
»CypherJF Posted February 12, 2004 Report Posted February 12, 2004 has this always been an/the issue; or am i remembering incorrectly that back in the old VIE zones, when i ran over a green (the whole team got it, i'm !@#$%^&*uming this was just a broadcast??), it was shown correctly on the other machines?...
Dr Brain Posted February 12, 2004 Report Posted February 12, 2004 Yes, the client tells the server what prize it picks up, and then forwards the *prize to the rest of the team. So you can be on the other side of the map and not even see the pickup. Side note: this is how *watchgreen gets it's data.
Mr Ekted Posted February 13, 2004 Report Posted February 13, 2004 Client only tells server if *watchgreen is on or if team prizes. Server only tells others if THEY are using *watchgreen or if same team and team prizes.
Mr Ekted Posted February 13, 2004 Report Posted February 13, 2004 Here's the code for doors right out of VIE... :0041BE9C A17CC64700 mov eax, dword[0047C67C] :0041BEA1 0FBF0D42DD4700 movsx ecx, word[0047DD42] :0041BEA8 40 inc eax :0041BEA9 3BC1 cmp eax, ecx :0041BEAB A37CC64700 mov dword[0047C67C], eax :0041BEB0 0F8CCC030000 jl 0041C282 :0041BEB6 0FBF0546DD4700 movsx eax, word[0047DD46] :0041BEBD 33ED xor ebp, ebp :0041BEBF 83F8FE cmp eax, -00000002 :0041BEC2 892D7CC64700 mov dword[0047C67C], ebp :0041BEC8 0F8436030000 je 0041C204 :0041BECE 83F8FF cmp eax, -00000001 :0041BED1 740F je 0041BEE2 :0041BED3 8BD8 mov ebx, eax :0041BED5 C744241C01000000 mov dword[esp+1C], 00000001 :0041BEDD E9A2030000 jmp 0041C284 --------- :0041BEE2 8B351C934800 mov esi, dword[0048931C] :0041BEE8 B91DF30100 mov ecx, 0001F31D :0041BEED 8BC6 mov eax, esi :0041BEEF 99 cdq :0041BEF0 F7F9 idiv ecx :0041BEF2 8BC2 mov eax, edx :0041BEF4 C1E003 shl eax, 03 :0041BEF7 2BC2 sub eax, edx :0041BEF9 8D0480 lea eax, dword[eax+4*eax] :0041BEFC 8D0480 lea eax, dword[eax+4*eax] :0041BEFF C1E004 shl eax, 04 :0041BF02 03C2 add eax, edx :0041BF04 8D0440 lea eax, dword[eax+2*eax] :0041BF07 8D0C42 lea ecx, dword[edx+2*eax] :0041BF0A B85F0B4E83 mov eax, 834E0B5F :0041BF0F F7EE imul esi :0041BF11 03D6 add edx, esi :0041BF13 C1FA10 sar edx, 10 :0041BF16 8BC2 mov eax, edx :0041BF18 C1E81F shr eax, 1F :0041BF1B 03D0 add edx, eax :0041BF1D 8D04D2 lea eax, dword[edx+8*edx] :0041BF20 C1E003 shl eax, 03 :0041BF23 2BC2 sub eax, edx :0041BF25 8D0480 lea eax, dword[eax+4*eax] :0041BF28 D1E0 shl eax, 1 :0041BF2A 2BC2 sub eax, edx :0041BF2C C1E002 shl eax, 02 :0041BF2F 2BC8 sub ecx, eax :0041BF31 83C17B add ecx, 0000007B :0041BF34 3BCD cmp ecx, ebp :0041BF36 8BF1 mov esi, ecx :0041BF38 7F06 jg 0041BF40 :0041BF3A 8DB1FFFFFF7F lea esi, dword[ecx+7FFFFFFF] --------- :0041BF40 8BC6 mov eax, esi :0041BF42 B91DF30100 mov ecx, 0001F31D :0041BF47 99 cdq :0041BF48 33C2 xor eax, edx :0041BF4A 2BC2 sub eax, edx :0041BF4C 83E001 and eax, 00000001 :0041BF4F 33C2 xor eax, edx :0041BF51 8BD8 mov ebx, eax :0041BF53 8BC6 mov eax, esi :0041BF55 2BDA sub ebx, edx :0041BF57 F7DB neg ebx :0041BF59 99 cdq :0041BF5A 1BDB sbb ebx, ebx :0041BF5C F7F9 idiv ecx :0041BF5E 83E311 and ebx, 00000011 :0041BF61 8BC2 mov eax, edx :0041BF63 C1E003 shl eax, 03 :0041BF66 2BC2 sub eax, edx :0041BF68 8D0480 lea eax, dword[eax+4*eax] :0041BF6B 8D0480 lea eax, dword[eax+4*eax] :0041BF6E C1E004 shl eax, 04 :0041BF71 03C2 add eax, edx :0041BF73 8D0440 lea eax, dword[eax+2*eax] :0041BF76 8D0C42 lea ecx, dword[edx+2*eax] :0041BF79 B85F0B4E83 mov eax, 834E0B5F :0041BF7E F7EE imul esi :0041BF80 03D6 add edx, esi :0041BF82 C1FA10 sar edx, 10 :0041BF85 8BC2 mov eax, edx :0041BF87 C1E81F shr eax, 1F :0041BF8A 03D0 add edx, eax :0041BF8C 8D04D2 lea eax, dword[edx+8*edx] :0041BF8F C1E003 shl eax, 03 :0041BF92 2BC2 sub eax, edx :0041BF94 8D0480 lea eax, dword[eax+4*eax] :0041BF97 D1E0 shl eax, 1 :0041BF99 2BC2 sub eax, edx :0041BF9B C1E002 shl eax, 02 :0041BF9E 2BC8 sub ecx, eax :0041BFA0 83C17B add ecx, 0000007B :0041BFA3 3BCD cmp ecx, ebp :0041BFA5 8BF1 mov esi, ecx :0041BFA7 7F06 jg 0041BFAF :0041BFA9 8DB1FFFFFF7F lea esi, dword[ecx+7FFFFFFF] --------- :0041BFAF 8BC6 mov eax, esi :0041BFB1 B91DF30100 mov ecx, 0001F31D :0041BFB6 99 cdq :0041BFB7 33C2 xor eax, edx :0041BFB9 2BC2 sub eax, edx :0041BFBB 83E003 and eax, 00000003 :0041BFBE 33C2 xor eax, edx :0041BFC0 2BC2 sub eax, edx :0041BFC2 F7D8 neg eax :0041BFC4 1BC0 sbb eax, eax :0041BFC6 83E002 and eax, 00000002 :0041BFC9 0BD8 or ebx, eax :0041BFCB 8BC6 mov eax, esi :0041BFCD 99 cdq :0041BFCE F7F9 idiv ecx :0041BFD0 8BC2 mov eax, edx :0041BFD2 C1E003 shl eax, 03 :0041BFD5 2BC2 sub eax, edx :0041BFD7 8D0480 lea eax, dword[eax+4*eax] :0041BFDA 8D0480 lea eax, dword[eax+4*eax] :0041BFDD C1E004 shl eax, 04 :0041BFE0 03C2 add eax, edx :0041BFE2 8D0440 lea eax, dword[eax+2*eax] :0041BFE5 8D0C42 lea ecx, dword[edx+2*eax] :0041BFE8 B85F0B4E83 mov eax, 834E0B5F :0041BFED F7EE imul esi :0041BFEF 03D6 add edx, esi :0041BFF1 C1FA10 sar edx, 10 :0041BFF4 8BC2 mov eax, edx :0041BFF6 C1E81F shr eax, 1F :0041BFF9 03D0 add edx, eax :0041BFFB 8D04D2 lea eax, dword[edx+8*edx] :0041BFFE C1E003 shl eax, 03 :0041C001 2BC2 sub eax, edx :0041C003 8D0480 lea eax, dword[eax+4*eax] :0041C006 D1E0 shl eax, 1 :0041C008 2BC2 sub eax, edx :0041C00A C1E002 shl eax, 02 :0041C00D 2BC8 sub ecx, eax :0041C00F 83C17B add ecx, 0000007B :0041C012 3BCD cmp ecx, ebp :0041C014 8BF1 mov esi, ecx :0041C016 7F06 jg 0041C01E :0041C018 8DB1FFFFFF7F lea esi, dword[ecx+7FFFFFFF] --------- :0041C01E 8BC6 mov eax, esi :0041C020 B91DF30100 mov ecx, 0001F31D :0041C025 99 cdq :0041C026 33C2 xor eax, edx :0041C028 2BC2 sub eax, edx :0041C02A 83E007 and eax, 00000007 :0041C02D 33C2 xor eax, edx :0041C02F 2BC2 sub eax, edx :0041C031 F7D8 neg eax :0041C033 1BC0 sbb eax, eax :0041C035 83E004 and eax, 00000004 :0041C038 0BD8 or ebx, eax :0041C03A 8BC6 mov eax, esi :0041C03C 99 cdq :0041C03D F7F9 idiv ecx :0041C03F 8BC2 mov eax, edx :0041C041 C1E003 shl eax, 03 :0041C044 2BC2 sub eax, edx :0041C046 8D0480 lea eax, dword[eax+4*eax] :0041C049 8D0480 lea eax, dword[eax+4*eax] :0041C04C C1E004 shl eax, 04 :0041C04F 03C2 add eax, edx :0041C051 8D0440 lea eax, dword[eax+2*eax] :0041C054 8D0C42 lea ecx, dword[edx+2*eax] :0041C057 B85F0B4E83 mov eax, 834E0B5F :0041C05C F7EE imul esi :0041C05E 03D6 add edx, esi :0041C060 C1FA10 sar edx, 10 :0041C063 8BC2 mov eax, edx :0041C065 C1E81F shr eax, 1F :0041C068 03D0 add edx, eax :0041C06A 8D04D2 lea eax, dword[edx+8*edx] :0041C06D C1E003 shl eax, 03 :0041C070 2BC2 sub eax, edx :0041C072 8D0480 lea eax, dword[eax+4*eax] :0041C075 D1E0 shl eax, 1 :0041C077 2BC2 sub eax, edx :0041C079 C1E002 shl eax, 02 :0041C07C 2BC8 sub ecx, eax :0041C07E 83C17B add ecx, 0000007B :0041C081 3BCD cmp ecx, ebp :0041C083 8BF1 mov esi, ecx :0041C085 7F06 jg 0041C08D :0041C087 8DB1FFFFFF7F lea esi, dword[ecx+7FFFFFFF] --------- :0041C08D 8BC6 mov eax, esi :0041C08F B91DF30100 mov ecx, 0001F31D :0041C094 99 cdq :0041C095 33C2 xor eax, edx :0041C097 2BC2 sub eax, edx :0041C099 83E00F and eax, 0000000F :0041C09C 33C2 xor eax, edx :0041C09E 2BC2 sub eax, edx :0041C0A0 F7D8 neg eax :0041C0A2 1BC0 sbb eax, eax :0041C0A4 83E008 and eax, 00000008 :0041C0A7 0BD8 or ebx, eax :0041C0A9 8BC6 mov eax, esi :0041C0AB 99 cdq :0041C0AC F7F9 idiv ecx :0041C0AE 8BC2 mov eax, edx :0041C0B0 C1E003 shl eax, 03 :0041C0B3 2BC2 sub eax, edx :0041C0B5 8D0480 lea eax, dword[eax+4*eax] :0041C0B8 8D0480 lea eax, dword[eax+4*eax] :0041C0BB C1E004 shl eax, 04 :0041C0BE 03C2 add eax, edx :0041C0C0 8D0440 lea eax, dword[eax+2*eax] :0041C0C3 8D0C42 lea ecx, dword[edx+2*eax] :0041C0C6 B85F0B4E83 mov eax, 834E0B5F :0041C0CB F7EE imul esi :0041C0CD 03D6 add edx, esi :0041C0CF C1FA10 sar edx, 10 :0041C0D2 8BC2 mov eax, edx :0041C0D4 C1E81F shr eax, 1F :0041C0D7 03D0 add edx, eax :0041C0D9 8D04D2 lea eax, dword[edx+8*edx] :0041C0DC C1E003 shl eax, 03 :0041C0DF 2BC2 sub eax, edx :0041C0E1 8D0480 lea eax, dword[eax+4*eax] :0041C0E4 D1E0 shl eax, 1 :0041C0E6 2BC2 sub eax, edx :0041C0E8 C1E002 shl eax, 02 :0041C0EB 2BC8 sub ecx, eax :0041C0ED 83C17B add ecx, 0000007B :0041C0F0 3BCD cmp ecx, ebp :0041C0F2 8BF1 mov esi, ecx :0041C0F4 7F06 jg 0041C0FC :0041C0F6 8DB1FFFFFF7F lea esi, dword[ecx+7FFFFFFF] --------- :0041C0FC 8BC6 mov eax, esi :0041C0FE B91DF30100 mov ecx, 0001F31D :0041C103 99 cdq :0041C104 33C2 xor eax, edx :0041C106 2BC2 sub eax, edx :0041C108 83E003 and eax, 00000003 :0041C10B 33C2 xor eax, edx :0041C10D 2BC2 sub eax, edx :0041C10F F7D8 neg eax :0041C111 1BC0 sbb eax, eax :0041C113 83E020 and eax, 00000020 :0041C116 0BD8 or ebx, eax :0041C118 8BC6 mov eax, esi :0041C11A 99 cdq :0041C11B F7F9 idiv ecx :0041C11D 8BC2 mov eax, edx :0041C11F C1E003 shl eax, 03 :0041C122 2BC2 sub eax, edx :0041C124 8D0480 lea eax, dword[eax+4*eax] :0041C127 8D0480 lea eax, dword[eax+4*eax] :0041C12A C1E004 shl eax, 04 :0041C12D 03C2 add eax, edx :0041C12F 8D0440 lea eax, dword[eax+2*eax] :0041C132 8D0C42 lea ecx, dword[edx+2*eax] :0041C135 B85F0B4E83 mov eax, 834E0B5F :0041C13A F7EE imul esi :0041C13C 03D6 add edx, esi :0041C13E C1FA10 sar edx, 10 :0041C141 8BC2 mov eax, edx :0041C143 C1E81F shr eax, 1F :0041C146 03D0 add edx, eax :0041C148 8D04D2 lea eax, dword[edx+8*edx] :0041C14B C1E003 shl eax, 03 :0041C14E 2BC2 sub eax, edx :0041C150 8D0480 lea eax, dword[eax+4*eax] :0041C153 D1E0 shl eax, 1 :0041C155 2BC2 sub eax, edx :0041C157 C1E002 shl eax, 02 :0041C15A 2BC8 sub ecx, eax :0041C15C 83C17B add ecx, 0000007B :0041C15F 3BCD cmp ecx, ebp :0041C161 8BF1 mov esi, ecx :0041C163 7F06 jg 0041C16B :0041C165 8DB1FFFFFF7F lea esi, dword[ecx+7FFFFFFF] --------- :0041C16B 8BC6 mov eax, esi :0041C16D B91DF30100 mov ecx, 0001F31D :0041C172 99 cdq :0041C173 33C2 xor eax, edx :0041C175 2BC2 sub eax, edx :0041C177 83E007 and eax, 00000007 :0041C17A 33C2 xor eax, edx :0041C17C 2BC2 sub eax, edx :0041C17E F7D8 neg eax :0041C180 1BC0 sbb eax, eax :0041C182 83E040 and eax, 00000040 :0041C185 0BD8 or ebx, eax :0041C187 8BC6 mov eax, esi :0041C189 99 cdq :0041C18A F7F9 idiv ecx :0041C18C 8BC2 mov eax, edx :0041C18E C1E003 shl eax, 03 :0041C191 2BC2 sub eax, edx :0041C193 8D0480 lea eax, dword[eax+4*eax] :0041C196 8D0480 lea eax, dword[eax+4*eax] :0041C199 C1E004 shl eax, 04 :0041C19C 03C2 add eax, edx :0041C19E 8D0440 lea eax, dword[eax+2*eax] :0041C1A1 8D0C42 lea ecx, dword[edx+2*eax] :0041C1A4 B85F0B4E83 mov eax, 834E0B5F :0041C1A9 F7EE imul esi :0041C1AB 03D6 add edx, esi :0041C1AD C1FA10 sar edx, 10 :0041C1B0 8BC2 mov eax, edx :0041C1B2 C1E81F shr eax, 1F :0041C1B5 03D0 add edx, eax :0041C1B7 8D04D2 lea eax, dword[edx+8*edx] :0041C1BA C1E003 shl eax, 03 :0041C1BD 2BC2 sub eax, edx :0041C1BF 8D0480 lea eax, dword[eax+4*eax] :0041C1C2 D1E0 shl eax, 1 :0041C1C4 2BC2 sub eax, edx :0041C1C6 C1E002 shl eax, 02 :0041C1C9 2BC8 sub ecx, eax :0041C1CB 83C17B add ecx, 0000007B :0041C1CE 3BCD cmp ecx, ebp :0041C1D0 7F06 jg 0041C1D8 :0041C1D2 81C1FFFFFF7F add ecx, 7FFFFFFF --------- :0041C1D8 8BC1 mov eax, ecx :0041C1DA 890D1C934800 mov dword[0048931C], ecx :0041C1E0 99 cdq :0041C1E1 33C2 xor eax, edx :0041C1E3 C744241C01000000 mov dword[esp+1C], 00000001 :0041C1EB 2BC2 sub eax, edx :0041C1ED 83E00F and eax, 0000000F :0041C1F0 33C2 xor eax, edx :0041C1F2 2BC2 sub eax, edx :0041C1F4 F7D8 neg eax :0041C1F6 1BC0 sbb eax, eax :0041C1F8 2580000000 and eax, 00000080 :0041C1FD 0BD8 or ebx, eax :0041C1FF E980000000 jmp 0041C284 --------- :0041C204 8B351C934800 mov esi, dword[0048931C] :0041C20A B91DF30100 mov ecx, 0001F31D :0041C20F 8BC6 mov eax, esi :0041C211 99 cdq :0041C212 F7F9 idiv ecx :0041C214 8BC2 mov eax, edx :0041C216 C1E003 shl eax, 03 :0041C219 2BC2 sub eax, edx :0041C21B 8D0480 lea eax, dword[eax+4*eax] :0041C21E 8D0480 lea eax, dword[eax+4*eax] :0041C221 C1E004 shl eax, 04 :0041C224 03C2 add eax, edx :0041C226 8D0440 lea eax, dword[eax+2*eax] :0041C229 8D0C42 lea ecx, dword[edx+2*eax] :0041C22C B85F0B4E83 mov eax, 834E0B5F :0041C231 F7EE imul esi :0041C233 03D6 add edx, esi :0041C235 C1FA10 sar edx, 10 :0041C238 8BC2 mov eax, edx :0041C23A C1E81F shr eax, 1F :0041C23D 03D0 add edx, eax :0041C23F 8D04D2 lea eax, dword[edx+8*edx] :0041C242 C1E003 shl eax, 03 :0041C245 2BC2 sub eax, edx :0041C247 8D0480 lea eax, dword[eax+4*eax] :0041C24A D1E0 shl eax, 1 :0041C24C 2BC2 sub eax, edx :0041C24E C1E002 shl eax, 02 :0041C251 2BC8 sub ecx, eax :0041C253 83C17B add ecx, 0000007B :0041C256 3BCD cmp ecx, ebp :0041C258 7F06 jg 0041C260 :0041C25A 81C1FFFFFF7F add ecx, 7FFFFFFF --------- :0041C260 8BC1 mov eax, ecx :0041C262 890D1C934800 mov dword[0048931C], ecx :0041C268 99 cdq :0041C269 33C2 xor eax, edx :0041C26B C744241C01000000 mov dword[esp+1C], 00000001 :0041C273 2BC2 sub eax, edx :0041C275 25FF000000 and eax, 000000FF :0041C27A 33C2 xor eax, edx :0041C27C 8BD8 mov ebx, eax :0041C27E 2BDA sub ebx, edx :0041C280 EB02 jmp 0041C284 --------- :0041C282 33ED xor ebp, ebp --------- :0041C284 8B442418 mov eax, dword[esp+18] :0041C288 48 dec eax :0041C289 89442418 mov dword[esp+18], eax :0041C28D 0F8593F8FFFF jne 0041BB26 :0041C293 EB04 jmp 0041C299 --------- :0041C295 8B5C2438 mov ebx, dword[esp+38] --------- :0041C299 396C241C cmp dword[esp+1C], ebp :0041C29D 7409 je 0041C2A8 :0041C29F 53 push ebx :0041C2A0 E88B000000 call 0041C330 :0041C2A5 83C404 add esp, 00000004 --------- :0041C2A8 8B4C2424 mov ecx, dword[esp+24] :0041C2AC 5F pop edi :0041C2AD 5E pop esi :0041C2AE 5D pop ebp :0041C2AF 64890D00000000 mov dword fs:[00000000], ecx :0041C2B6 5B pop ebx :0041C2B7 83C420 add esp, 00000020 :0041C2BA C3 ret
Dr Brain Posted February 13, 2004 Report Posted February 13, 2004 Client only tells server if *watchgreen is on or if team prizes. Server only tells others if THEY are using *watchgreen or if same team and team prizes.Close enough
catid Posted February 15, 2004 Report Posted February 15, 2004 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.
Mr Ekted Posted February 16, 2004 Report Posted February 16, 2004 Yes. A better way would be to always send a door timestamp 10+ seconds BEFORE the next toggle, so all clients are basically guaranteed to get it and sync up. Unweighted door mode just randomizes all doors each time. Weighted door mode uses 7 random numbers. One of them affects 2 of the 8 bits--the 2 most "toggling" door, so they stay in sync. The other 6 control the other 6 bits, which toggle 2x 4x and 8x less often. Door modes 0-255 set doors of all 8 types to those bits specifically. A door type is defined by the tile (there are chosen in the map editor.
Smong Posted February 16, 2004 Report Posted February 16, 2004 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.Is this delay:1. Door:DoorDelay2. Arbitrary. The random number generator is called times before the actual 7 numbers are updated. I read somewhere that Door:DoorDelay is used to generate the seed, or could be changed to influence how the doors open/close (not just more often, but a certain pattern). Weighted door mode uses 7 random numbers. One of them affects 2 of the 8 bits--the 2 most "toggling" door, so they stay in sync. The other 6 control the other 6 bits, which toggle 2x 4x and 8x less often.So the two fast changing doors (1 and 5) are always in the same state? When you say 'affects', do you mean part of the random number is somehow added to the current bit and then ANDed/modulus or something? Are the other doors exactly 2x, 4x, or is that just approxmate over a period of time.
Mr Ekted Posted February 16, 2004 Report Posted February 16, 2004 In weighted DoorMode, every DoorDelay unit of time, all door state bits are updated. Bits 0 and 4 are set to (RNG & 1)Bit 1 is set to (RNG & 3) != 0Bit 2 is set to (RNG & 7) != 0Bit 3 is set to (RNG & 15) != 0Bit 5 is set to (RNG & 3) != 0Bit 6 is set to (RNG & 7) != 0Bit 7 is set to (RNG & 15) != 0 Each RNG above is a separate call to the SS RNG function. So when I said 2x 4x 8x, it's the probabilities of the doors being "open" over a period of time.
catid Posted February 16, 2004 Report Posted February 16, 2004 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.Is this delay:1. Door:DoorDelay2. Arbitrary. The random number generator is called times before the actual 7 numbers are updated. I read somewhere that Door:DoorDelay is used to generate the seed, or could be changed to influence how the doors open/close (not just more often, but a certain pattern). I actually didn't say "delay", there so that people hopefully wouldn't get confused. Oh well ^_^ DoorDelay or Random(Arbit.) Delay are checked during each iteration in the door function, based on door mode. Knowing WHEN the delay has finished is based on this "number of game frames" I mention. One game frame happens every 100th of a second, as you may have guessed. The delays are checked against these game frames to see when the delay has finished; but, the delays are not these game frames. smong: If you're trying to implement a client, instead of trusting hear-say you should read EkTed's !@#$%^&*embler code. Or, better yet, rip it yourself from SS1.34
Smong Posted February 16, 2004 Report Posted February 16, 2004 That would mean learning !@#$%^&*embly, and learning how to interpret dis!@#$%^&*embled code. I was just thinking it would be nice to have a feature in a map editor or something so you can get your doors looking right.
pyxlz Posted March 1, 2004 Author Report Posted March 1, 2004 Can someone verify the correctness of the prize generation code found in MERVBot or provide other known working algorithms? The code I've been referred to was in the backup directory of the MERVBot source, in prize.cpp // Fill prize type p->type = 0; current = 0; stop = prng.getNextG() % prizeWeightTotal; BYTE *pw = (BYTE*)&prizeWeights; for (int i = 0; i < 28; ++i) { if (current < stop) break; current += (*pw++); ++p->type; } Right off the bat, (current < stop) is true, so the loop will never run, making the prize type always 0. !@#$%^&*uming the if statement should have (current >= stop), the type will still be calculated incorrectly. In this case, a larger prize weight value would result in a higher probability of occuring, but a larger prize weight value should actually result in a lower probability of occuring.
catid Posted March 1, 2004 Report Posted March 1, 2004 that code is not included mainly because it was not implemented properly. the overall scheme is correct, but the details are not. this is mainly because i was not the one who was trying to reverse-engineer it. Kavar! was the developer, and he dropped it before it was finished
Mr Ekted Posted March 1, 2004 Report Posted March 1, 2004 Even if you had the source right out of VIE of Cont, you can not sync the greens. They are very different on every client. Doors however can be synced perfectly minus S2C latency.
pyxlz Posted March 1, 2004 Author Report Posted March 1, 2004 Even if you had the source right out of VIE of Cont, you can not sync the greens. They are very different on every client. Doors however can be synced perfectly minus S2C latency.Independent of the prize synchronization though, is there a known working algorithm for generating prize types based on the weightings in the arena settings?
Mr Ekted Posted March 1, 2004 Report Posted March 1, 2004 Add up all prizeweights "t". Make a table. Choose a random number from 0 to t-1. Map it to prize using table. Or instead of table, you can walk the prize weight array and figure out where the random number would fall.
pyxlz Posted March 1, 2004 Author Report Posted March 1, 2004 Ok, any ideas on how to make the table? The way you say it sounds very similar to the already existing implementation in MERVBot, which is incorrect since the prize weight should be inversly proportional to the probability of a prize occuring (higher prize weight = lower probability of occuring). I tried inverting the weights simply by (prizeWeightTotal / weight) for every weight. For example, a 3 prize system with weights [10, 20, 200] would have corresponding probabilities [64.5%, 32.3%, 3.23%] ([23, 11.5, 1.15]/35.65). But this method doesn't seem to work out quite right either. So the question still remains: how do prize weights correspond to the chance of receiving that prize? Is it possible that a different prize system is used for giving starting bounties?
Mr Ekted Posted March 1, 2004 Report Posted March 1, 2004 Prize weights are proportional not inversely proportional. If you choose to use the table method, it would work like this. Say there are only 2 prizes (12 and 15), and their weights are 3 and 5. Make the table like this: 12 12 12 15 15 15 15 15 Choose a random number from 0 to 7, and lookup in the table to get the prize. Note that with this method, the table could get really big, and would probably have to be dynamically allocated, and rebuilt every time you get a new settings update.
Recommended Posts