Dillemma with onUse JS event

[Xuri]

In cPlayerAction.cpp, bool CPIDblClick::Handle( void ), the following...

Code: Select all

	ItemTypes iType		= findItemType( iUsed );
	if( !ItemIsUsable( tSock, ourChar, iUsed, iType ) )
		return true;

comes before the checks to see if an onUse JS event exists on the object, which means that it's not possible to override (for instance) the range check for doubleclicking items, doubleclicking on corpses, and more - as that is handled in the bool ItemIsUsable() function in the same file...

But move the above snippet below the JS-checking code, and we seemingly have no way of enforcing object-usage-delays (also handled in ItemIsUsable()) on items that have onUse-scripts attached, as there's no way of checking/setting object delay stuff through the JS engine - or is there?

[giwo]

The hook is after those checks because we didn't want to reproduce that code in every onUse script. It would be nice to avoid those checks in special cases, but it's not possible currently, we'd need to come up with a good all-around solution.

[Xuri]

Well, the reason I noticed it was because it broke the archerybutte-script ;/ If you stand too close, the script itself says you stand too close and won't let you use it - and if you go further away the hardcoded range-check won't let you use it =/

[Xuri]

So, any bright ideas out there on this issue? As it stands, any scripted items that require the user to be able to use it from a distance (archery buttes, house signs in my static housing-script, etc.) are unusable since it's impossible to overload the range/los-checks.

One workaround I've found is giving the item an item-type of either 203 (IT_HOUSESIGN) or 117 (IT_PLANK) as those are excepted from the range-check, but I'm guessing that this might have other, hidden implications? If not, then this is the route I will go.

Other ideas that pop up in my skull: New DFN-tags for items... RangeCheck=false/true (0/1), LoSCheck=false/true (0/1) and then check for those tags in the source-code. *shrug* I know how much Maarc/giwo hates new tags, but.. we need a way to solve this issue =P

[giwo]

Well that is a good idea you had there with house signs/planks, but yes, it could have other adverse affects. On that note, however, we could just create a new type which is to be used for that purpose and that alone.

[Xuri]

That sounds like a plan.