So can some explain what the purpose of the script property on items is for?
I originally assumed that items would get sent on equip and on unequip events, but I've tried testing this a few times, and the script never responsds to either of those event.
I just ran another test, where the main() function just prints a statement to the log everytime the item script gets an event, and so far, it hasn't received a single event.
So I'm not quite sure what the purpose of this property is.
I guess maybe you could specifically route an event to the item, then would that script handle the event?
Other than that, anyone know what its for?
the Script property on items - what's it for? it doesn't seem to receive on equip/unequip events so...
Débuté par
kilrex
, nov. 29 2009 07:01
#1
Posté 29 novembre 2009 - 07:01
#2
Posté 29 novembre 2009 - 07:16
Well, there are used to get events sent to the item. However, the event triggered by item acquisition (EVENT_TYPE_CAMPAIGN_ITEM_ACQUIRED) is sent to the module script, and only if the ITEM_SEND_ACQUIRED_EVENT item local var is set to 1.
Modifié par Phaenan, 29 novembre 2009 - 07:17 .
#3
Posté 29 novembre 2009 - 07:32
That being said, I am currently trying to make an item assigned script to handle events, and it sure as hell doesn't bother to answer me, even when I hit the script with a vicious SignalEvent()
Soo... Not really sure what should be done in order to make those scripts grab the events sent to the item.
Soo... Not really sure what should be done in order to make those scripts grab the events sent to the item.
Modifié par Phaenan, 29 novembre 2009 - 07:33 .
#4
Posté 29 novembre 2009 - 11:09
Those scripts weren't used in the main campaign. You could try EnableEvent before sending an event to the item, but I'm not sure if they are functional at all.
#5
Posté 30 novembre 2009 - 12:11
Hmm, worth a try.
* 2 min later *
Nope, no love !
Cheers for confirming it, this way no one will waste time wondering what going wrong.
* 2 min later *
Nope, no love !
Cheers for confirming it, this way no one will waste time wondering what going wrong.
Modifié par Phaenan, 30 novembre 2009 - 12:11 .
#6
Posté 30 novembre 2009 - 03:07
yep, thanks for the confirmation.
I'll quit poking it with a stick now
I'll quit poking it with a stick now
#7
Posté 30 novembre 2009 - 07:16
Edit: Misread the function name
Modifié par Nodrak, 04 décembre 2009 - 07:18 .
#8
Posté 05 décembre 2009 - 12:13
The reason is simple: Some areas have several thousand items in them, if we ran scripts on them, the game would run at 0.5fps
#9
Posté 05 décembre 2009 - 05:10
lol I guess 0.5 FPS might be just a little slower than some people would be willing to accept.
But only by a little
But only by a little
#10
Posté 05 décembre 2009 - 10:31
Well, look on the bright side : that'd give people time to think about their next combat move.
#11
Posté 05 décembre 2009 - 05:37
GZ is incorrect, if the items ran scripts only when equipped or unequipped, as the OP had surmised, the game's FPS would surely not be so adversely affected.
Nice try though.
Nice try though.
#12
Posté 05 décembre 2009 - 07:22
Any object with a script field (aka a full game object) would be processing on the main AI loop which checks each of the objects for pending events. Checking 100 creatures for pending events is expensive enough, what do you think would happen if it would have to go through all items in an area instead on each loop
Hence the reason for equip being on creatures, not items and items not running any AI at all.
Thanks for trying to explain me how the engine works though, I always wondered about that
Hence the reason for equip being on creatures, not items and items not running any AI at all.
Thanks for trying to explain me how the engine works though, I always wondered about that
georage wrote...
GZ is incorrect, if the items ran scripts only when equipped or unequipped, as the OP had surmised, the game's FPS would surely not be so adversely affected.
Nice try though.
Modifié par Georg Zoeller, 05 décembre 2009 - 07:22 .
#13
Posté 05 décembre 2009 - 08:47
Thanks for the insight.
But, from a programming standpoint, how is a "full object" different from any other object? That does not make sense to me. I have never declared a half object.
And, not to be a polemicist, but why make an engine that checks ITEMS within a main AI Loop?
I have never known an ITEM that requires AI. Do we expect a sword to realize the battle is hopeless and flee the player's hand?
Even the talking sword (Enserric sp?) needed a placeable (a full object?) to work, after all.
In NWN, items on players or in containers were not (from what I recall) included in GetNextObjectInArea loops. It seems the game engine in DAO would operate along the same lines and disregard items in containers.
Which leads to the question, what area has thousands of loose items in it? Perhaps objects, but not items. Is there an area where thousands of items litter the floor outside containers? I played the OC through and do not recall such a thing.
But, from a programming standpoint, how is a "full object" different from any other object? That does not make sense to me. I have never declared a half object.
And, not to be a polemicist, but why make an engine that checks ITEMS within a main AI Loop?
I have never known an ITEM that requires AI. Do we expect a sword to realize the battle is hopeless and flee the player's hand?
In NWN, items on players or in containers were not (from what I recall) included in GetNextObjectInArea loops. It seems the game engine in DAO would operate along the same lines and disregard items in containers.
Which leads to the question, what area has thousands of loose items in it? Perhaps objects, but not items. Is there an area where thousands of items litter the floor outside containers? I played the OC through and do not recall such a thing.
#14
Posté 05 décembre 2009 - 11:44
That is what I tried to explain to you. Items do not inherit from a game object that supports AI, hence the 'script' field does nothing on them.





Retour en haut






