Plugin Creator

[Fulby]

ALPine

 

ALPine is an attempt to allow plugin style mods to work with UFO: Aftermath. It allows multiple plugins to affect the same config file by loading data such as the weapon list into hierarchical data structures, manipulating the entries and saving the list back to file.

 

I've included a few sample plugins which should hopefully demonstrate. "All Human Weapons" makes human weapons, magazines and armour available in unlimited quantity from the start of the game. "Uzi Extended Clips" adds a second clip for the Uzi with double the capacity. These are provided with ALPine as examples of plugin code rather than proper plugins.

 

These plugins would be mutually exclusive if implemented as files because they both modify listofweapon.txt. Implemented as ALPine plugins they only modify the fields in the records they need and so have much less chance of interfering with each other. Plugins can still conflict (there isn't currently any method for identifying conflicting plugins) but do so less than file-level modding.

 

ALPine currently has functions for modification, addition and deletion of items (weapons, magazines and armour have been tested, other listof*.txt files may be usable) and for copying files (see PumpIcon plugin). Also, because it is based on programming/scripting language Lua, modders can write their own functions if an appropriate one is not available.

 

Installation instructions are included in the zip, though it assumes you already know how to import/export files from gamedata.vfs file and have the directory tree for VFSTool set up. Please contact me either through email (see readme.txt) or on this thread if you have problems, queries or suggestions.

 

Fulby

[Slaughter]

Very nice! Added to the mods section.

[Aralez]

Hm. The download doesn't seem to work. I'll try again later. Btw, Fulby, if i understand this correctly, can i actually add files via the copying funtion?

[Fulby]

It won't add files directly to gamdata.vfs, but you can copy files from on directory to another. For instance:

 

The "Pump-Action Shotgun Icon Replacement" (PumpIcon) plugin consists of the following files which are in the ALPine directory:

 

pumpicon.bat

pumpicon uninstall.bat

pumpicon.lua

pumpiconremove.lua

pump\h_s-pump.tga

pump\new_h_s-pump.tga

 

When you you pumpicon.bat, it copies the new icon (the last file) to "PATH\tactical\textures\interface\items\weapons\h_s-pump.tga"

where PATH is something like "c:\ufo\changed", and is set by the user to match their UFO:AM installation. You then use VFSTool to import the file into gamedata.vfs

 

It works with replacing existing files in gamedata.vfs, I haven't tried it with adding new ones but it won't do anything you couldn't do with normal copying.

 

Does that answer your question or were you asking about referencing new files in config files (like adding an original icon for a new magazine)?

 

Did you try to download the file from UFOAftermath.co.uk or from the link in my original post, or both?

 

Fulby

[Aralez]

Ah, the link in your post works, thx! And yes, i was talking about about new files, especially graphic files. I'll try adding files with this tool and will mail the result here. Thanks Fulby for your fast and complete answer (and of course the link! )

[Fulby]

Here's a better version of Extended Uzi Magazines

 

The extended magazines now have their own graphic icon.

 

Fulby

[Slaughter]

The link in the mods section should work now. I kind of forgot to upload the file...

[Fulby]

Just to keep you on your toes

 

ALPine 1.1 is available from the minimalist ALPine Website

 

Changes:

+ Removed uziammo plugin

+ Added uziex plugin

+ Removed uninstall for pumpicon plugin

+ Misc. changes to readme.txt

 

Fulby

[blian]

Hi!

 

I have an idea about a new kind of modding tool user interface; I already mailed it to Fulby. Here it is:

 

Subject: UFO:Aftermath modding - idea

 

Hi Fulby!

 

I've seen Your UFO:AM modding tool written in LUA. ***VERY NICE!***

I was thinking about something similar. I'll try to explain my concept

below. It's about an imaginary modding tool, which I'll call mT. Maybe

together we could create it (or something similar)?

 

Let's suppose that SomeGuy creates a mod with multiple features and

OtherGuy does the same. Some features conflict (maybe SomeGuy wants to set

the range of SomeGun to 24, OtherGuy wants it to be 35), some not.

The user would like to use some features from SomeGuy's mod, and some

other features from OtherGuy's mod. (I'll use mF as abbreviation of "mod

feature").

 

The mFs are stored in separate files (originally I imagined mFs as

XML files, but Your solution with the LUA modding API is way easier and

more elegant).

 

The script of the mF should contain code which can do the following:

- detect the mF and its actual parameters (this is for convenience

  only, the mT can memorize itself which mFs were installed and how)

- estimate if the mF can be applied at all (the data which it wants to

  change is present, etc.)

- install the mF

- uninstall the mF (either by restoring game default values, or by

  restoring the (saved-during-install) previous state)

 

The mT can detect the installed mFs and their actual parameters, and

install/uninstall them nearly indepedently.

 

I imagined a user interface where mFs are represented by checkboxes, and

they can have parameters (at least one numeric parameter can be handy).

The mT has a directory which is scanned at startup after the

installed/available mF files and every mF's widgets are displayed, one

below another. For example:

 

------------ mT modding Tool for UFO:Aftermath ------------

 

--SomeGuy's mod

 

[x] increase helicopter speed to [250]%

[x] add [ 20]-round magazine for ZVI Falcon

[ ] set (human) rocket speed to [ ] m/s

[ ] better Basic Alien Armor

[x] add Stun Grenades

...

 

--OtherGuy's mod

[x] helicopter speed to 5X

[ ] add PSI ammo for Glock

[ ] add a new Light Rail Pistol

[x] soldiers heal [ 30] % faster

...

 

[ Apply Changes ] [ Exit ]

 

----------------------------------------------------------

 

Problems can be:

- if two mFs set the same value: that's not really a problem, the value

will be set to X1, then to X2. Not exactly what the user wanted, though.

- if mFs create files with the same name: that's pain, should not be

allowed (must be declarated at prerequisites and/or detected by mT

automatically).

 

What do You say? Can this mT be created? Is it worth bothering with?

 

What do You think?

 

Blian

[Fulby]

I've seen Your UFO:AM modding tool written in LUA. ***VERY NICE!***

I was thinking about something similar. I'll try to explain my concept

below. It's about an imaginary modding tool, which I'll call mT. Maybe

together we could create it (or something similar)?

 

Thanks for the kind words

I'm working towards the same idea as you describe, a GUI where you select plugins and press Apply. ALPine needs some more work first to make "ALPine 2.0" with a GUI work the way I'd like. I'll try and outline my take on the idea below.

 

The mFs are stored in separate files (originally I imagined mFs as

XML files, but Your solution with the LUA modding API is way easier and

more elegant).

Yeah I looked at using XML at first, both processed in a C program or with XSLT but both ways seemed too complicated.

 

The mT can detect the installed mFs and their actual parameters, and

install/uninstall them nearly independently.

I don't think plugins/mFs should feature uninstalls, it complicates the process of making plugins. The AHW plugin is simple because it overwrites the TECH_LEVEL of human equipment with the value 1 - to make an uninstall would require either typing in the values for every item or making ALPine/mT work it out when the plugin is applied. The way I imagine the ALPine 2.0 working would make them unnecessary by starting from the original files and applying all selected patches, then saving the result in a new VFS file. Instead of having to make uninstalls, the mod tool just deletes the VFS file and starts again.

 

I imagined a user interface where mFs are represented by checkboxes, and

they can have parameters (at least one numeric parameter can be handy).

The mT has a directory which is scanned at startup after the

installed/available mF files and every mF's widgets are displayed, one

below another. For example:

I imagined exactly the same thing

 

Here's how I think the plugin process should go:

 

1. User runs a GUI program as you described, it scans the directory for plugins and lists them for the user to select.

2. After selecting the ones he wants, the user pressing Apply.

3. For each plugin, the GUI extracts the files the plugins needs from gamedata.vfs to a directory tree in a temporary location creating a directory tree. If the file already exists in the temporary directory tree (TDT for short) it doesn't replace it. If it already exists that's because another plugin have requested it earlier in the process. (The TDT is created from scratch each Apply, so the files aren't left over from earlier uses).

4. The GUI runs each plugin. They modify the files in the TDT. ALPine plugins rely on a PATH variable to tell them where the directory tree is, the GUI can set this at runtime. Plugins can also copy in new files from the plugin directory to the TDT.

5. After all the plugins have run, the GUI uses VFStool to import them to a new VFS file such as cfg.vfs in the game directory.

 

At this point the GUI is done and the player should be able to run UFO with the accumulated effect of the plugins modifying the game.

 

Disadvantages:

As you stated plugins may alter the same data resulting in a conflict, also the order in which the plugins is run may affect the outcome. I don't think there's a generic solution to this, instead if modders use such a system then they'll state which plugins are known to be incompatible. Morrowind features a plugin system and I think the same thing happens with the larger plugins.

 

Conflicts could be detected if a framework were put in place to catch them. For example every time a plugin calls setval(item, key, value) it updates a tree of modified fields. So is the mod HeavyUzi calls setval(uzi, "WEIGHT", 4), the setval function would create a node in the tree as Weapons->Uzi->Weight = {"HeavyUzi"}. If another plugin also modified that field through setval or another ALPine function the tree would read Weapons->Uzi->Weight = {"HeavyUzi", "OtherPlugin"}. The GUI could then search through the tree after running the patches and highlight conflicting plugins and where they conflict. Would only work on mods using official modifying functions and might not catch more complex conflicts like an item being added and then deleted. All in all it's not high on my priority list (just explaining it has taken up most of the post)

 

Advantages:

Multiple plugins can affect the same file

No need to write uninstallers for plugins

Player doesn't need to copy files around and make directories themselves (unlike current ALPine).

No need to extract the files from gamedata.vfs in advance. Currently ALPine only works if the listof*.txt file a plugin needs already exists in the right place, and it won't create directories when copying in files to the directory tree. You have to do this manually which isn't viable if the plugin system is to be used by non-modders (which is kind of the point ).

 

These are the problems I'm currently working on. Before starting on the GUI I'd like to create a "needs(filename)" function which plugins call before the main code and will do what's described in step 3 above. This means steps 3 and 4 are merged but it doesn't matter in practical terms. The needs() function would check if the file already existed in the directory tree. If not it extracts it from gamedata.vfs. If it can't find it the function fails and aborts the plugin. It would still be up to the modder to add needs() functions at the start of his plugins but that shouldn't be a problem.

 

I'm also modifying the copyfile(source, dest) function so that it will create any directories in the dest path that don't exist. The copyfile() function could in future also watch for two plugins trying to copy a file into the same path/name.

 

What do You say? Can this mT be created? Is it worth bothering with?

I don't think there's any technical problem which prevents a GUI mT, and it's something I'm working towards in the long run for ALPine. The answer to the last question depends on whether modders want to use a plugin system such as ALPine; it's more flexible than file-level modding but more complex to make mods with.

 

To those of you who haven't fallen asleep already, if you're a modder or potential modder (or just concerned citizen/busybody) and have had a look at ALPine I'd appreciate your comments on whether you consider it useful.

 

Fulby

[Fulby]

Next version of ALPine available, version 1.5

 

Changes:

1.5 2003-11-15

All file functions now use paths relative to the VFS root

Added needs(filename) function

Added VFSExtract tool

Updated included plugins to work with new version

Added apply command line tool for applying multiple plugins

Plugins are imported to cfg.vfs instead of gamedata.vfs

 

 

*** Installing plugins

ALPine uses a command line tool called "apply" to install plugins. It is run from the ALPine directory.

apply <UFOpath> <plugin1> <plugin2> ...

Example: apply "c:\games\ufo" uziex.lua pumpicon.lua ahw.lua

 

Up to 9 plugins can be installed at once. ALPine will process each plugin in turn, then import them to a VFS file called cfg.vfs in the UFO directory. UFO: Aftermath will use the installed plugins when you next run the game.

 

Available here.

 

Fulby

[Slaughter]

Well done, added to the mods section!

[Fulby]

Documentation on ALPine now available on the ALPine web site:

ALPine Web site

 

Also version 1.6 released.

 

Changes:

1.6 2003-11-15

Fixed bug in needs(filename) which would extract file from VFS even if it was already extracted

Added documentation covering ALPine functions (alpinedoc.htm)

Added Slow Weapons plugin

 

ALPine 1.6

 

Fulby

[Slaughter]

Added to the mods section. Good work!

[BlackAlmaz]

i'm sory but can some one tell me how to use this....i raed the raed me and itired it but nothing happens...mabye its because of one of my previous mods

[Slaughter]

Extract the tool to a subdirectory of your Aftermath directory. In my case that would be "d:\games\ufo aftermath\alpine". Then make sure that sigget's vfs tool is located in the Aftermath directory. When this is done, open cmd (command, start->run->cmd), go into the alpine directory (cd games, cd ufo aftermath, cd alpine), and type for instance:

apply "d:\games\ufo aftermath" pumpicon.lua

 

This will add the selected mod (in this case pumpicon.lua) to the game. For the stun rod to work, you have to start a new game.

[mipu]

hi fulby,

 

i think you should develop your tool in the style of the "FREELANCER MOD MANGER" which is great for loading and unloading complete mods into FREELANCER.

 

Find more at www.lancersreactor.com

 

cu mipu

[Fulby]

mipu,

 

Something like that would be cool, I don't know how far down the line it would be though, or even if it were me who made it. It's definitely needed for plugins to be user-friendly enough for most players.

 

Fulby