8 réponses à ce sujet

[JJM152]

Is there a faster way to add a single drop to the treasure system than modifying every worksheet inside the TS_* system? I don't want to hack the treasure system directly... I just want to change the drop rates.

Probably not huh?

[FalloutBoy]

I bet you could do it without editing all those tables. If you look at the treasure system, it generates treasure when the SPAWN and DYING events happen. So you could override those functions with your own treasure script, then call HandleEvent to make the default script happen too. This way you won't affect the existing drops, but you can add your own additional drops too which can be in separate tables that you create.

[JJM152]

FalloutBoy wrote...

I bet you could do it without editing all those tables. If you look at the treasure system, it generates treasure when the SPAWN and DYING events happen. So you could override those functions with your own treasure script, then call HandleEvent to make the default script happen too. This way you won't affect the existing drops, but you can add your own additional drops too which can be in separate tables that you create.

Yeah I investigated this. The only "correct" way to do this is to override the engineevents 2da file and point it at your own handler as the first port of call for these events, then doing an inline signal directly to sys_treasure, then modifying the calling object (check for loot, modify loot, add loot), then pass the signal along (thankfully sys_treasure uses a local var to flag/toggle treasure so the system doesn't get called twice).

I could do this but then if another person made a mod that overrode these events our two mods wouldn't play nice together (probably).

[FalloutBoy]

You can't override EVENT_TYPE_DYING with your own treasure code, then call HandleEvent to call the default handler? I guess I don't know what you mean when you say "signal directly to sys_treasure". You mean call the TreasureGenerate() function? If you call HandleEvent, you shouldn't need to call into sys_treasure yourself.

Something like this:

switch( event )
{
   case EVENT_TYPE_DYING:
   CreateItemOnObject( R"phat_lewt", ... )
   break
}

HandleEvent( event, DEFAULT_AREA_HANDLER_or_whateveritscalled )
return

Modifié par FalloutBoy, 21 décembre 2009 - 06:01 .

[JJM152]

FalloutBoy wrote...

You can't override EVENT_TYPE_DYING with your own treasure code, then call HandleEvent to call the default handler? I guess I don't know what you mean when you say "signal directly to sys_treasure". You mean call the TreasureGenerate() function? If you call HandleEvent, you shouldn't need to call into sys_treasure yourself.

Something like this:

switch( event )
{
   case EVENT_TYPE_DYING:
   CreateItemOnObject( R"phat_lewt", ... )
   break
}

HandleEvent( event, DEFAULT_AREA_HANDLER_or_whateveritscalled )
return

You have to either replicate the treasure generating code, or call into it by sending sys_treasure a signal.

Or I guess you don't have to, but then you've pretty much supplanted the default treasure system and I'm trying to avoid that for compatibilities sake.

I actually have tihs working already exactly like how I described in my current mod. I just didn't like it because it's not very compatible if someone else overrides engineevents.GDA to point those 2 events at something else.

[FalloutBoy]

Can you describe exactly what you mean by "sending sys_treasure a signal" because that doesn't sound right. It sounds like you may be making things harder than they should be.

Here is what worked for me. I wanted mobs to sometimes drop a particular item. I didn't want to supplant the existing treasure code, but I wanted to add this additional item drop. So I overrode the EVENT_TYPE_DYING area event and did exactly what I posted above. Now everything drops this item in addition to their normal drops. No messing with sys_treasure whatsoever.

If I had wanted to prevent the normal drops, I could have set that local var you mentioned earlier and the TreasureGenerate function would have returned without creating anything, and only my special item would have dropped.

[JJM152]

FalloutBoy wrote...

Can you describe exactly what you mean by "sending sys_treasure a signal" because that doesn't sound right. It sounds like you may be making things harder than they should be.
Here is what worked for me. I wanted mobs to sometimes drop a particular item. I didn't want to supplant the existing treasure code, but I wanted to add this additional item drop. So I overrode the EVENT_TYPE_DYING area event and did exactly what I posted above. Now everything drops this item in addition to their normal drops. No messing with sys_treasure whatsoever.
If I had wanted to prevent the normal drops, I could have set that local var you mentioned earlier and the TreasureGenerate function would have returned without creating anything, and only my special item would have dropped.

Ah yes, I am doing things (or I was anyway) slightly different.

I needed to catch the event first then reroute it directly to the treasure routine so that I could then check the inventory of the monster/placable after the fact and look for "normal drops" that I would then replace with my own drops (actually a random chance to add properties to some normal equipment).

That's why I did things the way I did Otherwise there doesn't seem to be a way to guarentee where in the event chain your handler will pick up the signal.

[FalloutBoy]

Move HandleEvent above the switch statement. After HandleEvent returns it should have finished the normal treasure generation. Then you can do your stuff to whatever treasure was generated. At least I think this will work. It's worth a try.

[JJM152]

FalloutBoy wrote...

Move HandleEvent above the switch statement. After HandleEvent returns it should have finished the normal treasure generation. Then you can do your stuff to whatever treasure was generated. At least I think this will work. It's worth a try.

It's a little bit more complicated than that. My module is an Add-in that extends the single player campaign. If someone is running my module with another module that also extends the SP, and then the only thing that determines which module handlers get called first is either the settings in the engineevents.2da or the module priority (this is stored in an XML file and needs to be hand hacked to denote priority).

I realize that on some level there is always going to be the potential for module incompatibility... so there is no way of getting around it. I'm just trying to do it in a way that really minimizes this.