4 réponses à ce sujet

[HipMaestro]

 I'm near crazy trying to figure this out so am hoping you guys can either guide me through the steps or offer an alternative.

Essentially, all I want to do is compile a list of every convo, object, trigger, waypoint, creature, etc... anywhere a script or convo is be imbedded (i.e. linked).  Ideally, it would be handiest to just get a full list of every script/convo used in the module with all of its respective linkages but, optionally, I would at least like to be able to enter a script/convo name and get all the items that link it.

The script editor is no good for this function (at least I haven't figured out how to use it) because all it does is list strings contained inside the scripts but not where the script is linked.  

Would I need a special utility to extract this information or can it be done directly via the toolset?

Any help you can provide will save me a fortune in antipsychotic meds. 

TIA

Modifié par HipMaestro, 06 octobre 2010 - 05:47 .

[Lightfoot8]

It will take a custom tool.

[HipMaestro]

Sounds like one doesn't exist or you would have furnished a Vault link. Too bad. Would have saved hours and hours of housecleaning. Ahh well. Thanks for the reply, Lightfoot8.

[Mudeye]

 I know it's too late to do this but a way that a lot of people use to keep track of stuff like that is to use a "naming convention". An example might be that everything associated with a particular quest gets a certain kind of name. Say a quest to hunt rats in the cellar was called Cellar Rats.
Then you might give everything related to the quest a tag starting with cr. So the quest giver might be tagged crQuestGiver, a waypoint crStartWaypoint, the quest ender crQuestEnder and so on. You might also add a convention for the areas by adding the area # as the third and fourth characters. So crQuestGiver might be cr09QuestGiver to indicate that the npc is in area 9. That way you can tell by the name of things what they are used for.

People often use naming conventions for the types of variables and objects but that isn't as useful NWScript since they don't mix much.

Modifié par Mudeye, 06 octobre 2010 - 05:28 .

[HipMaestro]

Mudeye wrote...

 I know it's too late to do this but a way that a lot of people use to keep track of stuff like that is to use a "naming convention". An example might be that everything associated with a particular quest gets a certain kind of name. Say a quest to hunt rats in the cellar was called Cellar Rats.
Then you might give everything related to the quest a tag starting with cr. So the quest giver might be tagged crQuestGiver, a waypoint crStartWaypoint, the quest ender crQuestEnder and so on. You might also add a convention for the areas by adding the area # as the third and fourth characters. So crQuestGiver might be cr09QuestGiver to indicate that the npc is in area 9. That way you can tell by the name of things what they are used for.

People often use naming conventions for the types of variables and objects but that isn't as useful NWScript since they don't mix much.

No it's not too late.  Actually, we do use a naming convention similar to what you've described but even so, it doesn't address the problem.  The names do collate in a more structured manner though using a convention.

As scripts are devised and applied, occasionally they are superseded by another one that may provide a slightly different function and destined to be implemented in  the final version.  Its point of use would therefore demand that it be named almost the same if not identical to the one being replaced.  At the time of switch, the "older" one could just be deleted, but may contain some functionality for other applications.  In other cases, some preliminary scripts/convos really aren't needed and just take up more space in the module resources. Depending on the stage of development it may or may not be apparent if any one of the "peripheral" scripts have value. We would like to separate all these superfluous versions and export into an ERF for historical reference purposes but the current procedure of checking demands walking step-by-step, through every possible link source, checking against the master list and then once the list has been compiled, either deleting it completely (as obsolete) or wrapping into an ERF (for export).  It is this step-by-step identification procedure that takes the time rather than the deleting and/or exporting.

The list of resources can become vast quickly so any efforts to reduce the clutter makes debugging and revisions so much more efficient and reduces the size of the module.