Question: A1 odf command
Talk about anything related to old versions of Armada.
1, 2
posted on September 11th, 2012, 8:22 pm
Question: A1 odf command
Hypothesis: Similar to Armada 2, there exists a upgrade function in Armada 1.
Evidence to support the theory: Within the stock set of object definition files exists a file called bupgrade.odf. Within this file, the following odf command exists: isUpgrade. In context, it appears this command is associated with the pod classLabel.
//**********************************************************************
//PROGRAMMING PARAMETERS WHICH SHOULD NOT BE CHANGED & UNUSED PARAMETERS
//programming thing DO NOT CHANGE
classLabel = "pod"
// Mark as special upgrade pod.
isUpgrade = 1
//**********************************************************************
Note the similarity to the A2 command extracted from one of the A2 upgrade files.
isShipUpgrade = 1
upgradeLevel = 3
upgradeMultiplier = 1.50
upgradeSystem = "engines"
Using a HEX editor, it is clear that isUpgrade is in the A1 code in some form or fashion. The question that I have for you is whether or not anyone has experimented with this and figured out how it works and what does it upgrade or how one specifies which system to upgrade.
//** BUPGRADE.ODF FROM A1 **********************************************************
//MAIN DESIGN PARAMETERS
//Name of Ship class in Ship Display window & in edit mode & tooltip
unitName = "Research Upgrade"
//Base name for upgrade.
baseName = "bresear2"
//Race which can build ship & starting race of ship
race = "borg"
//Amount of time required to build ship
buildTime = 30.0
//Number of officers required to build this ship
officerCost = 0
//Number of crew required to build ship & Starting crew
crewCost = 0
//Dilithium Cost to build
dilithiumCost = 400
//Max Shield Strength & Begining Shield Strength <1000
maxHealth = 500
//Rate at which shield recharges (points per second... we think)
shieldRate = 15
//Delay before shield begins recharging once it has reached zero (secs)
shieldDelay = 3.0f
//Maximum Value of Special Energy
maxSpecialEnergy = 0
//Rate at which special energy recharges (points per second... we think)
specialEnergyRate = 5
//This is the range in meters which the ships sensors can see (LOS)
rangeScan = 700.0f
//This is the range in meters which the ships sensors can see when destroyed
damagedScan = 100.0f
//************************************************************
//CREW STATUS MULTIPLIERS
//The percentage at which the crew enters yellow status (ex. 0.75f)
crewYellowStatus = 0.75f
//The percentage at which the crew enters red status (ex. 0.25f)
crewRedStatus = 0.25f
//The multiplier for the repair time while in yellow status
repairYellow = 2.0f
//The multiplier for the repair time while in red status
repairRed = 4.0f
//The multiplier for the delay between shots for weapons while in yellow status
weaponYellow = 1.5f
//The multiplier for the delay between shots for weapons while in red status
weaponRed = 2.5f
//**********************************************************************
//**********************************************************************
//SYSTEM HITPOINTS
//These values are the hitpoint values of the systems
//If the value is set to zero the ship does not have that system
enginesHitPoints = 0
lifeSupportHitPoints = 0
weaponsHitPoints = 0
shieldGeneratorHitPoints = 0
sensorsHitPoints = 0
//**********************************************************************
//**********************************************************************
//SYSTEM DAMAGE DISTRIBUTION
//The following section's values should add up to 100
//Percent Chance out of 100 of engines being destroyed
enginesHitPercent = 0.0f
//Percent Chance out of 100 of life support being destroyed
lifeSupportHitPercent = 0.0f
//Percent Chance out of 100 of weapons being destroyed
weaponsHitPercent = 0.0f
//Percent Chance out of 100 of shields being destroyed
shieldGeneratorHitPercent = 0.0f
//Percent Chance out of 100 of sensors being destroyed
sensorsHitPercent = 0.0f
//Percent Chance out of 100 of hull being hit (crew dying)
hullHitPercent = 0.0f
//Percent Chance out of 100 of entire ship exploding
criticalHitPercent = 100.0f
//**********************************************************************
//**********************************************************************
//SYSTEM REPAIR RATES
//This is the amount of time in seconds to repair ONE hitpoint of damage
//modified by race and crew status
enginesRepairTime = 10.0f
lifeSupportRepairTime = 10.0f
weaponsRepairTime = 10.0f
shieldGeneratorRepairTime = 10.0f
sensorsRepairTime = 10.0f
//**********************************************************************
//**********************************************************************
//CREW CASUALTY FOR SYSTEM DESTRUCTION
//The percentage of crew killed when the engines are destroyed
enginesCrewLoss = 15.0f
//The percentage of crew killed when the lifesupport is destroyed
lifeSupportCrewLoss = 10.0f
//The percentage of crew killed when the weapons are destroyed
weaponsCrewLoss = 5.0f
//The percentage of crew killed when the shields are destroyed
shieldGeneratorCrewLoss = 15.0f
//The percentage of crew killed when the sensors are destroyed
sensorsCrewLoss = 5.0f
//The percentage of crew lost every second while life support is disabled
lifeSupportLoss = 5.0f
//**********************************************************************
//**********************************************************************
//MESSAGE & SOUND PARAMETERS
diedMsg = "abetty3.wav"
soundDeploy = "avsave5.wav"
soundUndeploy = "avsave6.wav"
soundThrust = "avsave0.wav"
//**********************************************************************
//**********************************************************************
//PHYSICS PARAMETERS
physicsFile = "destphys.odf"
//**********************************************************************
//**********************************************************************
//PROGRAMMING PARAMETERS WHICH SHOULD NOT BE CHANGED & UNUSED PARAMETERS
//programming thing DO NOT CHANGE
classLabel = "pod"
//This tells the program that this object is a starbase
is_starbase = 1
// Mark as special upgrade pod.
isUpgrade = 1
//NOT USED CURRENTLY
periodScan = 0.0f
//Not USED CURRENTLY
velocJam = 5.0f
//**********************************************************************
//AI stuff
aiName = "CraftProcess"
Hypothesis: Similar to Armada 2, there exists a upgrade function in Armada 1.
Evidence to support the theory: Within the stock set of object definition files exists a file called bupgrade.odf. Within this file, the following odf command exists: isUpgrade. In context, it appears this command is associated with the pod classLabel.
//**********************************************************************
//PROGRAMMING PARAMETERS WHICH SHOULD NOT BE CHANGED & UNUSED PARAMETERS
//programming thing DO NOT CHANGE
classLabel = "pod"
// Mark as special upgrade pod.
isUpgrade = 1
//**********************************************************************
Note the similarity to the A2 command extracted from one of the A2 upgrade files.
isShipUpgrade = 1
upgradeLevel = 3
upgradeMultiplier = 1.50
upgradeSystem = "engines"
Using a HEX editor, it is clear that isUpgrade is in the A1 code in some form or fashion. The question that I have for you is whether or not anyone has experimented with this and figured out how it works and what does it upgrade or how one specifies which system to upgrade.
//** BUPGRADE.ODF FROM A1 **********************************************************
//MAIN DESIGN PARAMETERS
//Name of Ship class in Ship Display window & in edit mode & tooltip
unitName = "Research Upgrade"
//Base name for upgrade.
baseName = "bresear2"
//Race which can build ship & starting race of ship
race = "borg"
//Amount of time required to build ship
buildTime = 30.0
//Number of officers required to build this ship
officerCost = 0
//Number of crew required to build ship & Starting crew
crewCost = 0
//Dilithium Cost to build
dilithiumCost = 400
//Max Shield Strength & Begining Shield Strength <1000
maxHealth = 500
//Rate at which shield recharges (points per second... we think)
shieldRate = 15
//Delay before shield begins recharging once it has reached zero (secs)
shieldDelay = 3.0f
//Maximum Value of Special Energy
maxSpecialEnergy = 0
//Rate at which special energy recharges (points per second... we think)
specialEnergyRate = 5
//This is the range in meters which the ships sensors can see (LOS)
rangeScan = 700.0f
//This is the range in meters which the ships sensors can see when destroyed
damagedScan = 100.0f
//************************************************************
//CREW STATUS MULTIPLIERS
//The percentage at which the crew enters yellow status (ex. 0.75f)
crewYellowStatus = 0.75f
//The percentage at which the crew enters red status (ex. 0.25f)
crewRedStatus = 0.25f
//The multiplier for the repair time while in yellow status
repairYellow = 2.0f
//The multiplier for the repair time while in red status
repairRed = 4.0f
//The multiplier for the delay between shots for weapons while in yellow status
weaponYellow = 1.5f
//The multiplier for the delay between shots for weapons while in red status
weaponRed = 2.5f
//**********************************************************************
//**********************************************************************
//SYSTEM HITPOINTS
//These values are the hitpoint values of the systems
//If the value is set to zero the ship does not have that system
enginesHitPoints = 0
lifeSupportHitPoints = 0
weaponsHitPoints = 0
shieldGeneratorHitPoints = 0
sensorsHitPoints = 0
//**********************************************************************
//**********************************************************************
//SYSTEM DAMAGE DISTRIBUTION
//The following section's values should add up to 100
//Percent Chance out of 100 of engines being destroyed
enginesHitPercent = 0.0f
//Percent Chance out of 100 of life support being destroyed
lifeSupportHitPercent = 0.0f
//Percent Chance out of 100 of weapons being destroyed
weaponsHitPercent = 0.0f
//Percent Chance out of 100 of shields being destroyed
shieldGeneratorHitPercent = 0.0f
//Percent Chance out of 100 of sensors being destroyed
sensorsHitPercent = 0.0f
//Percent Chance out of 100 of hull being hit (crew dying)
hullHitPercent = 0.0f
//Percent Chance out of 100 of entire ship exploding
criticalHitPercent = 100.0f
//**********************************************************************
//**********************************************************************
//SYSTEM REPAIR RATES
//This is the amount of time in seconds to repair ONE hitpoint of damage
//modified by race and crew status
enginesRepairTime = 10.0f
lifeSupportRepairTime = 10.0f
weaponsRepairTime = 10.0f
shieldGeneratorRepairTime = 10.0f
sensorsRepairTime = 10.0f
//**********************************************************************
//**********************************************************************
//CREW CASUALTY FOR SYSTEM DESTRUCTION
//The percentage of crew killed when the engines are destroyed
enginesCrewLoss = 15.0f
//The percentage of crew killed when the lifesupport is destroyed
lifeSupportCrewLoss = 10.0f
//The percentage of crew killed when the weapons are destroyed
weaponsCrewLoss = 5.0f
//The percentage of crew killed when the shields are destroyed
shieldGeneratorCrewLoss = 15.0f
//The percentage of crew killed when the sensors are destroyed
sensorsCrewLoss = 5.0f
//The percentage of crew lost every second while life support is disabled
lifeSupportLoss = 5.0f
//**********************************************************************
//**********************************************************************
//MESSAGE & SOUND PARAMETERS
diedMsg = "abetty3.wav"
soundDeploy = "avsave5.wav"
soundUndeploy = "avsave6.wav"
soundThrust = "avsave0.wav"
//**********************************************************************
//**********************************************************************
//PHYSICS PARAMETERS
physicsFile = "destphys.odf"
//**********************************************************************
//**********************************************************************
//PROGRAMMING PARAMETERS WHICH SHOULD NOT BE CHANGED & UNUSED PARAMETERS
//programming thing DO NOT CHANGE
classLabel = "pod"
//This tells the program that this object is a starbase
is_starbase = 1
// Mark as special upgrade pod.
isUpgrade = 1
//NOT USED CURRENTLY
periodScan = 0.0f
//Not USED CURRENTLY
velocJam = 5.0f
//**********************************************************************
//AI stuff
aiName = "CraftProcess"
posted on September 11th, 2012, 8:55 pm
isUpgrade is also an A2 command; both are for ResearchPods. I wasn't able to find a function for either one unfortunately. I did not test the command with events functions, so it may have a use there, though I am quite doubtful
. There are about 40 commands in A1/A2 that I have yet to find a function for, yet are referenced by the executable 


posted on September 13th, 2012, 9:11 pm
Just as a real quick test I placed the command isUpgrade = 1 into one of the stock Romulan pods and didn't change anything else. I tested it to see what it would do and when I researched that particular pod. It researched as you might have expected however the sod for the pod wasn't observable. In other words, during the research phase there was no evidence of the pod sod being "built" and when the research was complete the pod's sod file wasn't present on the research station. The functionality of the pod (special weapon) wasn't affected and it was availbel on the particualar ship. I couldn't tell if anything was upgraded or not.
posted on September 13th, 2012, 9:37 pm
In A2 the model is still observable with isUpgrade being true; however, it is built at the root of the producer and cannot be selected (and thus not directly attacked). When the producer is destroyed prior to the pod's destruction, A2 crashes as well. Other than that there appears to be no changes to functionality.
posted on September 15th, 2012, 1:21 am
I was quasi successful in getting this to work.
1. Took a research station and added an pod node to the hierarchy and centered it at 0, 0, 0.
2. Created a pod odf which used the research station as its sod and included the isUpgrade = 1 command in this odf.
3. Changed the maxHealth and rangeScan values in this pods odf to something more significant than those in the research odf.
4. Added the upgrade = 2 command into the respective research odf. The hypothesis being that this command governs the number of upgradeable thing.
5. Tested
Was able to research the upgrade pod at the research station. When complete the research station seemed to inherit the increased values (maxHealth and rangeScan ) from the pod.
Now, it is still unclear what exactly can be upgraded or what effect this might have in game against an AI player.
1. Took a research station and added an pod node to the hierarchy and centered it at 0, 0, 0.
2. Created a pod odf which used the research station as its sod and included the isUpgrade = 1 command in this odf.
3. Changed the maxHealth and rangeScan values in this pods odf to something more significant than those in the research odf.
4. Added the upgrade = 2 command into the respective research odf. The hypothesis being that this command governs the number of upgradeable thing.
5. Tested
Was able to research the upgrade pod at the research station. When complete the research station seemed to inherit the increased values (maxHealth and rangeScan ) from the pod.
Now, it is still unclear what exactly can be upgraded or what effect this might have in game against an AI player.
posted on September 15th, 2012, 3:05 am
Holy crap, nice find! Appears that this functions very similarly for Armada II as well. Didn't think I'd see a new function in A2, but if I'm not getting ahead of myself this is a very very useful find for Fleet Operations. Great work Pepperman
Currently seems to change only the following for the Producer in A2:
-maxHealth (and not maxShields -> if maxHealth is default, hull hitpoints become inherited as 0 and shield hitpoints are unchanged from the original of the Producer)
'upgrade' flag in a ResearchStation has no effect, and all integer values of isUpgrade 1 and greater have the same effect as one another. The last ResearchPod to be built will create the inherited effect, which can be reverted by researching another ResearchPod etc. If another ResearchPod with isUpgrade is built, it detaches the previous one (although it still remains in game, yet does not effect the crash scanrange bug).
The rangescan for at least A2 is actually a property of the researchPod and not the Producer.
I tested maxhealth,maxshields,shieldrate,healthrate,rangescan,maxspecialenergy, hidden,shieldpad, maximumcrew,crewcost to see if there were any additional effects before getting lazy.
I've never been able to successfully test things out in A1 due to my graphics card, so hopefully you can find some extra functionality with 'upgrade' (which also seems to be duplicated in the executable), as it does not appear to be connected to anything in A2. Unfortunately the command appears identical in Battlezone, so I am not sure it will have utility in A1/A2, unlike isUpgrade which does not appear in Battlezone and seems to be specially created for A1.

Currently seems to change only the following for the Producer in A2:
-maxHealth (and not maxShields -> if maxHealth is default, hull hitpoints become inherited as 0 and shield hitpoints are unchanged from the original of the Producer)
'upgrade' flag in a ResearchStation has no effect, and all integer values of isUpgrade 1 and greater have the same effect as one another. The last ResearchPod to be built will create the inherited effect, which can be reverted by researching another ResearchPod etc. If another ResearchPod with isUpgrade is built, it detaches the previous one (although it still remains in game, yet does not effect the crash scanrange bug).
The rangescan for at least A2 is actually a property of the researchPod and not the Producer.
I tested maxhealth,maxshields,shieldrate,healthrate,rangescan,maxspecialenergy, hidden,shieldpad, maximumcrew,crewcost to see if there were any additional effects before getting lazy.
I've never been able to successfully test things out in A1 due to my graphics card, so hopefully you can find some extra functionality with 'upgrade' (which also seems to be duplicated in the executable), as it does not appear to be connected to anything in A2. Unfortunately the command appears identical in Battlezone, so I am not sure it will have utility in A1/A2, unlike isUpgrade which does not appear in Battlezone and seems to be specially created for A1.
posted on September 15th, 2012, 11:40 am
One thing I did notice late last night was that if you decommision the research station with the upgrade pod applied the game crashed. I was tired but I repeated the process several time and eaxh time it crashed. Not sure if you are seeing that in A2 or not. 

posted on September 15th, 2012, 11:37 pm
Yup, I noted that in a previous post
The crash seems to be a result of referencing the destroyed researchpod when updating the scanner. You can get around this in Fleet Ops (without requiring a separate bug fix) by having a short lifetimer on the researchpod
. Unfortunately I don't think there is anyway of doing something similar in A1 or stock A2...

Dominus_Noctis wrote:[...]When the producer is destroyed prior to the pod's destruction, A2 crashes as well. [...]
The crash seems to be a result of referencing the destroyed researchpod when updating the scanner. You can get around this in Fleet Ops (without requiring a separate bug fix) by having a short lifetimer on the researchpod

posted on September 16th, 2012, 4:54 am
Judging by some of the unused icons, I think the original idea was for there to be a single research station for each race that would then be upgraded to have more pods, rather than having two stations. Maybe the original version of the line was meant to be used to upgrade research stations?
posted on September 16th, 2012, 10:56 pm
Very suprised that this actually worked. Thanks for taking the time to try this one out. I've been looking at it for some time, but never really bothered to test it properly.
What was the result? Were these being upgraded with the pod?
My guess is that any ship/station is just an instance of a particular class of game object (wingman for ships for example). Each instance comes with its own properties which are set in the ODFs. Theoretically, any one of those properties should be upgradable.
Being able to upgrade research stations to have weapons, or change the podHardpoints (ei, give a larger number) would be pretty awesome.
Something I noticed is that the upgrade has craft AI: aiName = "CraftProcess"
where as pods have aiName = "StarbaseProcess". Maybe that has no relevance here, not sure.
Dominus_Noctis wrote: I tested maxhealth,maxshields,shieldrate,healthrate,rangescan,maxspecialenergy, hidden,shieldpad, maximumcrew,crewcost to see if there were any additional effects before getting lazy.
What was the result? Were these being upgraded with the pod?
My guess is that any ship/station is just an instance of a particular class of game object (wingman for ships for example). Each instance comes with its own properties which are set in the ODFs. Theoretically, any one of those properties should be upgradable.
Being able to upgrade research stations to have weapons, or change the podHardpoints (ei, give a larger number) would be pretty awesome.
Something I noticed is that the upgrade has craft AI: aiName = "CraftProcess"
where as pods have aiName = "StarbaseProcess". Maybe that has no relevance here, not sure.
posted on September 17th, 2012, 12:14 am
With just those few commands tested, only maxHealth is inherited by the Producer for A2. I'm guessing that the other commands I didn't test won't be inherited as well.
Yup, the aiProcess here doesn't seem to change anything and isn't inherited by the Producer as far as I can tell. Just tested weapon and target hardpoints, weapons and those weren't inherited either.
Yup, the aiProcess here doesn't seem to change anything and isn't inherited by the Producer as far as I can tell. Just tested weapon and target hardpoints, weapons and those weren't inherited either.
posted on September 18th, 2012, 2:17 am
...and seems this is a bit of a dead end. Did some talking with Doca, and Armada apparently sets most of these values globally, so they can't be changed for FO without significant effort. Probably the only command that's inheritable in stock A1/A2 is maxHealth after all.
posted on September 19th, 2012, 12:18 am
Well at least we gave it a good run. I am suprised we made as much progress as we did.
posted on October 13th, 2012, 4:53 am
Question as I got lost a little in the code lol: Does this mean a ship/station can have a upgrade to it, like upgrade its systems or stats?
posted on October 13th, 2012, 6:35 am
Yes and no: for stock A2/A1 it means a researchStation can inherit the maxHealth of the upgrade pod. I tested now over 50 gameObject commands and maxHealth was the only one inherited. It's quite likely this was an early attempt at creating what became the global upgrade system for A2.
1, 2
Reply
Who is online
Users browsing this forum: No registered users and 1 guest