ACR Transition includes?

AcadiusLost · Post by **AcadiusLost** » Sun Mar 18, 2007 8:59 am

We've got quite a few names for these files floating around now, I was hoping we could consolidate / clear up confusion with these.

acr_areatrans_i.nss: has all my seamless AT code
acr_area_transition_i.nss: has Ronan's door AT code

acr_seamlessat_i.nss: some kind of placeholder Ronan put in for Seamless AT code.

Should I rename my code to replace Ronan's placeholder, so we have:

acr_area_transition_i.nss
acr_seamlessat_i.nss

Or should we think about consolidating the two into a single include?

ç i p h é r · Post by **ç i p h é r** » Sun Mar 18, 2007 3:36 pm

I agree, consolidation is necessary, but it isn't limited to transition files only. The same appears to be true for spawn files and for creature event files.

1. In the case of transitions, let's keep all the ACR area event handlers in acr_area_i and keep the seamless AT code in either acr_transition_i or acr_seamlessat_i (your preference). Since seamless AT pertains specifically to area transitions, let's stick them in events/area as well, not misc.

2. In the case of creatures, there are presently 3 files:

acr_cre_events_i, acr_creature_i, acr_npc_events_i

As with transitions, I'd like to keep all the ACR creature event handlers in one file, in this case acr_creature_i. Whatever logical branches we need to distinguish between various types of creature should exist within these central event handlers. That will keep shared code common to all creature types. If we need separate event handlers for PCs and NPCs, we can always add them, but I don't think we have anything at this juncture that specifically requires it. Virtually all the code seems to have been placeholder code pre NWN2 release so it's about time we address these loose ends.

3. For spawns, I know you're looking over Ronan's submissions, but once you review those, I assume you'll consolidate what's necessary into acr_spawn_i. At that point, we can probably eliminate any redudant code.

Thoughts?

AcadiusLost · Post by **AcadiusLost** » Sun Mar 18, 2007 4:58 pm

Well, the acr_area_transition_i.nss basically just has one function, ACR_OnAreaTransitionClick() - called by the ABR Doors OnClick. Ronan had the spawn system hooks in there to prespawn, but had them commented out until the spawn system was ready.

Is it important to keep the systems separate? It would be easy enough to move the ACR_OnAreaTransitionClick() function into acr_areatrans_i, would just mean updating the acf files for the doors to switch their includes, and it would put all our area transition scripts into one place. That function ought to work for "normal" NWN2 ATs as well, if linked there.

looking in Scripts->Core Systems->Events->Area Events, I also see an acr_sat_i.nss, which has Hialmar's Seamless AT code.

Should we perhaps make a subdirectory for discontinued code/files, and move the unused ones down into that for future reference? It would help keep things straight when preparing erfs/haks from the respository resources.

ç i p h é r · Post by **ç i p h é r** » Sun Mar 18, 2007 6:58 pm

AcadiusLost wrote:Is it important to keep the systems separate? It would be easy enough to move the ACR_OnAreaTransitionClick() function into acr_areatrans_i, would just mean updating the acf files for the doors to switch their includes, and it would put all our area transition scripts into one place. That function ought to work for "normal" NWN2 ATs as well, if linked there.

It's only important for organizational purposes. Having everything in one file makes it harder to get at the information you're interested in and having things all over the place makes it equally challenging to get at that information. We don't want to force people to sift through unrelated code to get at what they want or to needlessly hunt for it either, so the logical point of separation is along system lines. Furthermore, consistency in conventions makes it easier to climb the learning curve when trying to familiarize yourself with code. Therefore, I'd prefer changing "acr_areatrans_i" to "acr_area_i" if that's the file which defines the area event handlers. You'll notice that this is the case for all other events as well, so it's something I'm keen on preserving.

looking in Scripts->Core Systems->Events->Area Events, I also see an acr_sat_i.nss, which has Hialmar's Seamless AT code.

Should we perhaps make a subdirectory for discontinued code/files, and move the unused ones down into that for future reference? It would help keep things straight when preparing erfs/haks from the respository resources.

That's one idea. SVN doesn't seem to have a method to deprecate files (at least one I can find). CVS allows devs to "hide" files while keeping the information in the repository, which is something I was hoping we could do here as well, but alas...

Would a scripts "archive" directory be clear enough for this purpose?

AcadiusLost · Post by **AcadiusLost** » Mon Mar 19, 2007 12:22 am

An "archive" directory would work well enough for discontinued/unused scripts- I'll create one when/if we do some reorganizing in the area.

I'm a bit unclear on your recommendation with the various transition scripts- we've already got an acr_area_i.nss file, it's got the acr-standard OnAreaEnter and OnAreaExit hooks in it. I can see moving the OnClick function body there for the ABR doors and such, but moving the seamless AT code (currently in acr_areatrans_i.nss) into there would clutter up things significantly (~700 lines of code).

I'll try to catch you on IRC soonish to work out the details.

ç i p h é r · Post by **ç i p h é r** » Mon Mar 19, 2007 1:25 am

There's an acr_area_transition_i file in the events folder already in addition to acr_area_i, not to be confused with your similarly named acr_areatrans_i file (I think I made the wrong reference in my prior post - sorry about that, it's easy to confuse hence this discussion

). I think those two should be merged into acr_area_i (which is the main area event handler file) and the seamless code kept in its own file, acr_seamlessat_i. That should clarify things tremendously.