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.


Attachment: pgpArDqcRD5Us.pgp
Description: PGP signature

Warzone-dev mailing list

Reply via email to