Aller au contenu

Photo

Events and my brain do not mix


16 réponses à ce sujet

#1
georage

georage
  • Members
  • 247 messages
I need help getting my head around area events.

I created a var_mymod 2DA and it works, the script AND04 created to display the names of items acquired never fails to work.

That is the ONLY event I can capture it seems.

In the 2DA I ALSO route all the area events to the same custom event handler script, but those events apparently never fire INTO the script. Debug messages never appear, so I know it is not firing when I enter areas.

What am I missing? Should I replace the area_core script on each area with my custom event handler script?

I am trying to use OnEnter type scripts to set up the areas depending on what point in the plot the player is at. I have been forced to use triggers at entrypoints, but fear those will not fire when a player loads up a save game.

Thanks for any help! Sorry to be posting so many questions. 

Modifié par georage, 08 décembre 2009 - 08:38 .


#2
sillyrobot

sillyrobot
  • Members
  • 171 messages
Which events, specifically, are you overriding? And is the event handler attached to the correct type of item to receive those events? Many events never fire into a module, for example.

#3
georage

georage
  • Members
  • 247 messages
Thanks for the reply sillyrobot. I have routed all of these events to my custom event handler.

EVENT_TYPE_INVENTORY_ADDED (this is the only one that works)
EVENT TYPE AREALOAD PRELOADEXIT
EVENT TYPE AREALOAD POSTLOADEXIT
EVENT TYPE AREALOAD SPECIAL

My custom script is not attached to anything ... should it be my default area script to capture area events?

I am confused because the EVENT_TYPE_INVENTORY_ADDED script in my custom script works, and it is not attached to anything.

I assumed the custom 2DA would force all 2DA rerouted events to execute my custom script first (which captures the event in a case switch), before going to the core script attached to the area. Is this not how it works?

Modifié par georage, 08 décembre 2009 - 09:36 .


#4
sillyrobot

sillyrobot
  • Members
  • 171 messages
OK, I see, I'll fiddle around a bit and get back tonight


#5
sillyrobot

sillyrobot
  • Members
  • 171 messages
Just because, I'm paranoid, what ID# do you have for EVENT TYPE AREALOAD PRELOADEXIT?

#6
georage

georage
  • Members
  • 247 messages
38




#7
FalloutBoy

FalloutBoy
  • Members
  • 580 messages

georage wrote...

Thanks for the reply sillyrobot. I have routed all of these events to my custom event handler.

EVENT_TYPE_INVENTORY_ADDED (this is the only one that works)
EVENT TYPE AREALOAD PRELOADEXIT
EVENT TYPE AREALOAD POSTLOADEXIT
EVENT TYPE AREALOAD SPECIAL

My custom script is not attached to anything ... should it be my default area script to capture area events?

I am confused because the EVENT_TYPE_INVENTORY_ADDED script in my custom script works, and it is not attached to anything.

I assumed the custom 2DA would force all 2DA rerouted events to execute my custom script first (which captures the event in a case switch), before going to the core script attached to the area. Is this not how it works?


Okay call me crazy but I don't understand how your script is ever getting run unless it is assigned to be your area script. I would assume that is the problem, but I am confused at how it is ever getting run in the first place.

#8
sillyrobot

sillyrobot
  • Members
  • 171 messages
The good news is my experience matches yours. The bad news is I don't know why... yet.

#9
sillyrobot

sillyrobot
  • Members
  • 171 messages
EVENT_TYPE_ENTER works, It fires multiple times per area transition though. Would that be workable for you?

#10
georage

georage
  • Members
  • 247 messages
FalloutBoy -- I followed the instructions below and got the EVENT_TYPE_INVENTORY_ADDED event to fire directly into my custom event override script. And the custom script is not attached to anything.



http://social.biowar.../Event_override



Areas seem to work differently however. That is what SillyRobot is helping me with.



GO SILLYROBOT GO!




#11
DavidSims

DavidSims
  • BioWare Employees
  • 196 messages
A script is only going to be run if something tells it to run. The engine needs to be told to run your script somewhere. The most basic way of doing that is making the script the default for the object, in this case the area. That will pass (almost) all events the object receives to your script. If you're making a stand-alone module or adding a new area into the main campaign, that's definitely the way to go.



You can also tell a script to run on area load using 2das, but I don't recommend that unless you want it to be a mod which is placed on top of other modules. I don't know much about that functionality myself, as it wasn't used at all to make the main campaign. It's a system designed for DLC and while I'm sure it will also be used for other mods, it's not the primary way of handling events in a normal module and it’s much more complicated than just making a standard script and attaching it to the object.

#12
sillyrobot

sillyrobot
  • Members
  • 171 messages
EVENT_TYPE_ENTER fire once per creature, so you can reduce the action by testing that the creature GetEventCreator(ev) is same as GetMainControlled(). That'll only fire for once for the player.



I'm testing if OBJECT_SELF references the area being entered now.

#13
georage

georage
  • Members
  • 247 messages
I was trying EVENT_TYPE_ENTER but a bioware guy said not to in this thread.

http://social.biowar...71/index/255550



I just reread that thread and I think the BioDude explains it, I was just to dense to read it.



Craig Graff wrote...



INVENTORY_ADDED is not a module event. It is an event which fires for each container, be it a placeable or a creature. In the case of the player, the assigned script is player_core.



There is a CAMPAIGN_ITEM_ACQUIRED event, but it is designed to only fire for items that have the appropriate local variable set.



INVENTORY_ADDED can be directed to a specific script, but you would need to be careful how you handled it, since it would potentially be firing for every object in the game.





#14
georage

georage
  • Members
  • 247 messages
Thanks SillyRobot ... if you need a job scripting quests let me know. :)

#15
sillyrobot

sillyrobot
  • Members
  • 171 messages
Ah, skimmed the thread.



The explanation that only events that fire into rules_core can be overridden this way is interesting. Non-intuitive, but interesting.



I understand why you want to be careful. EVENT_TYPE_ENTER gets called A LOT. It would be possible to introduce serious perforance problems if you don't take great care.



I'm of the school that the best way to override events is as infrequently as possible. Overriding is fraught with peril as only one override will be processed and it had better respond to all possible events correctly. If a different add-in is loaded and overrides the same events, well one of the two add-ins won't function as expected.



In your case, if your area setups affect areas not directly under your control, overriding EVENT_TYPE_ENTER with an immediate check as to the creature entering and the area is appropriate using OBJECT_SELF is probably your best bet. If you have direct control over the areas, attach a script that uses the area events directly.




#16
georage

georage
  • Members
  • 247 messages
Cool, thanks a lot for the help. I needed someone else to drive home the point.



The way events are handled confuses me, but I guess EVENT_TYPE_INVENTORY_ADDED is a peculiar one and I thought it was the norm.



I will just stick my event_override script directly on my areas and see what happens.



Thanks again to all!

#17
Craig Graff

Craig Graff
  • Members
  • 608 messages
Typically it's best to have an equivalent to area_core that you stick on your various areas (which passes through to area_core). Then if you have script that you want to fire only in a specific area, you make a script for that area and pass any unhandled events through to your main area script.

If you are doing a stand-alone module it might be best to use EVENT_TYPE_CAMPAIGN_ITEM_ACQUIRED in your module script and set the local variable ITEM_SEND_ACQUIRED_EVENT to 1 for the items that you want your script to handle.

Modifié par Craig Graff, 09 décembre 2009 - 01:34 .