Am Montag, 13. November 2006 09:54 schrieb zz zz: > wzinputpatch2.patch: > > 1.Changed mouse key KEY_STATE enum from 0,1,2,3,4 ... > to 1,2,4,8,16 ... > > 2.Changed aMouseState[MAX_SCANS] from KEY_STATE to UBYTE > > 3.Changed the mouse 'key state' in inputProcessEvent to bitwise > operation,prevously each 'key state' was exclusive,that's what makes > 'double click' event so hard to implement in my opinion. > > 4.Added a static Uint64 CurrFrameNum to get frame number in > InputProcessEvent function,'double click' event is triggered when there are > 2 'KEY_DOWN' events within (1 + frameGetAverageRate()*0.25) frames.(thanks > to Gerard for the '1+frameGetAverageRate()*0.25' idea) > > projfix1.patch: > > 1.Fixed a bug,which enables you to destroy oil resource/artifact/pickup > permanently. > > Problems in previous patches by me: > > 1.Concerning the crash problems with uninitialized asWeaps[0].nStat,the > uninitialized behavior is intended because non-weapon droid's > asWeaps[DROID_MAXWEAPS] should never be ininitialized. > > 2.The uninitialzied numWeaps problem is a compability issue,in old template > format in droid.c,'numWeaps' was commented-out,I re-enabled it recently > when adding multi-turret,so the 2 trucks given to you in skirmish might > have a corrupted or uninitialized numWeaps value under certain > circumstances when copying 'non-exist' numWeaps values from old template > format data. > > 3.I think the crashes have something to do with a bug in original code: > > Droids with 0 weapons/numWeaps were never supposed to be checked in those > functions,but the safety check 'if (psDroid->numWeaps > 0)' in various > functions was commented-out by someone for unknown reason,instead,they use > 'if (psDroid->asWeaps[0].nStat > 0)' hack to check whether a droid has a > weapon or not,which can be bypassed by a '0xcd'/'0xdd' marked uninitialized > value easily and results in a null pointer crash eventually.I just > re-added/uncommented 'if (psDroid->numWeaps > 0)' and it cured the crashes. > > 4.Projectile target prediction vector z is not used for ground units is > because the height difference between 2 ground units is usually > negligible,I'll make all target prediction to take vector z into > consideration if ground units have problems hitting each other on > higher/lower terrain. Ok, I'll do some heavy testing on mountain maps. ;) (Would it create a negative effects to use z for all? Like performance etc...)
> 5.The connectors(hardpoints) position problem(2nd and 3rd turret 'stack') > is due to the size problem of a .pie for a 'body',the body pie in wz are > way too small/narrow for multiple weapons,not to mention the turrets are > too big in wz,even light body with 1 ripplerocket looked rediculous.There > is no cure for this unless someone with artistic skills remake the body > pies with greater scale. So my idea was to remove the 3rd stacked turret from usual heavy bodies and just add it for the still-to-come ultra-heavy-bodies. --Dennis
pgpArDqcRD5Us.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
