40 réponses à ce sujet

[Magic]

Hey. Are you still working on it? I had some problems with the new toolset version yesterday.



IsFriendlyFireParty() is probably working differently than you'd expect. Basically it only returns whether oDamager and oTarget are followers. Friendly fire needs only to be considered in such cases, that's why this function exists. Changes here would only allow to let followers do more friendly fire (return FALSE) or let monsters respect the difficulty setting as well (return TRUE).

[Rolenka]

Right, I was experimenting with modifying the AOE scripts to say if IsFriendlyFire returns FALSE, do damage. I didn't actually modifiy the function, I was just calling it from the cone effect script (as a test). My post wasn't very clear.

Modifié par Rolenka, 19 décembre 2009 - 04:45 .

[Magic]

Oh I see - I misunderstood. Your original "idea" / solution already seems to be a very good approach though.

[Dheuster]

The original problem... compiling scripts... can be solved by throwing a void main {} at the bottom of the _h file. I dont know if that is enough for this game, or if you have to actually trace the event back to the root handlers. I see you have moved on since the originl question.



The trunk of the event tree starts in 2DA_base.xml (which says all files starting with engineevents are merged together for events). Which points you to events.xls (where engineevents is defined). All of this is located in tools/Source/2DA/events.xls



Shows the events and the script entry points. This allows you to trace from the bottom up how things are handled given an event. I am doing the same thing (No AOE damage), however I am implementing it as a skill that mages can choose to invest in or not. Instead of doing the individual scripts, I actually have my own engineevents_custom.xls that redefines Event 33 (Apply effect) to execute my own custom script instead of rules_core. Then my custom script either ignores the event (if the Caster has the proper skill and the target is friendly) or passes it along to rules_core. The advantage of this is it is a lot less code. I can also interecept any damage event regardless of origin (wether it is magic, item, or some new thing spell added by another mod that I dont even see).



I have a post here in this forums. Let me know how yours works out. Are you planning on updating the AI so that friendlies do not run out of the AOE spell radius?

[Rolenka]

I'm still very unclear on how to trace an event to a script that handles it. I opened 2da_base and events.xls, and the only script events.xls points to is rules_core a handful of times.

Honestly I don't even know what I'm looking at. Is there some sort of "intro to events" guide somewhere I'm not aware of?

I'm using OpenOffice, if that matters.

To answer your question, no, it hadn't occured to me to change the AI. The players can do that themselves, can't they? Just set to Aggressive or something else that ignores AOE?

Modifié par Rolenka, 21 décembre 2009 - 03:56 .

[Magic]

Dheuster, I agree with you that a main() in the header lets the header compile. However, that's only good to see if there are errors in the code, right? Scripts which include the header need to be identified and compiled anyway to make the changes work. And, when doing so, the main() in the header needs to be removed again else there will be a conflict. Actually, I think you are aware of this. Just wanted to write down to the dear reader why one would add a main() into a header and when not.

That's an interesting thing you did with the events. I wasn't aware that you can redirect the effect application event as well. Nice. Your modifications are a lot more powerful than necessary to handle Rolenka's original task though.

Good point with the AoE AI. How is it handled for the Easy setting? Maybe a simiar script modification is in order?

[Dheuster]

As far as I can tell at the moment, engineevents is more or less an OVERRIDE file. That is, the engine appears to have default values hard coded that it uses if there is no value in engineevents. This sort of sucks because then it falls on us to figure out what the default handler module is if the event script isn't already specified. I have found very little documentation on this. Anyway.. at least the game supports event interception, though they need a guide badly to help encourage good habits. Most things can be done using the subscription model, but in the case of preventing damage, we need a more obtrusive approach.



As for compiling... I need to do some tests to verify that these nss files that have an _h on them are in fact ignored. It isn't real C in the sense that you have a different header extension for header files. All of these files are .nss. Just as all the folders are ignore, I am not certain that the compiled code isn't simply a large laundry list of entry points. Due to some problems I had earlier playing with core_h and compiling it by simply adding main to the bottom, , I am not certain that they behave as normal header files. I will clarify this later today so I can talk about it in the developers guide.



I also noticed I started a new project and all the changes from my earlier experiments were still present. I was hoping to get a fresh copy of the core_h file I screwed up... but I didn't. Instead I had to use the version history to restore the original file. Here is hoping I am not permanently screwing the game up with all my edits. =)



Wether my approach is overkill or not is actually the question I posted... but I have to say, looking at all of those effects scripts, I would imagine a lot of edits will be more prone to error that 1 big optimized edit closer to the root of the event tree. Though while my method prevents damage, the fireball knockdown (secondary effect) is still happening. So I may still need to intercept a few specific spells to prevent secondary effects. We will see. I will play around a little more tonight and see how the fireball impact is handled and if it is an event I can intercept.

[DeepImpact]

It´s my experience, that editiing header-files is impossible (a week of testing).



But you could copy complete scripts from the header-files and use them in your script. I noticed no problems with that.



the header files or global and independend of your module. You could do what ever you want . it wont effekt or module or the core-game.

[Magic]

DeepImpact, I'm not quite sure what you want to say. Surely header files can be edited. Do you mean editing header files only will have no effect in the game? That is the fact leading to this topic in the first place. You need to recompile the non-header scripts which call the modifications in the header to see any results.

Dheuster, you mentioned another interesting aspect about the headers. I'm interested in your tests. Unfortunately, the toolset is currently not available to me. I assumed the compilation of headers behaves like in NWN but this surely doesn't need to be so.

I agree with you on the potential problems with modifying core scripts. That's why I avoid it completely but of course, modifications to the core rules will generally require such changes. I just hope that modders are aware of the necessary updates required by each official patch to the core scripts.

I'm not sure what you mean by "normal header files". Yeah, they have little in common with headers, they are includes. So we need to include them.  Not sure why they have been named as headers in the first place.

[Dheuster]

If you have a c program, normally when you run "make" you create a bunch of .o files and then you link them together. If you have separated out your .h files properly (no inline code), you can make implementation changes and only the corresponding .o file must be recompiled. Granted, re-linking is always needed.



As a newbie, I thought that Generate Module XML was like a linking step... but I am finding that it is not. There isn't really a LINKING step here. Rather the engine uses 2DA files to link events to compiled scripts. So the #include convention here has nothing to do with linking. It is basically simple code substitution.



And so, you are correct Magic. Editing _h files (even compiling them) has no effect. I assume that editing one of the core files like abilities_core and compiling it would.. but I haven't actually tested this yet.



It also seems that the version database that the toolset uses doesn't differentiate between projects. If I check in changes to area_core in one project and then switch to another... the same change is present... area-core has the same version history... etc... So even if those files are local to the toolset, there is still only 1 copy of those files per toolset, regardless of how many mods you create.



So it is best not to touch the original core files. The best approaches appear to be:



1) Use the "Script" property on the module and point to your own custom module_core script (duplicated and renamed) where you catch any events you care about and redirect handle them with your own custom scripts (or pass them on to the games default handlers).



or



2) Edit the 2DA files so that they point EVENTS to your own custom event handlers directly.



In truth, probably the Script property is the cleanest approach (most compatible with other mods) but as far as I can tell it doesn't support event interception. I am going to do a little more testing tonight to verify that is true.

[Magic]

Yeah, I'm always glad if I don't have to do the linking manually.

Thanks for the confirmation. Yes, I think the database and core scripts setup has been designed to support official patches to the core scripts as well as custom expansions on top. However, it does not support custom modifications to the core scripts well. I fully agree with you on 1) and have no experience with approach 2). However, I tend to agree that 2) is still better than modifying core scripts. It's easier to restore the core behavior by removing the 2da, and customization per module is possible as well. Unfortunately you need to modify the 2da_base for a custom 2da, right?

I haven't noticed to what you are a newbie, by the way.

[Rolenka]

So... if I want to modify what happens when an event fires, I have to comb 2da's to find what script handles it (a few are in events.xls). And if it's a header script, I have to find what non-header script calls the function I modified. And that has to be found by trial and error of opening scripts and looking.

Is that right?

Modifié par Rolenka, 24 décembre 2009 - 11:53 .

[Dheuster]

Pretty much.. except that the core events never redirect to a header file. They always redirect to one of the "Core" script files. (IE: One that does not end with an _h).



The other "gotcha" is that many events start off as a COMMAND_PENDING and then morph into smaller more specific events that hit the actual spell scripts. In some cases (such as spell_aoe_instant), the script calls an engine method that causes a new event to be sent only to the calling script. So... there is no way to intercept EVENT_TYPE_SPELLSCRIPT_INDIVIDUAL_IMPACT by editing a 2DA file because the script that generates the event doesn't "share" the event with the rest of the tree. When I wanted to intercept fireball's knockdown effect, I had to intercept the event earlier and do a whole lot of work I didn;t

want to do.



So basically, there are guidelines, but there is no golden rule or silver bullet. You have to trace through the code no matter what you want to do and figure out how to make it happen. You can actually prevent damage pretty easy, but secondary effects are much harder to prevent because most of them are created by the spellscripts in such a way that they are not interceptable at the root.



Myself, I am intercepting EVENT_TYPE_APPLY_EFFECT at the root to prevent most damage. However EVENT_TYPE_ABILITY_CAST_IMPACT is generally the last interceptable opportunity for most spells that have secondary effects. Then again, that particular event normally goes to ability_core which in turn pulls the handler script from the the "spellscript" column in ABI_base. So if you override the spellscript column in ABI_Base, you coul probably achieve the same thing. Redirect to a dupliacte of the original handler with a different name and your edits.

[Dheuster]

http://social.biowar...m/project/1470/



In the files section I have a developer diary if you would like to see what I did. I also include links to my source code.

[Rolenka]

Magic wrote...

Well, instants go through combat_h.nss but end up in player_core.nss as well. If you only changed IsDamageAllowed(), player_core.nss is probably the only thing to recompile.

Interestingly, spell combos go through module_core.nss into sys_comboeffects.nss.

Edit: Nope, wrong assumptions about the instants on my side. They go into rules_core.nss.

I tried it myself now because it's done pretty quickly:
1. Open local copy of effect_damage_h.nss, comment out the casual difficulty check, save.
2. Open local copy of player_core.nss, compile.
3. Open local copy of rules_core.nss, compile.

I finally went back and looked at those scripts you (correctly) had me compile.

The weird thing is, neither of them call IsDamageAllowed(). What they do is have "case EVENT_TYPE_DAMAGED" (rules_core) and "case EVENT_TYPE_DOT_TICK" (player_core).

So you just sort of have to assume from that that you have the right files.

To make matters worse, events.xls lists the events, but not which file handles them.

I know, I'm sort of slowly catching up to how you did it. So you just sort of did a Find for the events in the scripts because it made sense that they might be there?

[Magic]

Sorry, I was on vacation (and still am) with limited internet access. Should use the status message after all, I guess.

To make your changes work, I started with the damage effect from the Blizzard spell as an example and followed the scripts until I reached IsDamageAllowed(). You can see the path on the first page. player_core.nss is calling the function indirectly, so this script needed to be recompiled. It actually makes me wonder, when you searched for all the dependencies of effect_damage_h.nss, didn't player_core.nss show up? Maybe you dismissed it as a core include?