I release to you... The Modstrosity!
So I made a VERY rough modloader because I was having trouble keeping my mods straight. In many ways this is worse than just copying the files by hand, but it's only a prototype and I had to teach myself how to create batch files. Basically I'm asking for you to tell me how godawful I am at making modloaders so I can make something worthwhile.
I want to say thanks to Vorus and Martok42, I built the main Modstrosity.bat on top of your Into the Breach modloader skeleton.
I'd also like to thank Jörg Gerlach for the Defiant model, and Thorreign for the SR2. I downloaded an LCARS UI mod from somebody a while ago, but I can't seem to find that post. Hmmm... Anyway basically these are all just mods I had installed that I used for testing. You get 'em because you want to test too (you do, right?). No theft intended. :D
I ported the Normandy and Defiant to the game (poorly) and changed a few of the sounds/graphics.
So here it is! Grab it and tell me what you think!
VERY IMPORTANT
This modloader needs a full vanilla install of Artemis in the \Artemis\MODS\VanillaArtemis folder to work. Also, you'll need to put these files into the Artemis folder of an install. Please note that this will NOT play nice with existing mods and will clean them out.
I want to say thanks to Vorus and Martok42, I built the main Modstrosity.bat on top of your Into the Breach modloader skeleton.
I'd also like to thank Jörg Gerlach for the Defiant model, and Thorreign for the SR2. I downloaded an LCARS UI mod from somebody a while ago, but I can't seem to find that post. Hmmm... Anyway basically these are all just mods I had installed that I used for testing. You get 'em because you want to test too (you do, right?). No theft intended. :D
I ported the Normandy and Defiant to the game (poorly) and changed a few of the sounds/graphics.
So here it is! Grab it and tell me what you think!
VERY IMPORTANT
This modloader needs a full vanilla install of Artemis in the \Artemis\MODS\VanillaArtemis folder to work. Also, you'll need to put these files into the Artemis folder of an install. Please note that this will NOT play nice with existing mods and will clean them out.
[Last edited Mar 13, 2012 05:29:17]
page
1
11 replies
Good work, Evan! I'm looking forward to taking a closer examination of this tomorrow. I certainly think the community needs to establish some sort of mod package standard and this is certainly a great start. I've been working a few ideas on the subject, too, and I'd love to collaborate with you and the rest of the community on the best way to get our stuff out to everyone!
Well, if suggestions are welcome, i think the best approach for modding the game is the path Bethsheda or games like Independance War II taken.
Basically:
- Game has the main set of assets its using. They are stored preferably in an archive or special folder for vanilla-game-only assets
- Mods come in forms of zip archives that have a structure similar to the vanilla data folder.
- Those mods are enabled/disabled from a simple software or an INI file even.
- Files included in enabled mods take precedence over the vanilla files when game is loading
So, if you need to mod game's sound effects, you create a folder like Data, Sounds in it, and place sound files as they're named in original game there, and when your mod (zipped folder) is loaded, those files are used instead of main game's.
If you need to change weapon settings, you make a file that holds the weapon list of your own - probably this file is a modified original. Etc.
This means that making a mod is as simple as copying the files you wanna mod to a separate folder, maintaining structure, working on them, and then zipping this folder and thats a mod.
Loading a mod is also as simple as unzipping all mods to temp. directories, and giving the game a list of directories where to look for the files it tries to load at startup - with temp mod directories taking precedence over the game's vanilla directory.
Now, to allow more mods to run without conflicts, you'd generally like to have more smaller xml/ini files rather than one large vesseldata that is there now. So for example, one player modded torpedo range, other modded enemy ship shields - if those be separate files, the mods could be compatible, but in current situation, they arent, since both occupy the same file.
PS: A more complex solution would be to treat mod xml files as overwrites of the original - so if the same torpedo is described in the mod's vesseldata.xml, it replaces the vanilla statistics of this torpedo taken from vanilla vesseldata.xml. This way, modders would only have to add the entries they changed to their mod files, so both mods could be compatible.
Basically:
- Game has the main set of assets its using. They are stored preferably in an archive or special folder for vanilla-game-only assets
- Mods come in forms of zip archives that have a structure similar to the vanilla data folder.
- Those mods are enabled/disabled from a simple software or an INI file even.
- Files included in enabled mods take precedence over the vanilla files when game is loading
So, if you need to mod game's sound effects, you create a folder like Data, Sounds in it, and place sound files as they're named in original game there, and when your mod (zipped folder) is loaded, those files are used instead of main game's.
If you need to change weapon settings, you make a file that holds the weapon list of your own - probably this file is a modified original. Etc.
This means that making a mod is as simple as copying the files you wanna mod to a separate folder, maintaining structure, working on them, and then zipping this folder and thats a mod.
Loading a mod is also as simple as unzipping all mods to temp. directories, and giving the game a list of directories where to look for the files it tries to load at startup - with temp mod directories taking precedence over the game's vanilla directory.
Now, to allow more mods to run without conflicts, you'd generally like to have more smaller xml/ini files rather than one large vesseldata that is there now. So for example, one player modded torpedo range, other modded enemy ship shields - if those be separate files, the mods could be compatible, but in current situation, they arent, since both occupy the same file.
PS: A more complex solution would be to treat mod xml files as overwrites of the original - so if the same torpedo is described in the mod's vesseldata.xml, it replaces the vanilla statistics of this torpedo taken from vanilla vesseldata.xml. This way, modders would only have to add the entries they changed to their mod files, so both mods could be compatible.
[Last edited Mar 13, 2012 10:11:05]
Ok Hissatsu, your idea sounds WAY better than mine. The only problem is that copying files and folders is something I've done since childhood and is natural to me, while enabling and disabling packages sounds like something that Artemis would have to do itself. Without making you do too much work, could you steer me in the right direction on how to go about implementing this?
Oh and TreChipman, if you want to collab on something you can reach me at ehawman@gmail.com. I'm not very skilled, but I'm eager to learn and contribute.
Oh and TreChipman, if you want to collab on something you can reach me at ehawman@gmail.com. I'm not very skilled, but I'm eager to learn and contribute.
Yes, my idea requires at least some cooperation from game author, but i think if we suggest him a simple idea how to make a modloader, he would implement it. After all, i hope he understands how important an easy to use modloader is for Artemis.
I think we could just ask the author to make Artemis read some "mod.ini" file, where installed mods (filenames) are listed with 1 or 0 - enabed or not, and a default for unlisted mods - enable or disable, and we could write a program that lets player select the mods and writes to this file, or let players do that manually at first.
Then aside from reading the list of mods to load (or not to load if default is to load), a list of used mods is constructed. Then, its just a matter to check in different locations instead of loading from a preset location - hopefully changing just one function "OpenFile()" in the code.
Possibly also adding "unpack mods" to the initiation code and "remove all temp files" to the termination code.
I think we could just ask the author to make Artemis read some "mod.ini" file, where installed mods (filenames) are listed with 1 or 0 - enabed or not, and a default for unlisted mods - enable or disable, and we could write a program that lets player select the mods and writes to this file, or let players do that manually at first.
Then aside from reading the list of mods to load (or not to load if default is to load), a list of used mods is constructed. Then, its just a matter to check in different locations instead of loading from a preset location - hopefully changing just one function "OpenFile()" in the code.
Possibly also adding "unpack mods" to the initiation code and "remove all temp files" to the termination code.
[Last edited Mar 13, 2012 10:38:25]
Here is a neat little tool i found that might help out still learning about the different functions that is offers but it is free so I put it out there if you want to try it out. Might help out with the moding and patches.
http://nsis.sourceforge.net/Download
P.S. Great work Evan!!!!!!
http://nsis.sourceforge.net/Download
P.S. Great work Evan!!!!!!
[Last edited Mar 13, 2012 19:43:04]
Whoa! This program looks powerful but involved. This would definitely take some work to figure out. I'll have to delve into this thing for a few days.
Has anybody ever played Cortex Command? The mod-loading system for that game is beyond easy. The mods are all in folders and you activate and deactivate them by appending ".rte" to the end. So if I had the folder "EvansAwesomeMod" (with the mod stuff inside), to activate that mod in-game I would rename it to "EvansAwesomeMod.rte". It still acts exactly like a folder, but the game loads all of the files inside and stuff. There's actually a cool utility that will search for all folders in the main installation folder and list them with a check box next to each. If the folder has .rte appended to it, the check box is marked. To activate or deactivate mods, simply toggle the check and the program will rename the folders. I'd love for modding to work like this, but that would be up to Thom to implement.
Of course, this is just addressing the selection of mods. We need to be able to tack on our own vesselData settings for each ship (I made a hideous work-around in mine) and the camera angle and distance need to be set for each ship, not by artemis.ini. I want the ability to view the Defiant up close, but zoom farther away from a Galaxy or the Normandy. If the game could scale the engine particles somehow that would be nice too.
If you're reading this, Thom, keep up the good work! A modloader would be VERY nice, but it's just one of the dozens of awesome ideas I've seen posted on these forums. Prioritize as you see fit!
Has anybody ever played Cortex Command? The mod-loading system for that game is beyond easy. The mods are all in folders and you activate and deactivate them by appending ".rte" to the end. So if I had the folder "EvansAwesomeMod" (with the mod stuff inside), to activate that mod in-game I would rename it to "EvansAwesomeMod.rte". It still acts exactly like a folder, but the game loads all of the files inside and stuff. There's actually a cool utility that will search for all folders in the main installation folder and list them with a check box next to each. If the folder has .rte appended to it, the check box is marked. To activate or deactivate mods, simply toggle the check and the program will rename the folders. I'd love for modding to work like this, but that would be up to Thom to implement.
Of course, this is just addressing the selection of mods. We need to be able to tack on our own vesselData settings for each ship (I made a hideous work-around in mine) and the camera angle and distance need to be set for each ship, not by artemis.ini. I want the ability to view the Defiant up close, but zoom farther away from a Galaxy or the Normandy. If the game could scale the engine particles somehow that would be nice too.
If you're reading this, Thom, keep up the good work! A modloader would be VERY nice, but it's just one of the dozens of awesome ideas I've seen posted on these forums. Prioritize as you see fit!
[Last edited Mar 14, 2012 04:56:37]
I looked at NSIS, and while it's VERY impressive, I think it might be a bit overpowered for the scope of a simple modloader-- a Type 4 nuclear flyswatter, if you will. Here's what I'm proposing:
ST_TMP_161 (Full)
Download it, unzip it to your dat directory, and run the Play Artemis.bat file (based off of Vorus and Martok42's very instructive original Play Artemis.bat file) in dat/Mods/ST_TMP. The file does four things: install and play the mod, uninstall the mod, backup your Artemis resources (just the artemis.ini file, vesselData.xml, and the texture, models, and sound files though; I think anything else is probably venturing into the area of non-serviceable parts) and a way to restore your original Artemis resources should something get really messed up.
I'd recommend doing the backup option, then install the mod; from there you should be able to run the game from the regular Artemis.exe, and just run it again if you need or want to uninstall it and play the 'stock' version.
It doesn't directly mirror the current file structure (if it did, I could probably get away with using a simple directory copy) but the way it's built should make it a lot more intuitive and easier for modders to keep track of their resources. That being said, I'm not married to the file structure yet; the aforementioned directory copy would pretty much future-proof the backup/restore process if Thom adds new/different things down the road. However, it does make things a little more streamlined and less cluttered than the way they are in the current dat directory.
Note that for the TMP mod to work as it's written now, it'll require the 'generic' mod listed here. If you downloaded from the link above, you already have the necessary files and you'll be good to go, but the installation has been broken into two different files, too-- the mod itself, and the generic mod which holds a lot of... well, generic stuff that the mod (and other future mods) might need. You can grab them separately (or update your current installation as necessary) through the following links:
Generic Mod
ST_TMP (Basic)
I'm thinking the Generic Mod would contain non IP stuff that mission scripters would find useful but are not currently in the game -- space phenomena, generic objects, utility ships/stations, etc. Currently, the generic mod holds a planet mesh, a shuttle mesh, and a ton of textures, but it should be pretty easy for future modders to add more to it as time goes on provided their additions occupy a unique namespace. The Generic Mod wouldn't necessarily have an installer; it's just a repository for things that might be required by other mods that can be accessed via the vesselData.xml or artemis.ini files. This way, users wouldn't have to download a mesh for a planet for every mod-- the mod users can just require planet.dxs from Generic and call it a day. Ideally, this will significantly cut down on download sizes by providing an economy of scale as more mods are created.
ST_TMP_161 (Full)
Download it, unzip it to your dat directory, and run the Play Artemis.bat file (based off of Vorus and Martok42's very instructive original Play Artemis.bat file) in dat/Mods/ST_TMP. The file does four things: install and play the mod, uninstall the mod, backup your Artemis resources (just the artemis.ini file, vesselData.xml, and the texture, models, and sound files though; I think anything else is probably venturing into the area of non-serviceable parts) and a way to restore your original Artemis resources should something get really messed up.
I'd recommend doing the backup option, then install the mod; from there you should be able to run the game from the regular Artemis.exe, and just run it again if you need or want to uninstall it and play the 'stock' version.
It doesn't directly mirror the current file structure (if it did, I could probably get away with using a simple directory copy) but the way it's built should make it a lot more intuitive and easier for modders to keep track of their resources. That being said, I'm not married to the file structure yet; the aforementioned directory copy would pretty much future-proof the backup/restore process if Thom adds new/different things down the road. However, it does make things a little more streamlined and less cluttered than the way they are in the current dat directory.
Note that for the TMP mod to work as it's written now, it'll require the 'generic' mod listed here. If you downloaded from the link above, you already have the necessary files and you'll be good to go, but the installation has been broken into two different files, too-- the mod itself, and the generic mod which holds a lot of... well, generic stuff that the mod (and other future mods) might need. You can grab them separately (or update your current installation as necessary) through the following links:
Generic Mod
ST_TMP (Basic)
I'm thinking the Generic Mod would contain non IP stuff that mission scripters would find useful but are not currently in the game -- space phenomena, generic objects, utility ships/stations, etc. Currently, the generic mod holds a planet mesh, a shuttle mesh, and a ton of textures, but it should be pretty easy for future modders to add more to it as time goes on provided their additions occupy a unique namespace. The Generic Mod wouldn't necessarily have an installer; it's just a repository for things that might be required by other mods that can be accessed via the vesselData.xml or artemis.ini files. This way, users wouldn't have to download a mesh for a planet for every mod-- the mod users can just require planet.dxs from Generic and call it a day. Ideally, this will significantly cut down on download sizes by providing an economy of scale as more mods are created.
[Last edited Mar 14, 2012 07:23:27]
What does "cd .." do? Also "f |"
I like how clean your modloader is. Personally I'd go with matching/copying the directory structure, but I can see your reasoning for the contrary.
And as I understand it this mod loader is designed for only one mod at a time. I'm looking for something that will allow easy loading for any number of mods. The "Cortex Command" solution would be simple and elegant, but requires Thom to implement it. My Modstrosity sorta addresses the vesselData.xml issue and the overwrite issue (implement them in order, kids!) but this is such an ugly workaround.
Something I haven't quite been able to fix in my mind is how to deal with mod overlapping in a perfect way. Cortex Command mods only add content, they don't change the UI or whatever. We need a way to separate adding content from overwriting UI stuff. Perhaps a three part process?
1) Adding Content: This pretty much applies to new ships and new missions. Check this box to load "Tre's TMP Mod and Assorted Mission Pack". Check that other box to load "Evan's Normandy SR2". Each ship comes with its own vessel data that is loaded and implemented separate of vesselData.xml (EG: "defiantData.xml" "normandyData.xml"). Each ship has its own camera settings separate of artemis.ini ("defiantCam.ini", "normandyCam.ini"). Also, each ship could also have its own UI/sounds ("defiantUI.ini" points to which files should be used instead of the defaults). I want pulse beams on my Defiant, not phasers! If it doesn't change a file then the default is used.
2) UI/Sound Universal Override: If you wish, you can override the ship's individual UI/Sound data with these packs. "Evan's LCARS Tweak Pack" or "Dwayne's CIC Mod" would be in a separate mod category and would override any settings in part 1 that changed the way the UI looks/sounds. There should always be a "None" and "Default/Vanilla" option for part 2.
3) Selecting Game Settings: Basically this lets the user choose the game settings for artem- ...you know what? Get rid of part 3 and change the way this is. Let the server have the ability to change these settings when it starts the gorram thing. Each mod could have a "preset" settings file that the user would be able to select (EG: "Recommended Tre's TMP Mod Settings") or a "Custom" option in which the user would simply input the settings manually. By "settings" I am referring to all of the "Server Side Settings" in artemis.ini. That should definitely be handled by the GUI.
So here's my proposed mod structure:
EvansStarTrekMixMod
Defiant
defiantData.xml
defiantUI.ini
defiant.snt
defiant.dxs
defiant_diffuse.png
pulseBeams.wav
Galaxy
galaxyData.xml
galaxyUI.ini
galaxy.snt
galaxy.dxs
galaxy_diffuse.png
LCARS
DefiantTweaks
defiant_logo512.png
ds9intro.ogg
GalaxyTweaks
galaxy_logo512.png
TNGintro.ogg
thereareabunchofotherfilesinheretrustme.png
phaserSound.wav
modSettings.ini
EDIT: Oops. I guess it doesn't accept spaces as tabs. Hmmm... Well I'll just color the layers. Bold means that it is a folder.
I like how clean your modloader is. Personally I'd go with matching/copying the directory structure, but I can see your reasoning for the contrary.
And as I understand it this mod loader is designed for only one mod at a time. I'm looking for something that will allow easy loading for any number of mods. The "Cortex Command" solution would be simple and elegant, but requires Thom to implement it. My Modstrosity sorta addresses the vesselData.xml issue and the overwrite issue (implement them in order, kids!) but this is such an ugly workaround.
Something I haven't quite been able to fix in my mind is how to deal with mod overlapping in a perfect way. Cortex Command mods only add content, they don't change the UI or whatever. We need a way to separate adding content from overwriting UI stuff. Perhaps a three part process?
1) Adding Content: This pretty much applies to new ships and new missions. Check this box to load "Tre's TMP Mod and Assorted Mission Pack". Check that other box to load "Evan's Normandy SR2". Each ship comes with its own vessel data that is loaded and implemented separate of vesselData.xml (EG: "defiantData.xml" "normandyData.xml"). Each ship has its own camera settings separate of artemis.ini ("defiantCam.ini", "normandyCam.ini"). Also, each ship could also have its own UI/sounds ("defiantUI.ini" points to which files should be used instead of the defaults). I want pulse beams on my Defiant, not phasers! If it doesn't change a file then the default is used.
2) UI/Sound Universal Override: If you wish, you can override the ship's individual UI/Sound data with these packs. "Evan's LCARS Tweak Pack" or "Dwayne's CIC Mod" would be in a separate mod category and would override any settings in part 1 that changed the way the UI looks/sounds. There should always be a "None" and "Default/Vanilla" option for part 2.
3) Selecting Game Settings: Basically this lets the user choose the game settings for artem- ...you know what? Get rid of part 3 and change the way this is. Let the server have the ability to change these settings when it starts the gorram thing. Each mod could have a "preset" settings file that the user would be able to select (EG: "Recommended Tre's TMP Mod Settings") or a "Custom" option in which the user would simply input the settings manually. By "settings" I am referring to all of the "Server Side Settings" in artemis.ini. That should definitely be handled by the GUI.
So here's my proposed mod structure:
EvansStarTrekMixMod
Defiant
defiantData.xml
defiantUI.ini
defiant.snt
defiant.dxs
defiant_diffuse.png
pulseBeams.wav
Galaxy
galaxyData.xml
galaxyUI.ini
galaxy.snt
galaxy.dxs
galaxy_diffuse.png
LCARS
DefiantTweaks
defiant_logo512.png
ds9intro.ogg
GalaxyTweaks
galaxy_logo512.png
TNGintro.ogg
thereareabunchofotherfilesinheretrustme.png
phaserSound.wav
modSettings.ini
EDIT: Oops. I guess it doesn't accept spaces as tabs. Hmmm... Well I'll just color the layers. Bold means that it is a folder.
[Last edited Mar 14, 2012 20:42:38]
Thanks for the feedback, Evan!
"cd .." changes your active directory, so if you're in c:/directory/subdirectory, cd .. effectively moves things to c:/directory. I put it in there so that the mod could run from it's own folder, but still modify things above it in the directory structure.
"f |" is a flag that *I think* denotes that the object being copied is a file and not a directory, and absolves the user of having to answer a prompt with every file being processed. I'm still pretty new to the world of batch files, but I think that's what it does. It's either that or it mails me all of your credit card information. Either way, it's probably best if you just leave it in.
The thing about my mod format is that it really only copies 2 files at a time-- artemis.ini and vesselData.xml; as long as you back up those files, you should be able to use it without any concerns of getting back to your original install. In an ideal world, the location of every model, texture, and/or sound would (or at least, could) be referenced/defined by these files (also, ideally, failure to reference one of these resources would default back to original install, so if you don't reference the path to the frankly baffling brick.png texture, you'd get the stock one automatically). The option of copying the files from/to the stock directory is just a (probably needless) precaution on my part.
Anyway, once we've got the mod(s) in the right place and have an understanding of what's in them, they become Resource Libraries that modders can pull from at leisure-- This way, Modders can pick and choose from the elements they want to use-- for example, if you wanted to play a game where your ME Normandy was to take on a bunch of Klingons, provided you already had both mods downloaded, you'd just need to download a mod like "normandyVsKlingons.zip" that copies the vesselData.xml and artemis.ini files and run the install for that mod-- provided the directory structure is the same, it shouldn't adversely impact your stock install at all. If I wanted my bridge to fight you, I'd just install "klingonsVsNormandy.zip" and in both of our bridge instances, we should see what we're expecting to see. I'm not sure how the engine would handle conflicting info, like differing beam damage from cruisers, but that's why Thom makes the big money.
"cd .." changes your active directory, so if you're in c:/directory/subdirectory, cd .. effectively moves things to c:/directory. I put it in there so that the mod could run from it's own folder, but still modify things above it in the directory structure.
"f |" is a flag that *I think* denotes that the object being copied is a file and not a directory, and absolves the user of having to answer a prompt with every file being processed. I'm still pretty new to the world of batch files, but I think that's what it does. It's either that or it mails me all of your credit card information. Either way, it's probably best if you just leave it in.
The thing about my mod format is that it really only copies 2 files at a time-- artemis.ini and vesselData.xml; as long as you back up those files, you should be able to use it without any concerns of getting back to your original install. In an ideal world, the location of every model, texture, and/or sound would (or at least, could) be referenced/defined by these files (also, ideally, failure to reference one of these resources would default back to original install, so if you don't reference the path to the frankly baffling brick.png texture, you'd get the stock one automatically). The option of copying the files from/to the stock directory is just a (probably needless) precaution on my part.
Anyway, once we've got the mod(s) in the right place and have an understanding of what's in them, they become Resource Libraries that modders can pull from at leisure-- This way, Modders can pick and choose from the elements they want to use-- for example, if you wanted to play a game where your ME Normandy was to take on a bunch of Klingons, provided you already had both mods downloaded, you'd just need to download a mod like "normandyVsKlingons.zip" that copies the vesselData.xml and artemis.ini files and run the install for that mod-- provided the directory structure is the same, it shouldn't adversely impact your stock install at all. If I wanted my bridge to fight you, I'd just install "klingonsVsNormandy.zip" and in both of our bridge instances, we should see what we're expecting to see. I'm not sure how the engine would handle conflicting info, like differing beam damage from cruisers, but that's why Thom makes the big money.
Thank you thank you thank you! "cd .." and "f |" will definitely help me a lot. I'll be sure to implement them in the morning after I'm finished giggling at my sister following her wisdom teeth removal. Also run-on sentences.
As for your loader idea, if I understand you correctly you propose a two part system.
1) Resource installation: Users install all of the data required for ships and UI changes.
2) Resource implementation: Using information files included in the packs, downloaded later, or created by the user, the user proceeds to load up the resources and play with them.
Does this mean we would have to create a new mod loading instance (normandyVsKlingons.zip) for each and every combination permutation? I guess I'm not seeing it.
Actually I think I do...
What you are proposing is a stopgap measure until Thom allows individual ships to dictate settings, correct?
As for your loader idea, if I understand you correctly you propose a two part system.
1) Resource installation: Users install all of the data required for ships and UI changes.
2) Resource implementation: Using information files included in the packs, downloaded later, or created by the user, the user proceeds to load up the resources and play with them.
Does this mean we would have to create a new mod loading instance (normandyVsKlingons.zip) for each and every combination permutation? I guess I'm not seeing it.
Actually I think I do...
What you are proposing is a stopgap measure until Thom allows individual ships to dictate settings, correct?
Here is a little program I found that creates a batch style file. I am currently using this in my Mods. the down side of this is It has to be installed on the users computer but it is freeware. Here is the link for it. The program is called Batch Run.
https://rapidshare.com/files/1868923203/Batch_File_Creation_Utility_19633.exe
It is pretty easy to use and allows for quick editing of the batch run files.
https://rapidshare.com/files/1868923203/Batch_File_Creation_Utility_19633.exe
It is pretty easy to use and allows for quick editing of the batch run files.
Login below to reply:
