PkgInstaller
Posted: Sun Mar 12, 2006 12:57 pm
Current Version: 0.02 as at 12th March, 2006
You can find the latest release of it here https://sourceforge.net/project/showfil ... _id=113893
I'm in the process of developing a tool that should, hopefully, ease a few burdens with regarding installation and sharing of new JS scripts and package (I'm looking at you here Stranf).
At the moment, the situation seems a little fraught with trouble. You have to post a JS file, some DFNs, give instructions, and so on. Frankly, there has to be an easier way, and I think I've come up with a possible solution (or at least, am coming up with).
Initially, I'm prototyping this with C#, but nothing in there is too hard that couldn't be backported to a C++ utility (just faster for prototyping). What I'm looking at is an application which takes the concept of a 'package', and does the install for you.
This package would, in essence, just be a zip file with a couple of special files. A package would contain
The setup.info is where the developer's work will be. This will contain information about what files there are, how they're configured, and so on. A setup.info file would look something like:
Obviously, throw in real values, not just placeholder stuff. But as you can see, we explicitly list the JS files (it would be quite possible, for instance, to just figure out the list from the archive, but this does serve a purpose!)
By listing the files explicitly in this file, we essentially give them a uniqueness. And the idea is to have (somewhat) a custom value support in the DFNs. Basically, to avoid hardcoding script IDs. So you could put something like
SCRIPT=[[1]]
In your DFN file, and the tool would associate that with the JS file you listed at 1= in [JS_FILES]. The tool finds a free slot, and updates the assorted files to point to the right number, when it installs it.
Ultimately, this is not a Windows only tool. C# is just an initial prototyping tool, and nothing in this can't be backported fairly readily.
Thoughts, ideas, suggestions, are all welcome. I hope to have something working by the end of the week. I think it'll be useful to some of you, at least. Let me know your thoughts.
You can find the latest release of it here https://sourceforge.net/project/showfil ... _id=113893
Code: Select all
[color=yellow]V0.02[/color]
Updated to use a later version of the ToolAPI
Copes with relative path names in the uox.ini file for DFNs and JS files
Refactoring of code so that hopefully it becomes easier to do multiple package installs in a single run
Progress bar indicates how the install is going
Tells you when the package has been installed
At the moment, the situation seems a little fraught with trouble. You have to post a JS file, some DFNs, give instructions, and so on. Frankly, there has to be an easier way, and I think I've come up with a possible solution (or at least, am coming up with).
Initially, I'm prototyping this with C#, but nothing in there is too hard that couldn't be backported to a C++ utility (just faster for prototyping). What I'm looking at is an application which takes the concept of a 'package', and does the install for you.
This package would, in essence, just be a zip file with a couple of special files. A package would contain
- readme.txt
setup.info
*.dfn
*.js
The setup.info is where the developer's work will be. This will contain information about what files there are, how they're configured, and so on. A setup.info file would look something like:
Code: Select all
[DESCRIPTION]
{
NAME=Package Name
AUTHOR=Package Author
REVISION=Package Revision
tag/data pairings to detail description
}
[CONFIGURE]
{
COMMAND=a,b,c,d
MAGIC=a,b,c,d
CONSOLE=a,b,c,d
PACKET=a,b,c,d
SKILLUSE=a,b,c,d
GENERIC=a,b,c,d
}
[dfn_category] // eg, item, npc, maps, etc, etc
{
FILE=filename
}
[JS_FILES]
{
1=file1
2=file2
3=file3
}
[JS_ENVOKE]
{
ID=1
ID=3
ID=3
ID=3
}
[JS_TYPE]
{
Type=1
Type=2
Type=2
Type=3
}
By listing the files explicitly in this file, we essentially give them a uniqueness. And the idea is to have (somewhat) a custom value support in the DFNs. Basically, to avoid hardcoding script IDs. So you could put something like
SCRIPT=[[1]]
In your DFN file, and the tool would associate that with the JS file you listed at 1= in [JS_FILES]. The tool finds a free slot, and updates the assorted files to point to the right number, when it installs it.
Ultimately, this is not a Windows only tool. C# is just an initial prototyping tool, and nothing in this can't be backported fairly readily.
Thoughts, ideas, suggestions, are all welcome. I hope to have something working by the end of the week. I think it'll be useful to some of you, at least. Let me know your thoughts.