Hi guy's im helping jedimaster76 with his recruitment mod and i need to know where to put an on enter script for the dantooine crystal cave module in K1? :lsduel:
Well, the crystal caves are in module danm14ae. In m14ae.are there is nothing listed for the OnEnter parameter, so there is no OnEnter script for that module. You can extract m14ae.are and edit the OnEnter parameter to point to whatever your custom script is called. Put the changed .are file and script in the Override directory and you should be good to go.
At least, that is how I remember doing it. :D
I usually wouldn't put modified ARE, GIT or IFO files in the override folder though, since the ARE files usually are named the same for all areas sharing the same basic model set, which can create conflicts in some cases.
(GIT files can conflict with GIT files in the savegames which permanently freezes the area at its default state if you put them in the override folder, and all IFO files are named the same for all modules.)
It's usually best to put the modified area files back into the module you extracted them from, in my opinion. Reduces the risks of conflicts. :)
Thanks guy's but can i just edit an .ARE file in a gff editor?
The best thing to do is forget the onenter script and use something in the caves that fires a script, like the crystal formations, you can easily place a script to run once there without having to edit a ton of wierd ARE or GIT files. ;)
Why not just use a trigger to fire the function you want to fire? You could put it near the enterence and have it fire when the player walks over it. Well whatever you do I hope it works out.;)
Of course creating a trigger for an area brings us right around full circle with the discussion about the onEnter script. If you are creating a trigger then you have to place it within the module. In order to place it in the module you have to have it edited into the GIT file or have a script create it.
Stoffe's point is most valid above. The TSLPatcher which she didn't mention can modify the files directly within there RIM's so that the modification doesn't cause conflicts.
As RH said, if it's just for spawning a npc, I'm sure you can find another suitable place to attach your script rather than repackaging the whole module. If you're looking for a "lite" method, you could use an existing trigger if any. Maybe you could attach your script to one of those kinrath OnDeath event too. (I don't have the game with me and can't verify the available options. )
Well thank you for all your suggestions, but i think that puting an on enter script is the way to go, as we can just do what stoffe said and pack all the files back into a module file. But thank you all.
^That will pack your mod out somewhat excessively, though...
I'd strongly recommend replacing either dan14_deadman.utc or one of the kinrath eggs (e.g. dan_egg003.utp - since neither is likely to be re-used elsewhere) for this, using, for dan14_deadman, the OnUserDefined box. In the case of the egg, it's a little trickier to choose which script slot...I'd recommend either OnMeleeAttacked, or OnEndDialogue as the likely candidates...
This is one of the easiest methods, and would mean that your mod files would package up at a much smaller size for a greater effect with less messiness ;)
In the end, it's up to you, though :)
^That will pack your mod out somewhat excessively, though...
Not necessarily. If you use a mod installer you can instruct it to modify the OnAreaEnter field within the ARE file within the existing module RIM file. That way you won't need to pack the whole module that needs to be modified with your mod archive.
But if you don't use a mod installer I can agree it's a bit over the top to include the whole module just to change one of its event scripts. :)
Not necessarily. If you use a mod installer you can instruct it to modify the OnAreaEnter field within the ARE file within the existing module RIM file. That way you won't need to pack the whole module that needs to be modified with your mod archive.
But if you don't use a mod installer I can agree it's a bit over the top to include the whole module just to change one of its event scripts. :)
Didn't know about that feature. Sounds very useful :)
I usually wouldn't put modified ARE, GIT or IFO files in the override folder though, since the ARE files usually are named the same for all areas sharing the same basic model set, which can create conflicts in some cases.
(GIT files can conflict with GIT files in the savegames which permanently freezes the area at its default state if you put them in the override folder, and all IFO files are named the same for all modules.)
It's usually best to put the modified area files back into the module you extracted them from, in my opinion. Reduces the risks of conflicts. :)I stand corrected. :p
But... I'm fairly sure (and the KotOR Tool search function backs me up in this) that there is only one m14ae.are in the entire game - so placing it in the override shoudln't cause conflicts with the stock content of the game.
But... I'm fairly sure (and the KotOR Tool search function backs me up in this) that there is only one m14ae.are in the entire game - so placing it in the override shoudln't cause conflicts with the stock content of the game.
...until someone else decides to do anything with that area, and go the route of modifying the module directly instead. Then the changes in the module itself will never take effect since the file in the override folder blocks it. Or if another mod has already modified the file by replacing the module with a .MOD file, or modified the content of the RIM file, then installing a mod which puts an ARE file in the override folder might lead to problems that can be tricky to figure out. :)
(It will also override the .ARE file present in the savegames with the same name, though in the case of ARE files I don't think that matters since it just contains static area info anyway.)
In this case there may be no direct drawbacks of doing it if you aren't concerned about compatibility with other people's mods, though personally I prefer to put things where they belong when it's possible or practical to do so. A matter of personal taste I guess.
...Or a custom module using m14ae as a base...
...Or a custom module using m14ae as a base...
Like my Korriban crystal caves module... I tried using m14ae.* files without compiling a new mod... nothing but problems lol ;)