PPK 00: 00020000 Position 01: 00120000 Handle/Switch 02: 00020000 Position mflashn 03: 00020000 Position mflashf 04: 00040000 Display List No Collision mflashf 1 05: 00040000 Display List No Collision mflashn 2 06: 00150000 Position Held-items 07: 00120000 Handle/Switch 08: 00040000 Display List No Collision Barrle 3 09: 00090000 Head/Hat Placement 0A: 00090000 Head/Hat Placement 0B: 00090000 Head/Hat Placement 0C: 00090000 Head/Hat Placement 0D: 00120000 Handle/Switch 0E: 00040000 Display List No Collision Trigger 5 0F: 00120000 Handle/Switch 10: 00020000 Position TFinger 11: 00040000 Display List No Collision TFinger 4 12: 00120000 Handle/Switch 13: 00040000 Display List No Collision rightGrip 6 14: 00120000 Handle/Switch 15: 00040000 Display List No Collision fingersrear 7 16: 00040000 Display List No Collision Grip 8 17: 00120000 Handle/Switch 18: 00090000 Head/Hat Placement 19: 00090000 Head/Hat Placement 1A: 00040000 Display List No Collision mid 11 1B: 00040000 Display List No Collision ring 10 1C: 00040000 Display List No Collision Pinky 9 1D: 00090000 Head/Hat Placement 1E: 00120000 Handle/Switch 1F: 00040000 Display List No Collision thumb 12 20: 00040000 Display List No Collision lowerframe 13 21: 00090000 Head/Hat Placement 22: 00120000 Handle/Switch 23: 00040000 Display List No Collision Knuckles 14 24: 00120000 Handle/Switch 25: 00120000 Handle/Switch 26: 00040000 Display List No Collision Wrist 15 27: 00040000 Display List No Collision slideGuard 16 28: 00020000 Position TopSlide 29: 00090000 Head/Hat Placement 2A: 00040000 Display List No Collision sights 19 2B: 00090000 Head/Hat Placement 2C: 00090000 Head/Hat Placement 2D: 00040000 Display List No Collision top 18 2E: 00040000 Display List No Collision sides 17 2F: 00040000 Display List No Collision hamer 20 PPK/Silenced 00 [02 Position] (main) (Command: 0000) (Matrix: 00000000) PRef 05 (using self as PRef) 01 [12 Handle/Switch] 02 03 01 Use Handle 01 on part 02 (Hide flash) 02 [02 Position] (muzzle flash near) (Command: 0001) (Matrix: 00000040) 03 [02 Position] (muzzle flash far) (Command: 0002) (Matrix: 00000080) 04 [04 Display List No Collision] MFlash 05 [04 Display List No Collision] NMflash 06 [15 Position Held-items] (0003) (Matrix: 000000C0) 07 [09 Head/Hat Placement] 08:30 (30>8>A) YES 08 [12 Handle/Switch] 09 -- 23 Use Handle 23 on part 09 09 [04 Display List No Collision] 03 Barrel 0A [09 Head/Hat Placement] 0B:21 (21>B>28) WRONG should be B>21>28 0B [09 Head/Hat Placement] 0C:10 (10>0C) yes 0C [09 Head/Hat Placement] 0D:0F (0F>0D) YES 0D [12 Handle/Switch] 0E -- 08 Use Handle 08 on part 0E (Hide finger in menu) 0E [04 Display List No Collision] 04 Thumb 0F [04 Display List No Collision] 05 frame 10 [09 Head/Hat Placement] 11:17 (17>11) YES 11 [12 Handle/Switch] 12 -- 0B Use Handle 0B on part 12 12 [09 Head/Hat Placement] 13:16 (16>13) YES 13 [09 Head/Hat Placement] 14:15 (15>14) YES Combining these = 16>15>14 YES 14 [04 Display List No Collision] 6 Mid 15 [04 Display List No Collision] 7 Ring 16 [04 Display List No Collision] 8 Pinky 17 [09 Head/Hat Placement] 18:20 (20>18>19>1C>1D) YES except D. D-Grip should be last (18>19>1C>1D>20) 18 [04 Display List No Collision] 9 trigger/Inside 19 [12 Handle/Switch] 1A 06 0C 1A [02 Position] (trigger finger) (Command: 0004) (Matrix: 00000100) 1B [04 Display List No Collision] A Tfinger 1C [04 Display List No Collision] B RightGripSide 1D [12 Handle/Switch] 1E 0D -- Remove Handle on part 1E (keep grip visible) 1E [12 Handle/Switch] 1F -- 0D Use Handle 0D on part 1F 1F [04 Display List No Collision] C fingersrear 20 [04 Display List No Collision] D Grip 21 [09 Head/Hat Placement] 22:24 (24>22) WRONG E>F>10, this tries F>10>E... Ill double check. 22 [12 Handle/Switch] 23 -- 0A 23 [04 Display List No Collision] E knuckles 24 [12 Handle/Switch] 25 09 -- 25 [12 Handle/Switch] 26 -- 09 26 [04 Display List No Collision] F wrist 27 [04 Display List No Collision] 10 SlideGuard 28 [02 Position] (top slide) (Command: 0005) (Matrix: 00000140) ----TESTING FLIP-FLOP---- [what I want = (2C>2D>2E>2B>2F) 12,13,11,14 ] Child/parent/next/previous only show tree position and have no corrolation to flip-flop 29 [09 Head/Hat Placement] 2A:2F (2A>2F) = 2f>2A>2C>2e>2d>2b wrong Parent Part: 28 2F>2A>2B>2C>2E>2D wrong Child Part: 2A 2A>2C>2D>2E>2B>2F Match, flip-flop starting normal... MinX: 0.000000 (00000000) MaxX: 8.589720 (41096F7E) MinY: -31.807751 (C1FE7646) MaxY: 0.000000 (00000000) MinZ: 21.299999 (41AA6666) MaxZ: 0.000000 (00000000) Number: 0000 number has no use, its always 0000 2A [09 Head/Hat Placement] 2B:2C (2C>2B) MinX: 0.000000 (00000000) AHA! Success, Using numbers from 2C produced B>C order, now to find out why. MaxX: 14.569698 (41691D7C) MinY: -51.424210 (C24DB264) MaxY: 0.000000 (00000000) MinZ: -15.061374 (C170FB63) MaxZ: 15.061375 (4170FB64) 2B [04 Display List No Collision] 11 Hammer 2C [09 Head/Hat Placement] 2D:2E (2D>2E) MinX: 0.000000 (00000000) MaxX: -6.283808 (C0C914F5) MinY: -31.807751 (C1FE7646) MaxY: 0.000000 (00000000) MinZ: 21.299999 (41AA6666) MaxZ: 0.000000 (00000000) 2D [04 Display List No Collision] 12 LowerTopslide 2E [04 Display List No Collision] 13 upperTopslide 2F [04 Display List No Collision] 14 Sights 30 [04 Display List No Collision] 15 Silencer Stiped out head/hat cords to compare directly for patterns. I may have found one, 0x41 = 1>2, else 2>1 ok, so 0x41 does not work on its own. also, using 2C numbers on 07 has no effect 0A 0000000042275CFC4292B3EA00000000 41 AA666600000000 1>2 ORDER 0.000000 41.856430 73.351395 0.000000 21.299999 0.000000 21 BF926D054260560B4296319E410B0AB4 41 6398ECC15428B5 1>2 ORDER -1.143952 56.084026 75.096909 8.690113 14.224834 -13.259938 ===== Faces Back toward player, front is drawn Last (Wrist), Back is drawn First (Knuckles). 29 0000000041096F7EC1FE764600000000 41 AA666600000000 1>2 order 0.000000 8.589720 -31.807751 0.000000 21.299999 0.000000 2C 00000000C0C914F5C1FE764600000000 41 AA666600000000 1>2 order 0.000000 -6.283808 -31.807751 0.000000 21.299999 0.000000 17 BF9EE829426627684295DCFE414E1FC9 40 8AD45FC1832F9C 1>2 ORDER -1.241460 57.538483 74.931625 12.882760 4.338424 -16.398247 2A 0000000041691D7CC24DB26400000000 C1 70FB634170FB64 2>1 order 0.000000 14.569698 -51.424210 0.000000 -15.061374 15.061375 ===== faces 45 down and forward and ofset from origin by -993 crossing y=0 07 000000004267D3854336073142200000 00 00000041AA6665 2>1 ORDER 0.000000 57.956562 182.028091 0.000000 0.000000 21.299997 ===== passes through origin, points forward. back = silencer. since we are "back" (as plane faces away from us) back is drawn first. 0B 0000000041DB2D324292B3EA00000000 C1 AA666500000000 2>1 ORDER 0.000000 27.397068 73.351395 0.000000 -21.299997 0.000000 0C 415E87BD4267D3854292B3EAC1AA6666 00 00000000000000 2>1 ORDER 13.908139 57.956562 73.351395 -21.299999 0.000000 0.000000 10 41955AE54267D3854292B3EAC1AA6666 00 00000000000000 2>1 ORDER 18.669382 57.956562 73.351395 -21.299999 0.000000 0.000000 12 00000000C22DA2DE4292B3EA00000000 C1 AA666700000000 2>1 ORDER 0.000000 -43.409050 73.351395 0.000000 -21.300001 0.000000 13 420BF7C8C19715D0428FA9E4410D36D7 C1 9B0D89BEC43CC0 2>1 ORDER 34.991974 -18.885651 71.831818 8.825889 -19.381609 -0.383276 ---Binary order check --- 07 headhat [ 00000000 4267D385 43360731 42200000 00000000 41AA6665 050001E0 050005A0 ] 050001E0 leads to 09 barrel 050005A0 leads to 30 silencer So order is definatly not defined by P1/P2 references as they are the same no matter which order. order must be done on cpu as display list tree runs in order specified. this is a damn mystery... well, Ive done enough to place triangles in areas without wrong order. ------------------------- Been told that the guns were created like other objects with NinGen using a mix BSP tree and Z sorting. I cant help but notice that the 2 ordering systems are opposit Z, yet changing the numbers has little effect. The mention of Z Sort could mean that the silencer is drawn first becuase it has a higher Z value on test where the z is for whole part and not per pixle like zbuffer in rendermode. Binary Seperating Plane (MultiGen .flt Spec) --------------------- So, 09 is a BSP where 2 reference parts are decided upon "front" and "Back" by position against plane and plane direction. The MultiGen .flt file specifies a BSP as 2Byte Opcode 2Byte Legnth of record 8Byte 7Char ID (ASCII) 8Byte a 8Byte b 8Byte c 8Byte d Where ax+by+cz+d=0. If ax+by+cz+d>=0 then part is "front" else "Back" As to how this is converted... well... thats another story... we seem to have an extra 8bytes of data once flt2c strips out the ID and Legnth. (ID is used as gfx_ID[] in C, but lost in compile) Also, GE uses "Leafy BSP", where instead of each poly being a plane, there are BSP nodes followed by 2 groups of orderd triangles, Front and Back. ========================= Update 8/1/16 ======================= Ok, I think I have finally cracked it... Its taken a while and its probably obvious... the values seem to fit a Point and Vector (Un-normalised) so, basically, the reason the -21's and 21's pointed opposit was because thair normals point opposit. Im sure you can get better maths than me. My value assumptions are, 6 Floats as already indicated. Point (x,y,z) and Vector (a,b,c). The point places the plane, while the vector gives it direction. The Vector needs to be normalised to unit form to give the proper location when entered into ax+by+cz=d where D is an intersection with an axis. ========================= Update 11/1/16 ======================= Just wanted to update this topic with some concrete evidence. [b]Rules for Binary Seperating Plane.[/b] BSP Nodes Must Reference 2 parts, eg part 30 and Part 08 Reference 1 Must be the Lower Order Part - eg 08 Reference 2 Must be the Higher Order Part - eg 30 If you use the wrong order then they fail to draw any children. These references define which branch is on which side of the plane. [i]In Leafy BSP tree nomenclature this is "Left" and "Right", but put simply, we have a "Front" of plane and "Back" of plane.[/i] Reference 1 is "Left" or "Back" Reference 2 is "Right" or "Front" BSP 07 References Parts 08 and 30 and the plane points forward. This assigns part 30 to the front which points away from the hand, therefor drawing first as being "Behind" the plane (Refer to BSP Drawing order). If we turn the gun round, like in the watch, then Part 30 would be in front of the plane as we look at it, therefor drawing last as "In Front" [img]http://fgfc.ddns.net/PerfectGold/GunBSP/BSP-07_Rest-Silencer.gif[/img] Planes do not nessesarelly have to split parts exactly, but they should. There is no down side to not being alligned, as the below examples show. (I have multiplied the vector lines x10 so they are more visible) [img]http://fgfc.ddns.net/PerfectGold/GunBSP/BSP-2C_Topslide-Frame.gif[/img] [img]http://fgfc.ddns.net/PerfectGold/GunBSP/BSP-2A_Hammer-Topslide.gif[/img] If the plane was wildly off then odd results will show, so best to be sure. To swap the order you Invert the Vectors.(Format is PointX, PointY, PointZ, VectorX, VectorY, VectorZ) eg: to Draw part 30 on top of the rest, invert BSP 07 Vector to -Z, [ 0,0,-21 ] To Draw the UpperTopslide below the LowerTopslide invert BSP 2C to -Y, [ 0,-21,0 ] BSP are Confirmed to be used in Start. I have a slight error in the PPK where somewhere along the line it draws double-sided. If the silencer draws first, it is single sided, if drawn last its double sided. As the gun rotates it switches from single to double sided. I made 2 examples with inverted BSP vector (07) and they appeared opposite to each other. From the front of the gun, the silencer is drawn last. (Because we and it are in front of the plane) [img]http://fgfc.ddns.net/PerfectGold/GunBSP/BSP-07_Rest-Silencer_StartComp2.gif[/img] This can be seen in the watch as I left a cull command open on the sights. Because of this, the silencer appears bolder since its drawing both front and back faces. [img]http://fgfc.ddns.net/PerfectGold/GunBSP/WatchBSP_Normal_Front.gif[/img] From the Back of the gun (as held), the silencer is drawn first, or if you will, the rest of the gun is drawn last as both we and the rest of the gun are on the same side of the plane. [img]http://fgfc.ddns.net/PerfectGold/GunBSP/BSP-07_Rest-Silencer_StartComp1.gif[/img] This can be seen in the watch as the open cull command has not yet been reached and so only the front faces of the silencer are drawn. [img]http://fgfc.ddns.net/PerfectGold/GunBSP/WatchBSP_Normal_Back.gif[/img] When I invert the vector of BSP 07, the opposit is shown in watch. [img]http://fgfc.ddns.net/PerfectGold/GunBSP/WatchBSP_Invert_Back.gif[/img] [img]http://fgfc.ddns.net/PerfectGold/GunBSP/WatchBSP_Invert_Front.gif[/img] The first image shows a double sided silencer away from us, and a single sided one towards us. This means the silencer is last, then when closest to us, first (being overritten by everything else, as you can probably see the topslide taking over the silencer) I hope this all makes sence, but its finally easy to swap orders and move planes around for our Goldfinger Guns. I had a quick look in PD and there are no 09 opcodes at all, so, opcode 09 needs [b]re-named [/b]to [b]BSP[/b], and yes, that does mean that there is a Binary Seperating Plane between the neck and head. This is to draw the head on top of the body although, has anyone checked the z-buffer status for heads? If they are z-buffered then it may be that they were originally not going to be z-buffered. Having the BSP there on z-Buffered surfaces has no effect, in fact, a properly BSP'd model can help speed up the z-buffer, the rules are opposit to guns though. eg. z-buffered surfaces are drawn Front to Back. This saves Z-Buffer re-write and incurs only a read and can speed up a scene x2. Trev ==============================================================