Artemis Mod Loader 3.0
I was impressed with the Mods that were available for Artemis Spaceship Bridge Simulator, but found the mechanism for installing and switching between them rather cumbersome and clunky, and even dangerous to the Artemis stock install since you had to run with administrator privilege and write over some of the stock files.
The mechanism involved either copying in a directory with Windows Explorer, or running a command-line batch file.
I wanted something easy and brainless and involved the least risk to the stock Artemis installation as possible, so I created Artemis Mod Loader (link below) to handle that. It is a graphical interface that works by setting up a copy of Artemis in your user profile directories, so administrative privilege is generally not needed.
I've predefined a list of Mods already, but adding more is easy. The definition and how the files are copied in are defined in XML files (under "ModDefinitions" folder in the Artemis Mod Loader install folder, for examples), but are not required when installing a new mod not already defined. The simplest way to add a new mod through the Artemis Mod Loader is to put all your files in a zip file with the same directory structure as what the directory structure should look like when installed in the Artemis folder. When you install your mod through the Artemis Mod Loader, it will prompt you for basic information and create the definition file ("*.aml") for you, which if you put in the root of your zip package, Artemis Mod Loader will use this for installing the Mod going forward.
This application can also be used for managing mission files.
Latest Stable version: Artemis Mod Loader 3.0.14
I probably should mention that you should start with a plain vanilla install of Artemis Spaceship Bridge Simulator.
I hope you enjoy.
Latest Changes
3.0
- Added mood music.
- Further refinement of Xml Editor
- Some refactoring of the Setup window.
- Fixed bug for Mod Developer when mapping files--if file being mapped to did not exist, you could not specify it.
- Added the "Into The Breach Look and Feel" mod by Dean Mallory as a Pre-defined mod.
- Modified file selection in VesselData editor and file mapping so that backslashes are now forward slashes, per Xml standard.
- Added Mission Studio.
3.0.1
- Had settings wrong on two of the pre-defined mods ("Into the Breach Look and Feel", and TNG) so that they did not get included with the installer. They should now be included.
3.0.2
- Tweaked the download source for "Into the Breach Look and Feel Mod" so that it downloads correctly.
- Bug Fix: VesselData editor: Turn Rate, Back Shields, and top speed would not get updated with changes.
- Bug Fix: Vesseldata editor: When the arc width was "1", then the arc would not render. Corrected by "faking" it. Internally, the arc is rendered as just shy of 1 (0.999999) to fix the issue.
- Bug Fix: VesselData Editor: Previously, if a vessel was assigned an invalid side (hull race), the user would only be told that vessel(s) had invalid data. Now, the user gets better feedback.
- Added code to ensure user settings gets kept whenever the application gets updated.
3.0.3
- Added code completion on the Mission Script for named objects
- Added "Launch Artemis Mod Loader" checkbox on installer
- Added code to self-update Artemis Mod Loader as updates become available. I just have to remember to update the file that indicates the current version in my DropBox account, or else the self-update won't self-update.
- Corrected bug with prompt for Artemis Path when it could not find Artemis install path. Prompts displayed funny and were not clear what it was asking.
- Changed code for rending backgrounds with Artemis skyboxes so that the file would not be locked. if the file was locked, there was the potential for crashing when applying a Mod.
3.0.4
- Fixed bug where Artemis Mod Loader would crash on startup if it could not find the *.ogg files (which can happen when initially installed).
- Added in the release date for Artemis version 1.702.
3.0.5
- Reorganized code to resolve reported crash on initial startup. Due to difficulty in reproducing issue, I'm not certain I got it, but I feel pretty good about it.
- Set "Stand by" window to always be on top.
- Fixed issue with self-update process. Version 3.0.3 and 3.0.4 would not auto-update properly unless user had admin access to the C: drive. Therefore, be sure to manually update to 3.0.5 by downloading and re-installing.
3.0.6
- If the Mod Definition file (*.aml) defined a folder structure that did not exist in the Mod pack (*.zip, *.rar), then Artemis Mod Loader would crash. This fixes that issue by simply providing a warning message instead of crashing. The Mod might not get applied--but at least we don't crash.
- Added version 2 of Mark Bell's TNG mod to the predefined list. PLEASE NOTE: if you installed version 2 of TNG using the predefined TNG mod prior to this version, you will need to completely uninstall the mod.
- Added code so that the Standby window would only temporarily be the top-most window. When it was always topmost, information messages would display behind it instead of being visible on top.
3.0.7
- Downloaded all mods to my Dropbox and set installation of Mods to pull from there. This way I have better control over the mods, though I won't be able to keep up with updates. I have had the problem in the past of folder structures changing, which wreaks all kinds of havoc on Artemis Mod Loader. This way I will be able to note changes in the structure and fix things myself before anyone gets ahold of it.
- Forgot to include the TNG version 2 in the installer--should now be included.
3.0.8
-Bug fix: Adding a race to the vesselData file in the Mod Developer crashed the application, trying to split the parse out the type keys ("Friend", "Enemy", etc.). Thanks to Kacie Stevens for reporting this.
-Bug fix: clicking "New" for a new vesselData file in the Mod Developer crashed the program.
-Added code to make sure Artemis Spaceship Bridge Simulator executable is found before trying to start it. Had an occasion of people telling me that Artemis Mod Loader was blowing up when trying to play Artemis, when the log file said it couldn't find the Artemis executable, which is why it crashed--the only reason it won't find the Artemis executable is that Artemis isn't installed.
-Added code to check that the Artemis Spaceship Bridge Simulator is no longer installed and offer the user to remove the copy used by Artemis Mod Loader--so that they can remain within License restrictions.
3.0.9
- Adding a new vessel to the vesselData file in the Mod Development editor failed to add an Art definition, so the Art definition list was empty. Since the Art definition was not blocked, changes would not get saved, until an Art Definiton was added. Also added code to disable entry if there is no available Art Defintion, since even one Art definition can be removed.
- Bug fix with the self-update process. If an update was detected, the process would crash once the update was downloaded. This is fixed, so that when the update is downloaded, the installer is run to install the update. However, version 3.0.9 and prior will require manual update.
3.0.10
Updated Into the Breach Mod to the latest, version 1.702.
If you were on version 3.0.9 of Artemis Mod Loader, it should automatically update.
If you already had the old version of Into the Breach installed through Artemis Mod Loader, you only need to uninstall and reinstall from the web (or download it from the link and install on PC manually).
3.0.11
- Added "Flight of the Artemis" fan music mod.
- Fixed bug--if Mod Loader was playing music from the Artemis install folder, it would not be able to replace that music. Solved problem by stopping all music when activating mods or updating the Stock version. Also prevented crashing if a file copy was unsuccessful.
- Added code to prevent crashing if for some reason it is unable to play a music file (possibly due to file corruption?) There may be a bit of quirkiness with the music playing at this time--but at least everything else should function fine.
- Fixed an issue with Star Trek: The Motion Picture Mod. Activating it would cause Artemis to crash after starting the server. This is now fixed.
- Updated Into The Breach to indicate that it does now support Invasion Mode.
NOTE: to see these changes to the MOD definitions, you MUST completely uninstall the MOD, close and restart Artemis Mod Loader, then re-install. Updating an already installed Mod is on the To-Do list.
3.0.12
Fixed the Mod Definition for Star Trek: Into the Breach. Should work good now. NOTE: to see these changes to the MOD definitions, you MUST completely uninstall the MOD, close and restart Artemis Mod Loader, then re-install. Updating an already installed Mod is on the To-Do list.
3.0.13
Added The TSN Overhaul Mod from here
Added code to check for updates to installed Mod Definitions and automatically apply them. If the Mod is Activated, simply deactivate and re-activate to apply the changes (no longer need to uninstall the mod). This check will only occur after the first run of an update to Artemis Mod Loader.
Changed References to "Android Client" to "Unofficial Android Client". The Official Android Client cannot be modded, but Thom gave his blessing to the author of the Unofficial Android Client to continue his work--and the Unofficial Android Client can be modded. The term "Unofficial" is added to differentiate the two versions. Code to mod the official Android client will be added once it is possible to be modded.
3.0.14
- Updated the link to the TSN Overhaul Mod. To pick up the updates that the author of this mod did, you will need to uninstall and re-install the mod. The update from 3.0.13 should allow for the automatic update of the download link of the mod definition if you have installed this mod, but this will be the first time it is in action, so any bugs in this function might crop up.
- Updated the definition file for TNG V2, provided by Mark Bell. Again, this uses the new definition update feature, but the TNG V2 package was also updated, so it should be unintalled and re-installed to pick up the updates.
3.0.15
- Improved performance of activating a mod by only copying files into the Artemis copy that are not specifically defined in the baseFiles mapping. This will prevent duplicate copies of files and copying files twice, so that the process should run faster on certain mods, plus the amount of disk space used is reduced.
- Strange and unexplainable error received on the file listing under Mod Development that crashed the application. Added code to prevent crashing, but due to nature of error, was unable to fix root cause.
3.0.16
- Updated the version stored in modified vesselData.xml files to 1.702, from 1.66.
- One last tweak to TNG_V2 Mod.
Enjoy!
Readme.txt contains full details of changes.
Please note that Google Chrome may warn you about the download being possibly dangerous (it did for me). You can ignore that.
The mechanism involved either copying in a directory with Windows Explorer, or running a command-line batch file.
I wanted something easy and brainless and involved the least risk to the stock Artemis installation as possible, so I created Artemis Mod Loader (link below) to handle that. It is a graphical interface that works by setting up a copy of Artemis in your user profile directories, so administrative privilege is generally not needed.
I've predefined a list of Mods already, but adding more is easy. The definition and how the files are copied in are defined in XML files (under "ModDefinitions" folder in the Artemis Mod Loader install folder, for examples), but are not required when installing a new mod not already defined. The simplest way to add a new mod through the Artemis Mod Loader is to put all your files in a zip file with the same directory structure as what the directory structure should look like when installed in the Artemis folder. When you install your mod through the Artemis Mod Loader, it will prompt you for basic information and create the definition file ("*.aml") for you, which if you put in the root of your zip package, Artemis Mod Loader will use this for installing the Mod going forward.
This application can also be used for managing mission files.
Latest Stable version: Artemis Mod Loader 3.0.14
I probably should mention that you should start with a plain vanilla install of Artemis Spaceship Bridge Simulator.
I hope you enjoy.
Latest Changes
3.0
- Added mood music.
- Further refinement of Xml Editor
- Some refactoring of the Setup window.
- Fixed bug for Mod Developer when mapping files--if file being mapped to did not exist, you could not specify it.
- Added the "Into The Breach Look and Feel" mod by Dean Mallory as a Pre-defined mod.
- Modified file selection in VesselData editor and file mapping so that backslashes are now forward slashes, per Xml standard.
- Added Mission Studio.
3.0.1
- Had settings wrong on two of the pre-defined mods ("Into the Breach Look and Feel", and TNG) so that they did not get included with the installer. They should now be included.
3.0.2
- Tweaked the download source for "Into the Breach Look and Feel Mod" so that it downloads correctly.
- Bug Fix: VesselData editor: Turn Rate, Back Shields, and top speed would not get updated with changes.
- Bug Fix: Vesseldata editor: When the arc width was "1", then the arc would not render. Corrected by "faking" it. Internally, the arc is rendered as just shy of 1 (0.999999) to fix the issue.
- Bug Fix: VesselData Editor: Previously, if a vessel was assigned an invalid side (hull race), the user would only be told that vessel(s) had invalid data. Now, the user gets better feedback.
- Added code to ensure user settings gets kept whenever the application gets updated.
3.0.3
- Added code completion on the Mission Script for named objects
- Added "Launch Artemis Mod Loader" checkbox on installer
- Added code to self-update Artemis Mod Loader as updates become available. I just have to remember to update the file that indicates the current version in my DropBox account, or else the self-update won't self-update.
- Corrected bug with prompt for Artemis Path when it could not find Artemis install path. Prompts displayed funny and were not clear what it was asking.
- Changed code for rending backgrounds with Artemis skyboxes so that the file would not be locked. if the file was locked, there was the potential for crashing when applying a Mod.
3.0.4
- Fixed bug where Artemis Mod Loader would crash on startup if it could not find the *.ogg files (which can happen when initially installed).
- Added in the release date for Artemis version 1.702.
3.0.5
- Reorganized code to resolve reported crash on initial startup. Due to difficulty in reproducing issue, I'm not certain I got it, but I feel pretty good about it.
- Set "Stand by" window to always be on top.
- Fixed issue with self-update process. Version 3.0.3 and 3.0.4 would not auto-update properly unless user had admin access to the C: drive. Therefore, be sure to manually update to 3.0.5 by downloading and re-installing.
3.0.6
- If the Mod Definition file (*.aml) defined a folder structure that did not exist in the Mod pack (*.zip, *.rar), then Artemis Mod Loader would crash. This fixes that issue by simply providing a warning message instead of crashing. The Mod might not get applied--but at least we don't crash.
- Added version 2 of Mark Bell's TNG mod to the predefined list. PLEASE NOTE: if you installed version 2 of TNG using the predefined TNG mod prior to this version, you will need to completely uninstall the mod.
- Added code so that the Standby window would only temporarily be the top-most window. When it was always topmost, information messages would display behind it instead of being visible on top.
3.0.7
- Downloaded all mods to my Dropbox and set installation of Mods to pull from there. This way I have better control over the mods, though I won't be able to keep up with updates. I have had the problem in the past of folder structures changing, which wreaks all kinds of havoc on Artemis Mod Loader. This way I will be able to note changes in the structure and fix things myself before anyone gets ahold of it.
- Forgot to include the TNG version 2 in the installer--should now be included.
3.0.8
-Bug fix: Adding a race to the vesselData file in the Mod Developer crashed the application, trying to split the parse out the type keys ("Friend", "Enemy", etc.). Thanks to Kacie Stevens for reporting this.
-Bug fix: clicking "New" for a new vesselData file in the Mod Developer crashed the program.
-Added code to make sure Artemis Spaceship Bridge Simulator executable is found before trying to start it. Had an occasion of people telling me that Artemis Mod Loader was blowing up when trying to play Artemis, when the log file said it couldn't find the Artemis executable, which is why it crashed--the only reason it won't find the Artemis executable is that Artemis isn't installed.
-Added code to check that the Artemis Spaceship Bridge Simulator is no longer installed and offer the user to remove the copy used by Artemis Mod Loader--so that they can remain within License restrictions.
3.0.9
- Adding a new vessel to the vesselData file in the Mod Development editor failed to add an Art definition, so the Art definition list was empty. Since the Art definition was not blocked, changes would not get saved, until an Art Definiton was added. Also added code to disable entry if there is no available Art Defintion, since even one Art definition can be removed.
- Bug fix with the self-update process. If an update was detected, the process would crash once the update was downloaded. This is fixed, so that when the update is downloaded, the installer is run to install the update. However, version 3.0.9 and prior will require manual update.
3.0.10
Updated Into the Breach Mod to the latest, version 1.702.
If you were on version 3.0.9 of Artemis Mod Loader, it should automatically update.
If you already had the old version of Into the Breach installed through Artemis Mod Loader, you only need to uninstall and reinstall from the web (or download it from the link and install on PC manually).
3.0.11
- Added "Flight of the Artemis" fan music mod.
- Fixed bug--if Mod Loader was playing music from the Artemis install folder, it would not be able to replace that music. Solved problem by stopping all music when activating mods or updating the Stock version. Also prevented crashing if a file copy was unsuccessful.
- Added code to prevent crashing if for some reason it is unable to play a music file (possibly due to file corruption?) There may be a bit of quirkiness with the music playing at this time--but at least everything else should function fine.
- Fixed an issue with Star Trek: The Motion Picture Mod. Activating it would cause Artemis to crash after starting the server. This is now fixed.
- Updated Into The Breach to indicate that it does now support Invasion Mode.
NOTE: to see these changes to the MOD definitions, you MUST completely uninstall the MOD, close and restart Artemis Mod Loader, then re-install. Updating an already installed Mod is on the To-Do list.
3.0.12
Fixed the Mod Definition for Star Trek: Into the Breach. Should work good now. NOTE: to see these changes to the MOD definitions, you MUST completely uninstall the MOD, close and restart Artemis Mod Loader, then re-install. Updating an already installed Mod is on the To-Do list.
3.0.13
Added The TSN Overhaul Mod from here
Added code to check for updates to installed Mod Definitions and automatically apply them. If the Mod is Activated, simply deactivate and re-activate to apply the changes (no longer need to uninstall the mod). This check will only occur after the first run of an update to Artemis Mod Loader.
Changed References to "Android Client" to "Unofficial Android Client". The Official Android Client cannot be modded, but Thom gave his blessing to the author of the Unofficial Android Client to continue his work--and the Unofficial Android Client can be modded. The term "Unofficial" is added to differentiate the two versions. Code to mod the official Android client will be added once it is possible to be modded.
3.0.14
- Updated the link to the TSN Overhaul Mod. To pick up the updates that the author of this mod did, you will need to uninstall and re-install the mod. The update from 3.0.13 should allow for the automatic update of the download link of the mod definition if you have installed this mod, but this will be the first time it is in action, so any bugs in this function might crop up.
- Updated the definition file for TNG V2, provided by Mark Bell. Again, this uses the new definition update feature, but the TNG V2 package was also updated, so it should be unintalled and re-installed to pick up the updates.
3.0.15
- Improved performance of activating a mod by only copying files into the Artemis copy that are not specifically defined in the baseFiles mapping. This will prevent duplicate copies of files and copying files twice, so that the process should run faster on certain mods, plus the amount of disk space used is reduced.
- Strange and unexplainable error received on the file listing under Mod Development that crashed the application. Added code to prevent crashing, but due to nature of error, was unable to fix root cause.
3.0.16
- Updated the version stored in modified vesselData.xml files to 1.702, from 1.66.
- One last tweak to TNG_V2 Mod.
Enjoy!
Readme.txt contains full details of changes.
Please note that Google Chrome may warn you about the download being possibly dangerous (it did for me). You can ignore that.
[Last edited Jun 27, 2013 19:11:07]
Sweet! I still had to uninstall then reinstall to install the newest version, but I really like the icon to start another session. Quick test makes it look like it works exactly as I'd expect, which is phenomenal.
I even layered the TMP mod on top of the TNG mod, and it worked! my ui and sound files with TMP mod, which was great. Then I clicked to deactivate the TMP mod, and boom. Said it couldn't find the artemis.ini file and shut down. I emailed the .log file. I tried hitting the "reset to artemis stock" and it still blows up.
I even layered the TMP mod on top of the TNG mod, and it worked! my ui and sound files with TMP mod, which was great. Then I clicked to deactivate the TMP mod, and boom. Said it couldn't find the artemis.ini file and shut down. I emailed the .log file. I tried hitting the "reset to artemis stock" and it still blows up.
I'm on it--Problem is kind of complex, but it has to do with the complex folder structure of the mod. I'll be able to fix it--just need a little time to work on it. Of all things, it's croaking not able to locate "artemis.ini" in the still active Mod to restore it.
Yeah, that's the main issue it was parroting back to me. Looking forward to the fix, this is coming along great! :)
Okay, got things fixed and did a few general clean-up things. Should work slick now.
Great! Just ran it a few different ways, stacked etc, and no problems activating, deactivating, resetting to base stock, etc. This is really nice, I'll definitely be including a .aml if I release my TNG mod. Or, I might just release the .aml and let folks figure it out from there :)
Nice!
Nice!
I started playing around with adding an editor for vesselData.xml to Artemis Mod Loader--to assist with Mod development. I'm nearly complete with the back-end engine for this (which loads the xml data into C# classes of my design, then saves it back), but I still need to build the user interface. It's going to be kind of rough since I don't really know what most of the attributes mean, though I can make educated guesses on a lot of it.
Is there any kind of documentation anywhere as to the meaning of the various attributes in vesselData.xml? It'd go much faster if I didn't have to do some trial-and-error on some of those attributes. Of particular interest are the meaning of the x, y, and z attributes on the various nodes--I imagine they relate to angles and distance, but it would be helpful to have clarification on them--I could more easily provide a graphical view if I have detailed information as to what these mean.
I probably will never bother with rendering an image of the ship--such as what you get with the Ship Editor tool (I have no idea how to do that with a *.dxs file and the strange-looking image file that goes with it, plus it would be a lot of work for a small benefit), but I thought of rendering a little triangle to make it easy to sketch out beam angles, engines, tubes, and shields. The vesselData.xml file doesn't look all that complex, and I'm sure adding a nice editor will make building custom vesselData files much easier.
Thanks.
Is there any kind of documentation anywhere as to the meaning of the various attributes in vesselData.xml? It'd go much faster if I didn't have to do some trial-and-error on some of those attributes. Of particular interest are the meaning of the x, y, and z attributes on the various nodes--I imagine they relate to angles and distance, but it would be helpful to have clarification on them--I could more easily provide a graphical view if I have detailed information as to what these mean.
I probably will never bother with rendering an image of the ship--such as what you get with the Ship Editor tool (I have no idea how to do that with a *.dxs file and the strange-looking image file that goes with it, plus it would be a lot of work for a small benefit), but I thought of rendering a little triangle to make it easy to sketch out beam angles, engines, tubes, and shields. The vesselData.xml file doesn't look all that complex, and I'm sure adding a nice editor will make building custom vesselData files much easier.
Thanks.
That would be nice, notepad gets old real quick :)
The X, Y, and Z coordinates on things like beam_port are the x, y, and z coordinates on the ship model itself. The *.dxs file loads into the DeleD open source modeling tool, and you can pick off the coordinates either by eyeing it in DeleD or using Thom's Artemis Ship Editor Tool to pick off coordinates fairly directly. The location on the model determines the center of the arc (for beams) and the location of the engine particle emitters or torpedo launchers, respectively.
For beams, the arcwidth is the percentage of a full circle the beam covers. cycletime is in seconds, and range... well, you know. For example:
<beam_port x="-78.24" y=" 41.71" z=" 164.49" damage="12" arcwidth="0.30" cycletime="10.2" range="1260"/>
Located at <-78.24,41.71,164.49> on the ship model, does 12 damage at nominal beam power in engineering, covers a 108° arc (30% of a circle) with the centerline drawn from <0,0,0> to <-78.24,41.71,164.49>, takes 10.2 seconds to recharge at nominal beam power and can hit targets up to 1260 meters from the center of the ship (not from the port!).
torpedo_tube location is just where the torpedoes nominally fire from, although it doesn't always. torpedo_storage types are the max number and starting number of various torpedoes; 0-3 homing, nuke, mines and ecm respectively. engine_port location is where engine particles are emitted from - you don't need these. If you delete/comment them out, then you don't have engine particles emitted.
uniqueID is the identifier the game passes around, side is linked to the hullRace ID at the top of the file. Classname is the name that pops up when selecting at the beginning of the mission/ship type before being scanned, broadType is used for enemy/ally selection randomization - if a mission calls for 14 "large" enemies, any enemy with the broadType "large" qualifies. Likewise, if you've got multiple bases you want to use in Invasion mode, just put several "base" broadType entries in the .xml. meshfile is the .dxs, diffuseFile is the minimum art file you need to render. glowFile and specularFile are both nice to have but not actually necessary to include. Scale is render scale compared to the .dxs model, pushRadius is theoretically how far out collision detection happens, although I'm not sure how well it works. turnrate and topspeed are pretty obvious, and the internal_data file is the engineering file for location of systems, damage control teams, etc. Shields pretty self explanatory and long_desc text is the text that displays during ship selection.
Lessee... fleet_ai commonality is the relative percent of the time that any given model will be selected randomly - a modifier for broadType random selection, basically.
I think that's it.
The X, Y, and Z coordinates on things like beam_port are the x, y, and z coordinates on the ship model itself. The *.dxs file loads into the DeleD open source modeling tool, and you can pick off the coordinates either by eyeing it in DeleD or using Thom's Artemis Ship Editor Tool to pick off coordinates fairly directly. The location on the model determines the center of the arc (for beams) and the location of the engine particle emitters or torpedo launchers, respectively.
For beams, the arcwidth is the percentage of a full circle the beam covers. cycletime is in seconds, and range... well, you know. For example:
<beam_port x="-78.24" y=" 41.71" z=" 164.49" damage="12" arcwidth="0.30" cycletime="10.2" range="1260"/>
Located at <-78.24,41.71,164.49> on the ship model, does 12 damage at nominal beam power in engineering, covers a 108° arc (30% of a circle) with the centerline drawn from <0,0,0> to <-78.24,41.71,164.49>, takes 10.2 seconds to recharge at nominal beam power and can hit targets up to 1260 meters from the center of the ship (not from the port!).
torpedo_tube location is just where the torpedoes nominally fire from, although it doesn't always. torpedo_storage types are the max number and starting number of various torpedoes; 0-3 homing, nuke, mines and ecm respectively. engine_port location is where engine particles are emitted from - you don't need these. If you delete/comment them out, then you don't have engine particles emitted.
uniqueID is the identifier the game passes around, side is linked to the hullRace ID at the top of the file. Classname is the name that pops up when selecting at the beginning of the mission/ship type before being scanned, broadType is used for enemy/ally selection randomization - if a mission calls for 14 "large" enemies, any enemy with the broadType "large" qualifies. Likewise, if you've got multiple bases you want to use in Invasion mode, just put several "base" broadType entries in the .xml. meshfile is the .dxs, diffuseFile is the minimum art file you need to render. glowFile and specularFile are both nice to have but not actually necessary to include. Scale is render scale compared to the .dxs model, pushRadius is theoretically how far out collision detection happens, although I'm not sure how well it works. turnrate and topspeed are pretty obvious, and the internal_data file is the engineering file for location of systems, damage control teams, etc. Shields pretty self explanatory and long_desc text is the text that displays during ship selection.
Lessee... fleet_ai commonality is the relative percent of the time that any given model will be selected randomly - a modifier for broadType random selection, basically.
I think that's it.
[Last edited Dec 31, 2012 13:53:56]
Ooo--that's good info. I had already figured on the torpedo_storage node (nothing to figure out). If I can figure out how to read the *.dxs file, then I can remove the need for even presenting the x,y,z to the user (you can take care of that with the Artemis Ship Editor Tool). That'll leave just having to deal with rendering arcwidth and range (using mouse control to adjust), and a prompt for cycletime. A question about this, though, is how would a beam_port be specified for an arc that fires from the rear, or from one side or the other? This information suggests only forward firing beams, though you could specify a beam with a 360 degree firing arc. Or is there no way to specify this (or perhaps the x,y,z position affect the position of the arc?)?
Under "hullRace", what are valid values for "keys"? I understand from looking at the stock vesselData file what the keys that are currently there mean (they're not hard to figure out), but are there other values that can be used?
Are there limits to what can be used for "broadType"? Or is it just an arbitrary value?
Under "art", I think I know what "scale" means, but is there a valid range, (can it be picked up from the *.dxs file?) and what does the "pushRadius" mean?
I think that covers my remaining questions. I think my biggest challenge left to me will be figuring out how to read the *.dxs file. Taking the x,y, and z out of the equation really simplifies the work ahead.
I can see just how much easier this will make editing the vesseldata file. Yeah, I think you'll love what I have in mind.
Under "hullRace", what are valid values for "keys"? I understand from looking at the stock vesselData file what the keys that are currently there mean (they're not hard to figure out), but are there other values that can be used?
Are there limits to what can be used for "broadType"? Or is it just an arbitrary value?
Under "art", I think I know what "scale" means, but is there a valid range, (can it be picked up from the *.dxs file?) and what does the "pushRadius" mean?
I think that covers my remaining questions. I think my biggest challenge left to me will be figuring out how to read the *.dxs file. Taking the x,y, and z out of the equation really simplifies the work ahead.
I can see just how much easier this will make editing the vesseldata file. Yeah, I think you'll love what I have in mind.
So the beam arc width is the arcwidth value, and the center of the arc is a vector drawn from (0,0,0) to the (x,y,z) of the beam_port (although since it's 2D, really just x and z). So, if my beam_port was located at (0,0,100), then the center of the beam arc would be directly forward <0,0,1>. If my beam_port was at <100,0,0>, then the center of the beam arc would be directly to port <0,0,1>. (-100, 0, -100) would be aft starboard <-1,0,-1>, etc, etc. So, the beam_port location determines the location on the physical model the beam emits from as well as the center of the arc (the x,y,z is actually just the vector, if you think about it). Once the center of the arc is determined, then the arcwidth goes half to clockwise, half to counterclockwise.
Valid keys (afaik) for allied are "player" and "friendly". For enemies, you need "enemy" in addition to any of a number of modifiers, minimum "standard", "support", or "elite", plus optional bonuses of "whalehater", "whalelover" and "loner" (I think loner is optional, although I haven't seen any "elite" tags as anything other than "loner elite"). For example, the hullRace ID list from my mod:
<hullRace ID="0" name="Starfleet" keys="player"/>
<hullRace ID="1" name="Starfleet" keys="friendly"/>
<hullRace ID="2" name="Klingon" keys="enemy standard"/>
<hullRace ID="27" name="Klingon" keys="enemy support"/>
<hullRace ID="29" name="Klingon" keys="enemy loner elite"/>
<hullRace ID="3" name="Romulan" keys="enemy standard"/>
<hullRace ID="37" name="Romulan" keys="enemy support"/>
<hullRace ID="39" name="Romulan" keys="enemy loner elite"/>
<hullRace ID="4" name="Dominion" keys="enemy standard"/>
<hullRace ID="47" name="Dominion" keys="enemy support whalehater"/>
<hullRace ID="49" name="Dominion" keys="enemy loner elite"/>
<hullRace ID="5" name="Cardassian" keys="enemy standard whalelover" />
<hullRace ID="69" name="Ferengi" keys="enemy loner elite whalelover" />
<hullRace ID="99" name="Borg" keys="enemy loner elite whalehater"/>
Name, obviously, does not need to be unique. I have uniqueIDs for ships up to 9901 (not that I have that many ships!), mostly so I can keep them organized and recognize the ship race and type by glancing.
For broadType, I think some are necessary if only for general compatibility - small, medium, large, carrier, fighter, player, base. These are the broadTypes that the game looks for when in Invasion mode or most missions. You can have other broadTypes, but they won't ever get picked randomly (although they should work in missions). I think.
The scale is just a scaling factor applied to the .dxs model. If you open a model in DeleD, the model is a certain size in units. That is interpreted directly as meters in Artemis unless the scale is other than 1. For example, I've got a ship that I want to be 685m in the game. I can either make it 685 units in DeleD or I can take the size it is in DeleD and scale it in the game (if it's 68.5 units in DeleD, I set scale="10.0" and poof). This can be useful for designing internal data files and skinning and such - you might build it in DeleD at 10x or 50x and scale it down for the game. Also, the Ship Editor pulls up the model at 1:1 scale, so if you're having trouble making the .snt or picking off certain points, then you might want a larger scale model that gets scaled down.
Valid keys (afaik) for allied are "player" and "friendly". For enemies, you need "enemy" in addition to any of a number of modifiers, minimum "standard", "support", or "elite", plus optional bonuses of "whalehater", "whalelover" and "loner" (I think loner is optional, although I haven't seen any "elite" tags as anything other than "loner elite"). For example, the hullRace ID list from my mod:
<hullRace ID="0" name="Starfleet" keys="player"/>
<hullRace ID="1" name="Starfleet" keys="friendly"/>
<hullRace ID="2" name="Klingon" keys="enemy standard"/>
<hullRace ID="27" name="Klingon" keys="enemy support"/>
<hullRace ID="29" name="Klingon" keys="enemy loner elite"/>
<hullRace ID="3" name="Romulan" keys="enemy standard"/>
<hullRace ID="37" name="Romulan" keys="enemy support"/>
<hullRace ID="39" name="Romulan" keys="enemy loner elite"/>
<hullRace ID="4" name="Dominion" keys="enemy standard"/>
<hullRace ID="47" name="Dominion" keys="enemy support whalehater"/>
<hullRace ID="49" name="Dominion" keys="enemy loner elite"/>
<hullRace ID="5" name="Cardassian" keys="enemy standard whalelover" />
<hullRace ID="69" name="Ferengi" keys="enemy loner elite whalelover" />
<hullRace ID="99" name="Borg" keys="enemy loner elite whalehater"/>
Name, obviously, does not need to be unique. I have uniqueIDs for ships up to 9901 (not that I have that many ships!), mostly so I can keep them organized and recognize the ship race and type by glancing.
For broadType, I think some are necessary if only for general compatibility - small, medium, large, carrier, fighter, player, base. These are the broadTypes that the game looks for when in Invasion mode or most missions. You can have other broadTypes, but they won't ever get picked randomly (although they should work in missions). I think.
The scale is just a scaling factor applied to the .dxs model. If you open a model in DeleD, the model is a certain size in units. That is interpreted directly as meters in Artemis unless the scale is other than 1. For example, I've got a ship that I want to be 685m in the game. I can either make it 685 units in DeleD or I can take the size it is in DeleD and scale it in the game (if it's 68.5 units in DeleD, I set scale="10.0" and poof). This can be useful for designing internal data files and skinning and such - you might build it in DeleD at 10x or 50x and scale it down for the game. Also, the Ship Editor pulls up the model at 1:1 scale, so if you're having trouble making the .snt or picking off certain points, then you might want a larger scale model that gets scaled down.
pushRadius is an effort to keep ship models from clipping each other as much. Sometimes it works, others not so much. Ideally, I could take a 685m ship, set pushradius="392.5" and then nothing would be able to get their pushradius any closer than 392.5 m from my ship center.
Okay, I've got the grasp of the x,y,z. I'm not going to spend a lot of time figuring out how to render a ship from a dxs file (though I was surprised to see that it was a simple xml file), so I'll have the user use the Ship Editor Tool to get x,y, and z and enter it manually. Not quite as nice as having it all built in, but it could take me a while to figure out 3D rendering--since that's beyond my experience.
All other parameters should be pretty straight forward--most of them just entering numbers, but the beam arc width and range should be adjustable by mouse (easy once I've got the start point), with rendering of a simple triangle to represent the ship.
I'll probably make broadType a simple drop-down, with the ability to add beyond the standard. Keys will be limited to the basic checkbox selection, with basic validation (can't have an enemy be both a whalelover and a whalehater).
Looks like IDs and uniqueIDs will be positive integer values. I don't see any limit to the range.
I don't see anything other than pushRadius suggesting ship size. Would it be best to simply prompt for the ship size, then set push radius to half that?
Do you know if there is a valid limit to the values for shields? I noticed the Doomsday Machine in ITB had the rear shield set to "999"--I would have thought it should be much higher, if it could be (I was able to destroy the thing simply by blasting away at it for a long time from behind, where it couldn't get me).
On another topic, one feature I thought would be nice to add would be a "DependsOn" attribute. This would indicate that your Mod depends on another Mod being activated. For example, if your Mod uses files from the TMP Mod, then you could use this DependsOn attribute to indicate that, so that when the Artemis Mod Loader activates your Mod, it can at least warn the user that the TMP Mod should also be activated.
I also thought of having such an attribute added to mission files (it would have to be within an XML comment), so that you can have an easy way of creating a mission for various Mods and keep it clear as to which Mod your mission is for (and not have to include the Mod with your mission package).
Not sure if such a feature would be helpful or needed--it's just a thought.
All other parameters should be pretty straight forward--most of them just entering numbers, but the beam arc width and range should be adjustable by mouse (easy once I've got the start point), with rendering of a simple triangle to represent the ship.
I'll probably make broadType a simple drop-down, with the ability to add beyond the standard. Keys will be limited to the basic checkbox selection, with basic validation (can't have an enemy be both a whalelover and a whalehater).
Looks like IDs and uniqueIDs will be positive integer values. I don't see any limit to the range.
I don't see anything other than pushRadius suggesting ship size. Would it be best to simply prompt for the ship size, then set push radius to half that?
Do you know if there is a valid limit to the values for shields? I noticed the Doomsday Machine in ITB had the rear shield set to "999"--I would have thought it should be much higher, if it could be (I was able to destroy the thing simply by blasting away at it for a long time from behind, where it couldn't get me).
On another topic, one feature I thought would be nice to add would be a "DependsOn" attribute. This would indicate that your Mod depends on another Mod being activated. For example, if your Mod uses files from the TMP Mod, then you could use this DependsOn attribute to indicate that, so that when the Artemis Mod Loader activates your Mod, it can at least warn the user that the TMP Mod should also be activated.
I also thought of having such an attribute added to mission files (it would have to be within an XML comment), so that you can have an easy way of creating a mission for various Mods and keep it clear as to which Mod your mission is for (and not have to include the Mod with your mission package).
Not sure if such a feature would be helpful or needed--it's just a thought.
I like the drop down idea for broadType, just keep things simple.
Honestly, that's how I do pushRadius - I decide how big the ship should be, apply a scale for the model, then set the pushRadius to half the in game ship size. I just do it manually :P
I don't know if there is an upper limit. Some of my stations have a shield rating of 8000, and a certain cybernetic zombie race have ships with 40000 shields for the spheres and something ludicrous like 160000 for cubes. (I had to set them that high to avoid setting _all_ enemies as having stupid fast shield recharge times in the .ini. Although, the Borg do have really high shields.)
I like the dependencies idea. I try to keep my mods pretty self contained, but it'd be nice to have a note if you needed a particular mod installed. Especially for missions.
Honestly, that's how I do pushRadius - I decide how big the ship should be, apply a scale for the model, then set the pushRadius to half the in game ship size. I just do it manually :P
I don't know if there is an upper limit. Some of my stations have a shield rating of 8000, and a certain cybernetic zombie race have ships with 40000 shields for the spheres and something ludicrous like 160000 for cubes. (I had to set them that high to avoid setting _all_ enemies as having stupid fast shield recharge times in the .ini. Although, the Borg do have really high shields.)
I like the dependencies idea. I try to keep my mods pretty self contained, but it'd be nice to have a note if you needed a particular mod installed. Especially for missions.
[Last edited Dec 31, 2012 16:34:23]
Okay, to keep from hijacking the Android Client thread, I thought I'd continue the train of thought on the Android client issues here:
On the Android Client thread, some issues with using my Mod Loader to copy necessary Mod files to the Android were brought up: A user's android might not have a USB port, they may not have an accessible SD card, and they might not have the Android SDK installed.
So...
Maybe I'm asking the wrong questions.
Okay, you don't have the Android SDK, so the "adb push" is out.
Your tablet does not have USB connection functionality, so plugging into the USB port is out.
And you don't have an SD or micro SD card for your Android that can be removed, so putting it into an SD reader to attach to your PC is out.
Okay--so how did you get the Android client installed in the first place? Answering that question may give me ideas as to how to get the mod to the Android.
Perhaps my question sounds a little dense--admittedly I'm not much of an Android person. I picked up a cheap one from Big Lots and found little use for it beyond playing Angry Birds and the Artemis Android Client. So I don't really know how most people would do things with the Android--like solving this little puzzle. I can only imagine that the only way to install the Artemis client on the Android given such a situation would be to browse to it with the browser and download it directly. If such is the case, then is there some way I can transmit the mod's files via WiFi (maybe dump the files on a shared directory and have the Android browse to that directory?), or have the user specify a web site to upload it to, or something like that? I practically know C# backwards, but when it comes to the Android, I'm kind of lost. I don't really have to have the Artemis Mod Loader have all the solutions, but it would be nice to at least be able to provide the necessary instruction to solve this little situation.
Of course, as you pointed out, most Android devices have an accessible SD card, and I had assumed that most have a USB port, since my little cheap one has one. So maybe I'm worrying only about a small 1% who are stuck?
On the Android Client thread, some issues with using my Mod Loader to copy necessary Mod files to the Android were brought up: A user's android might not have a USB port, they may not have an accessible SD card, and they might not have the Android SDK installed.
So...
Maybe I'm asking the wrong questions.
Okay, you don't have the Android SDK, so the "adb push" is out.
Your tablet does not have USB connection functionality, so plugging into the USB port is out.
And you don't have an SD or micro SD card for your Android that can be removed, so putting it into an SD reader to attach to your PC is out.
Okay--so how did you get the Android client installed in the first place? Answering that question may give me ideas as to how to get the mod to the Android.
Perhaps my question sounds a little dense--admittedly I'm not much of an Android person. I picked up a cheap one from Big Lots and found little use for it beyond playing Angry Birds and the Artemis Android Client. So I don't really know how most people would do things with the Android--like solving this little puzzle. I can only imagine that the only way to install the Artemis client on the Android given such a situation would be to browse to it with the browser and download it directly. If such is the case, then is there some way I can transmit the mod's files via WiFi (maybe dump the files on a shared directory and have the Android browse to that directory?), or have the user specify a web site to upload it to, or something like that? I practically know C# backwards, but when it comes to the Android, I'm kind of lost. I don't really have to have the Artemis Mod Loader have all the solutions, but it would be nice to at least be able to provide the necessary instruction to solve this little situation.
Of course, as you pointed out, most Android devices have an accessible SD card, and I had assumed that most have a USB port, since my little cheap one has one. So maybe I'm worrying only about a small 1% who are stuck?
Stumbled onto a significant bug this weekend--the Mod Loader would crash on first run checking to see if Artemis had been updated--so thought it best to release a new update, which also includes a number of other features I was working on, though be forewarned that I haven't really put the new features through the testing paces, yet.
The vesselData editor development is in full swing--the back-end engine for this is complete, other than data validation (basically, it loads the XML into my C# classes, then saves it back from the C# classes into the properly formatted XML file, and does it correctly). One thing I've realized with the way this behaves is that it should very easily upgrade a vesselData.xml file that is not compatible with the current version of Artemis. A simple example is that in the ITB mod, it is for vesselData version 1.56. The current version is 1.66. The only thing really wrong with the 1.56 version is that it is missing the "pushRadius" attribute. Doing nothing more than loading vesselData into the editor and saving it back will automatically add the "pushRadius" attribute, though it will be with a value of "0". Old versions of vesselData.xml will load into the editor without issue (unless you have some invalid XML characters in it), so upgrading the vesselData file will be practically no-brainer. When the next update to Artemis is provided, I will try to update my code as quickly as possible to handle any changes--so that updating your Mods will be as about no-brainer as it gets. I still have a lot of work to do for the UI, but with the hard part complete, it's just grunt work at this point.
I've also decided to go beyond just an editor for vesselData and provide a full Mod developer manager tool integrated into the Mod Loader (but will be added at a later release). The idea here is that it will go so far as providing an easy way to develop, test, package, and deploy your Mod. The way I see it, the easier I can make it for you Mod developers out there, the more and better Mods we can see.
The vesselData editor development is in full swing--the back-end engine for this is complete, other than data validation (basically, it loads the XML into my C# classes, then saves it back from the C# classes into the properly formatted XML file, and does it correctly). One thing I've realized with the way this behaves is that it should very easily upgrade a vesselData.xml file that is not compatible with the current version of Artemis. A simple example is that in the ITB mod, it is for vesselData version 1.56. The current version is 1.66. The only thing really wrong with the 1.56 version is that it is missing the "pushRadius" attribute. Doing nothing more than loading vesselData into the editor and saving it back will automatically add the "pushRadius" attribute, though it will be with a value of "0". Old versions of vesselData.xml will load into the editor without issue (unless you have some invalid XML characters in it), so upgrading the vesselData file will be practically no-brainer. When the next update to Artemis is provided, I will try to update my code as quickly as possible to handle any changes--so that updating your Mods will be as about no-brainer as it gets. I still have a lot of work to do for the UI, but with the hard part complete, it's just grunt work at this point.
I've also decided to go beyond just an editor for vesselData and provide a full Mod developer manager tool integrated into the Mod Loader (but will be added at a later release). The idea here is that it will go so far as providing an easy way to develop, test, package, and deploy your Mod. The way I see it, the easier I can make it for you Mod developers out there, the more and better Mods we can see.
Looking forward to the mod developer - I'd like to release my TNG mod with a few missions thrown in for good measure and having a way to check things as I go would be nice. Also, having the program take in my hellish mess of .xml files and reorganizing them in a straightforward way will be very good :)
I'm intrigued by the add on bit for the Artemis Extender - have you tried testing that? (I don't use it myself, but I know a number of folks do.)
I'm intrigued by the add on bit for the Artemis Extender - have you tried testing that? (I don't use it myself, but I know a number of folks do.)
Login below to reply:
