Some notes for D:OS 2:
Both APIs for example have no way to query the items equipped by a character nor can the items themselves be examined.
This was partially addressed with the "CharacterGetEquippedWeapon" and "CharacterGetEquippedShield" functions. Still no way to query the whole set of equipped items though
One possibility would be using ItemLaunchIterator to iterate through all items and check them one by one, or alternatively keeping an "is equipped" database by hooking ItemEquipped and ItemUnEquipped, and storing the items into the database. Both are quite nasty workarounds though.
A summon will *not* qualifiy as player2, because like a spawn, a summon is not a global character known at compile time.
Would it be possible to use "CombatGetNumberOfInvolvedPartyMembers" and "CombatGetInvolvedPartyMember" to enumerate summons?
paranoia of object handle waste ;-
Object handles are finally 64-bit, so we cannot run out of them like in D:OS 1.
I thought this thread was about EE modding so handles being 64 bit in D:OS2 is not very helpful for EE modding ;-) (They seemed to have been 32 bit in EE already as it looks, see below.)
Hey, shame on you, YOU are the 'Father of EE modding', Sir, you've already forgotten your own child ? ... ;-)
I've thought about keeping track of equipped items with the equip events a couple of time but find it an overkill personally. I don't have the editor open, so cannot look it up, do the equip events take ITEMs or ITEMHANDLEs ? If it's ITEMs, it won't even be thrown for non publics in EE.
Anyway, whenever thinking about the monitoring I decided against it because I find it complete overkill. Almost as bad as polling in programming ;-)
With player2, it's not about querying if a summon exists but about the role, a lot of existing story scripts and dialogs expect a CHARACTER_PLAYER2 to exist.
Actually, handles in EE were not even 32 bit, because that would already have been enough to never have to worry about them.
Raze once gave us the information, that the handle generator is actually a simple counter. A patch note once said, they increased the handle limit to 64k.
Although I don't know it, I suppose, they use a 16bit short for the handle counter. Extending the possible pool from 32k to 64k might have been a simple change from 'short' to 'unsigned short'.
Looking at a save file one time, I came to think that they use several 16 bit short counters for different purposes of handles and 'shift' them to certain windows of a 32bit int, simply by bit-or'ing them with e.g. 0x10000 for items, 0x20000 for characters, 0x30000 for scenery and so forth. Maybe a remainder - as so many things in classic and EE - from earlier Larian games.
The values I saw in the save files were all above 2^16, so it cannot be a pure short that's used to store the actual handle, it's probably a 32bit int.
It's only a stupid implementation of the handle generator that introduced the 64k limit. And even that would have never been a big problem if there was a 'used/free handles bitmap' that would have enabled handle re-use.
The latter could probably never be implemented because none of the API functions ever released their handles, or more precisely, they would have had to report the handle release to some handle bookkeeper which was not the case as it seems.
Version 2 looks like a big cleanup from what you posted in the other thread. Good for future modders. Maybe they finally do it correct instead of 'as quickly as possible', and generic instead of 'what we currently need'.
(Maybe even the extremely annoying 'Magic Pockets' popups can be turned off but I have doubts. They were the main reason I disabled this whole functionality for shovels and pickaxes in XC_Bags ;-)
... and maybe they even implement a real 'game timer' which they wanted to do a long time ago as one of the comments in an Osiris file suggests ;-)
