Constructing a Module outside of toolset programatically?

[Baaleos]

               

Does anyone know the process one would follow if they wanted to for instance:

Take the contents of the temp.0 folder, which contains the content of a module, and then turn that content into a module.

 

 

I am interested in setting up a continuous integration system, where content can be checked into SVN, and then Jenkins builds the module into the mod file.

Not too fussed about script compiling, as I would likely check those into SVN / Version control in their compiled versions anyway.

 

I have access to the OEIShared.dll from nwn/nwn2.

Which allows the creation and modification of ERF/GFF Structures.

 

Does anyone know what process I should follow when trying to create a MOD file from scratch?

               
               

               
            

[Legacy_Lightfoot8]

               The module file is nothing more then a ERF. You could take the temp0 folder and dump it into a hak. the only thing you would need to change from there to make the hak into a module would be the first 8 bytes of the file to MOD v1.0 I think is the current version. I can double check that latter if you need me to.
               
               

               
            

[Legacy_henesua]

               

Baaleos, are you looking to manage all of the resources independently? Stick them in a CVS or something?

 

I ask because I've had similar thoughts and would be interested in hearing what you plan to do.

               
               

               
            

[Legacy_Proleric]

               I sometimes open an empty module in the toolset, move content into temp0, tweak something trivial, then save.


Or does it need to be strictly programable?


Very interested in this discussion.
               
               

               
            

[Legacy_meaglyn]

               

I do this all the time.   The key is to convert the module to a revision control system friendly format.

 

Here's a summary of how I do that. I use linux for all of this.

 

- erf  program (one which builds and runs on Linux... I don't have the link handy).

- Elven's nwn ruby tools - converting gff files to text based yml and back.

- External compiler nwnnsscomp - I use the latest version I could find from the old nwn-tools package, with a few fixes to make it look for the 1.69 include files.

- A checked in read-only tree of all the base scripts for the expansions  - this is so that I don't have to have all the bif files around.

- A few shell scripts to pull it all together.

- Git  (some other source control would be fine, but git is the best I've found. CVS can't handle symlinks which is important to my process).

 

 

I don't keep the built module around so I haven't bothered with a depdency checking build process. Each time you build a module it does

everything. So for each module I make a little wrapper script for pulling and pushing the module. E.g. push_appear.sh, pull_appear.sh

 

I use git which handles symlinks nicely so I have all the non-module specific things linked into a common place (items, scripts, placeables etc).  This way I can build an work on a subsystem module (like body tailor for example) and when I pull the changes back in any scripts or common gff things that were changed get changed in the common place automatically and all other modules which use those files get the changes.  I find this very convenient.

 

To build the appearance module you do push_appear.sh  which:

 

-rsyncs ths files to a tmp directory (this turns the links into real files)

-compiles all the scripts

-converts all the yml files back to gff files

-erf  the tmp directory into the appropriate .mod file into the staging directory (name of mod is specified in the wrapper script, staging dir is global but configurable).

 

You can now play the mod directly, or pull it into the toolset and do things you can only do there etc.

 

When done put the mod file back in to the staging area (if not nwn/modules/ already).  Then do pull_appear.sh which

-creates a tmp dir and un-erfs the module files into it.

- removes ncs files

- converts all gff files to yml format (with a filter wich reduces the precision of position floats to 4 decimal places so that the don't change every time).

- copies all these files in to the specified module's source control directory (things that are links get followed so the changes go into the master copy.

 

Now you can use your source control to view the changes and commit them etc.

 

I keep all my hak files in there to. A slightly different process since there are no scripts and you don't tend to build them as often. But in general it's the same idea.

 

You can then use text processing tools to make changes to things as needed. Renumber parts, fix pallete things etc.  I don't do much with

dlg files in yml format because they are really hard to hand edit beyond simple type fixes or script name changes. You can run speakeasy wine pretty well.  I use zldg for all of my generic or system (i.e. tailor, moneychanging, etc) dialogs anyway so that's all just scripting.

 

I do everything I can in linux. All my scripting except small changes during debugging etc. The text editor in the toolset is unusable for any real programming.   Anyway, a lot of words to say that, yes, it's certainly possible '>

               
               

               
            

[Baaleos]

               

Yeah, I was planning on using something like GIT, or SVN, and perhaps a web front end to allow people to collaborate on my PW more efficiently.

I hate the idea of sharing my module file, in case it goes walkies, and ends up hosted somewhere else.

 

Im naturally protective of it, having developed it over the last 6-7 years.

 

But I think a dispersed approach might be safer.

Eg: Grant access to specific resources of the module, and allow people to contribute, and the module is then built by a service on a server from the head revision of all the resources.

 

This way, its harder to steal the entire module.

 

Plus - collaboration can work alot easier as you dont need one person to merge everything into the module from external erfs etc.

               
               

               
            

[Legacy_FunkySwerve]

               

We use SVN to do this. We don't sync areas, but we do sync most everything else: uti, utc, nss (source only, not compiled), utp, utt, utw, etc. With the mod open in the toolset, we compare the contents of temp0 to a repo folder, which is then synced to the main repo. Then just recompile scripts if you had any edits to them, and save the mod after. Uses NWNIAB dev environment.

 

Funky

               
               

               
            

[Legacy_Rolo Kipp]

               

<doing the old...>

 

For an old working example, you might check out Paul Speed's ModPacker written in Java.

I'm hoping to use this as a base for a whole-vault resource cataloger and dependency generator... someday :-P

 

Paul's moved on to jME and something of a hero of mine :-)

He's doing fascinating things with procedural terrain... 

Just sayin'...

 

<...double-take>