Hi all...
I was just wondering if any of the more experienced mod builders
might post a sort of 'Best practices builder's check list' of the steps
that they take from starting a mod to a finished mod that is ready to
be downloaded and played... obviously this would be the basic list
of important steps and not every single aspect of mod building...
After looking more at the toolset I can see that there are a lot of steps
to be taken to get a mod into the game and thought it would be a great
help to those who are just starting out to get an idea of the important
steps to take and what might be the best order in which to do them...
I'm only getting started now so I have a lot to learn.... lol
Any thoughts you have would be much appreciated!!
M
builder's check list..
Débuté par
Marcy3655
, sept. 01 2010 11:26
Retour en haut
#2
Posté 02 septembre 2010 - 04:17
DarthParametric
-
- Members
- 1 414 messages
There's no one checklist because things will vary depending on what sort of mod you are making. Something heavy on scripting is obviously going to be very different than something like a weapon mod. The only universal maxim is always test the end result in the game to see that it works (something I've been guilty myself of not doing).
Modifié par DarthParametric, 02 septembre 2010 - 04:18 .
#3
Posté 02 septembre 2010 - 04:00
ladydesire
-
- Members
- 1 928 messages
I have a list of things of things I avoid doing that I'd like to see more modders following:
I don't place content in the game installation folder; this practice, along with the next one I'm going to list, causes major headaches for developers of stand-alone mods, since doing either one will affect every module installed, whether the module should be or not.
I don't put content in the user's packages/core/override folder or modules/single player folder; the former should only hold content that has to be in that location for the toolset to find it, or the game itself needs it there (I know of only a few mods like this).
I don't make major changes to core mechanics, or add new spells or talents, by directly editing the existing spell or talent scripts; I always duplicate existing scripts and set their properties so that they only function when activated in game. I also provide edited versions of the required core gda files to be sure that things work properly.
Some things I do to support existing mods:
I will be providing a builder to builder file for any mod author that wants to make my class available in their stand alone mod.
I keep separate mods for each Bioware campaign: I currently have mods that support Origins, Awakening and Golems of Amgarrak, and will be releasing one for Witch Hunt after it is released.
I don't place content in the game installation folder; this practice, along with the next one I'm going to list, causes major headaches for developers of stand-alone mods, since doing either one will affect every module installed, whether the module should be or not.
I don't put content in the user's packages/core/override folder or modules/single player folder; the former should only hold content that has to be in that location for the toolset to find it, or the game itself needs it there (I know of only a few mods like this).
I don't make major changes to core mechanics, or add new spells or talents, by directly editing the existing spell or talent scripts; I always duplicate existing scripts and set their properties so that they only function when activated in game. I also provide edited versions of the required core gda files to be sure that things work properly.
Some things I do to support existing mods:
I will be providing a builder to builder file for any mod author that wants to make my class available in their stand alone mod.
I keep separate mods for each Bioware campaign: I currently have mods that support Origins, Awakening and Golems of Amgarrak, and will be releasing one for Witch Hunt after it is released.
