24.July 2016 - Miscellaneous IZ Combat Tweaks updated to v0.70
Tentative fix for situation where movement coordinates could become invalid when combat crosses zone boundaries in between two or more consecutive move actions.
Thanks to Scoob for the detailed description of the issue.
...
Please note that this fix is tentative because I have been unable to reproduce this issue, so cause might be different from my best guess. If anyone encounters the problem described in this post:
http://forum.egosoft.com/viewtopic.php? ... 00#4621800
with MICT v0.70+, please let me know.
[MOD] Miscellaneous IZ Combat Tweaks
Moderators: Moderators for English X Forum, Scripting / Modding Moderators
Thanks for the update w.e, I'll test and monitor my ships behaviour.
Quick observation, not related to the above tweak I think.
I just took a "Xenon targeting this Station" mission. A Xenon K appears in the Zone - I assume boosting in - and my Light Sul (with me on board) jumps to engage. However, the K did a short boost its self, I assume to get closer to its intended target, which left my Light Sul off a little bit.
My Light Sul then announces it's boosting to the Xenon K, but it doesn't attempt to turn first. As a result, my Light Sul is performing a long, lazy Arc while boosting....though it's not reaching the usual full boost speed. It's actually getting slightly further away from the target, as it's not able to turn quite sharp enough.
I have seen this sort of behaviour before, but only in much earlier MICT versions. So, the Jumping behaviour was perfect, though the target moved after the jump count-down had started it appears. The boosting to the Xenon K (what the Captain said he was doing) is also as expected, but not him failing to turn first. My Light Sul ideally needed to do a full 180 degree turn prior to boosting.
All this happening with both my Light Sul and the Xenon K in the same Zone to be clear.
Thought: I think a degree of station avoidance is occurring, hence the odd flight path.
Edit: My Slight Sul did eventually get nearer to the Xenon K, but not within weapons range. Oddly it's path was not along a flat plane, rather my Light Sul while originally diving then proceeded to pull up again while executing this long turn. However, after pulling up it stopped turning, and flew straight....the Xenon K was then killed by NPC's. If my Light Sul had continued to turn, it would have been able to engage the target, so why it straightened up I don't know...it was well out of range of any stations by that point.
So, a bit of an anomaly there, but I'll check combat behaviour once again when I am able.
Scoob.
Quick observation, not related to the above tweak I think.
I just took a "Xenon targeting this Station" mission. A Xenon K appears in the Zone - I assume boosting in - and my Light Sul (with me on board) jumps to engage. However, the K did a short boost its self, I assume to get closer to its intended target, which left my Light Sul off a little bit.
My Light Sul then announces it's boosting to the Xenon K, but it doesn't attempt to turn first. As a result, my Light Sul is performing a long, lazy Arc while boosting....though it's not reaching the usual full boost speed. It's actually getting slightly further away from the target, as it's not able to turn quite sharp enough.
I have seen this sort of behaviour before, but only in much earlier MICT versions. So, the Jumping behaviour was perfect, though the target moved after the jump count-down had started it appears. The boosting to the Xenon K (what the Captain said he was doing) is also as expected, but not him failing to turn first. My Light Sul ideally needed to do a full 180 degree turn prior to boosting.
All this happening with both my Light Sul and the Xenon K in the same Zone to be clear.
Thought: I think a degree of station avoidance is occurring, hence the odd flight path.
Edit: My Slight Sul did eventually get nearer to the Xenon K, but not within weapons range. Oddly it's path was not along a flat plane, rather my Light Sul while originally diving then proceeded to pull up again while executing this long turn. However, after pulling up it stopped turning, and flew straight....the Xenon K was then killed by NPC's. If my Light Sul had continued to turn, it would have been able to engage the target, so why it straightened up I don't know...it was well out of range of any stations by that point.
So, a bit of an anomaly there, but I'll check combat behaviour once again when I am able.
Scoob.
You mentioned diving. Would the Sul have had to pitch rather steeply on the y-axis to orient properly? That could be causing the problem.
Capital ships (used to be all, since a recent change, most) have a limit to how much they can pitch up or down. However, they don't know that when they start moving, so they try anyway, and just can't. Behavior is as you described: they start turning, then stop, and sort of wobble, turn back, or in really bad cases, start spinning like tops. It's the same problem the Sucellus used to sometimes have orienting to the target.
Could also account for not turning before boost. They had already turned as much as they can, then start moving while trying to continue to turn as much as they can, but can't.
They should recover, but yeah, it might take some time. (Seconds to start to recover, but that might still be too long, as you noticed.)
Capital ships (used to be all, since a recent change, most) have a limit to how much they can pitch up or down. However, they don't know that when they start moving, so they try anyway, and just can't. Behavior is as you described: they start turning, then stop, and sort of wobble, turn back, or in really bad cases, start spinning like tops. It's the same problem the Sucellus used to sometimes have orienting to the target.
Could also account for not turning before boost. They had already turned as much as they can, then start moving while trying to continue to turn as much as they can, but can't.
They should recover, but yeah, it might take some time. (Seconds to start to recover, but that might still be too long, as you noticed.)
Depends on where it wanted to go. You mentioned it was approaching to attack? i seem to remember the Light Sul having most (if not all) of its turrets on top. So it likely would've wanted to get underneath the K. If it was on top of the K before it started moving, it would've had to pitch almost straight down before starting to boost, which it can't.
Unless, hmm. Unless it was trying to turn upside down and stay above the K. The top is the K's weak spot, if i remember correctly. That would be problematic since capships can't turn upside-down.
Will have to think about that because even if that wasn't the cause of this particular case, it is a case that could arise.
Is the problem serious enough that i have to come up with a quick fix before fixing it properly? Or could i take my time on this one?
Unless, hmm. Unless it was trying to turn upside down and stay above the K. The top is the K's weak spot, if i remember correctly. That would be problematic since capships can't turn upside-down.
Will have to think about that because even if that wasn't the cause of this particular case, it is a case that could arise.
Is the problem serious enough that i have to come up with a quick fix before fixing it properly? Or could i take my time on this one?
Regarding Scoob's last report, good news and bad news.
Good news: MICT ships don't try to fly upside-down relative to their target.
Bad news: I have no idea what happened.
They do look at whether their target's upper or lower side has the most firepower and try to go slightly above or below their target accordingly while maintaining front/right/left orientation depending on where the MICT ship has the most firepower, but top/down does not affect their orientation.
I still think pitch is the most likely culprit but, in the case described, the Sul should have tried to stay above the K if anything since that's the K's weak point. Save would be great, but I'm not keeping my hopes up. I do know that it's hard to get a save right before this happens because what they actually do can change. But if anyone happens to have a save right before a ship does something like what Scoob described, would help greatly in tracking this down.
Good news: MICT ships don't try to fly upside-down relative to their target.
Bad news: I have no idea what happened.
They do look at whether their target's upper or lower side has the most firepower and try to go slightly above or below their target accordingly while maintaining front/right/left orientation depending on where the MICT ship has the most firepower, but top/down does not affect their orientation.
I still think pitch is the most likely culprit but, in the case described, the Sul should have tried to stay above the K if anything since that's the K's weak point. Save would be great, but I'm not keeping my hopes up. I do know that it's hard to get a save right before this happens because what they actually do can change. But if anyone happens to have a save right before a ship does something like what Scoob described, would help greatly in tracking this down.
Hi w.e.
Another bit of odd combat behaviour to report.
I ordered my Arawn to Patrol a Zone which contained an enemy (REI) Outpost from the CWIR mod. My Arawn made short work of all three Targon Tracers, the stations Radar and the section that linked the Radar to the main station body. However, while it attacked surface elements of the main station body, it's not firing now to try to finish it off. Ship is in range of this part of the station, but is not shooting.
Note: Arawn jumped to a point underneath said station and engaged from there, possibly isn't trying to get to a point where it can engage the stations remaining surface elements - which are on top of the station?
Interestingly, my Arawn pitches UP quite a lot, as if it's about to fly to a position where it can engage said upper surface elements. However, no sooner does it hit about 70 degrees of pitch (perfect for fly to a good position incidentally) does it then pitch down again, until it's flat. It does appear to rotate a bit at (seemingly) random too.
Over 10 minutes have passed, yet my Arawn hasn't really moved, just pitched & rotated on the spot. I get the weird ones, don't I?
Btw: my ships have engaged Outposts without issue in the past - this one is surrounded by asteroids, so maybe just getting confused?
Update: I forced my Arawn, via abusing the "Withdraw" command, to get slightly above the Outpost, and it starting firing again right away.
Scoob.
Another bit of odd combat behaviour to report.
I ordered my Arawn to Patrol a Zone which contained an enemy (REI) Outpost from the CWIR mod. My Arawn made short work of all three Targon Tracers, the stations Radar and the section that linked the Radar to the main station body. However, while it attacked surface elements of the main station body, it's not firing now to try to finish it off. Ship is in range of this part of the station, but is not shooting.
Note: Arawn jumped to a point underneath said station and engaged from there, possibly isn't trying to get to a point where it can engage the stations remaining surface elements - which are on top of the station?
Interestingly, my Arawn pitches UP quite a lot, as if it's about to fly to a position where it can engage said upper surface elements. However, no sooner does it hit about 70 degrees of pitch (perfect for fly to a good position incidentally) does it then pitch down again, until it's flat. It does appear to rotate a bit at (seemingly) random too.
Over 10 minutes have passed, yet my Arawn hasn't really moved, just pitched & rotated on the spot. I get the weird ones, don't I?
Btw: my ships have engaged Outposts without issue in the past - this one is surrounded by asteroids, so maybe just getting confused?
Update: I forced my Arawn, via abusing the "Withdraw" command, to get slightly above the Outpost, and it starting firing again right away.
Scoob.
Sounds like the old problem with fighting stations: it can't shoot through wrecks and, while they should stay within range of the station module they're shooting at, haven't found a way to make sure that their view of the station module isn't obstructed. Not really happy with this, but find that it works often enough to not necessitate a fix. It should be better now though since they'll work from the outside of the onion in.
Workaround is what you did: essentially just order it to attack the station again, and it should plot a course to a different position.
Except:
Workaround is what you did: essentially just order it to attack the station again, and it should plot a course to a different position.
Except:
this sounds like the movement is being interrupted, or the same old pitch problem. That, or the particular module they were targeting was destroyed and they've targeted a new one. In general, if they turn, they should do something: move, hold position after aiming. If they turn, then fidget like that, usually means that the movement was interrupted, or that it failed. Interruptions can be normal. Failure is usually due to the pitch problem.Scoob wrote:Interestingly, my Arawn pitches UP quite a lot, as if it's about to fly to a position where it can engage said upper surface elements. However, no sooner does it hit about 70 degrees of pitch (perfect for fly to a good position incidentally) does it then pitch down again, until it's flat. It does appear to rotate a bit at (seemingly) random too.
Heh. Don't know how you feel about that, but I, for one, appreciate your telling me about them!Scoob wrote:I get the weird ones, don't I?
What makes this one extra odd, is that my ship wasn't trying to shoot through anything, the remaining module was there, fully LoS exposed, just not being shot at. The surface elements on this final station module had been taken out easily on the under-side, my ship just refused to shoot at the hull from this angle.
Once level/slightly above the remaining module, the ship shot it just fine - for the most part. However, I noticed a couple of my turrets seemed to be aiming above the station module, causing the shots to miss and fly past harmlessly - might indicate some issue with the model, I'll monitor future attacks on Outposts. Enough shots did hit to take the station down though finally.
Happy to share
Scoob.
Once level/slightly above the remaining module, the ship shot it just fine - for the most part. However, I noticed a couple of my turrets seemed to be aiming above the station module, causing the shots to miss and fly past harmlessly - might indicate some issue with the model, I'll monitor future attacks on Outposts. Enough shots did hit to take the station down though finally.
Happy to share
Scoob.
Hey w.e.
I was wondering if you'd consider making aspects of MICT configurable via a file to allow fine-tuning of behaviours?
For example, if I wanted my Split Captains to NEVER retreat, or my Argon ones to only return to a fight once their shields are at 60% I'd be able to set that.
How about other features, such as retreat behaviour, Boost & Jump, Boost only etc. or allowing capital ships to boost to a Fighter group, rather than normal flight.
Having separate configs by Captain Race, and even skill level, would enable the player to tweak fleet behaviour further.
I know I could likely change the scripts myself to customise behaviour, but having it in a single config file would be great for dummies like me.
Just a thought, no worries if it's not something you want to do
Scoob.
I was wondering if you'd consider making aspects of MICT configurable via a file to allow fine-tuning of behaviours?
For example, if I wanted my Split Captains to NEVER retreat, or my Argon ones to only return to a fight once their shields are at 60% I'd be able to set that.
How about other features, such as retreat behaviour, Boost & Jump, Boost only etc. or allowing capital ships to boost to a Fighter group, rather than normal flight.
Having separate configs by Captain Race, and even skill level, would enable the player to tweak fleet behaviour further.
I know I could likely change the scripts myself to customise behaviour, but having it in a single config file would be great for dummies like me.
Just a thought, no worries if it's not something you want to do
Scoob.
Hi again,
A minor issue I've spotted with a MICT crew vs. the new Xenon Outpost in CWIR...
The CWIR Xenon Outposts have a large central sphere, a MICT controlled ships fire seems to be drawn to this, even once it's been destroyed.
I've observed attacks from all angles, yet this central sphere remains the target.
Saving my game during an attack on an outpost exhibiting this behaviour, removing MICT then reloading, sees my ship target other station components right away.
Note: During the initial attack, my ships will often strip a few surface elements that they have LoS on, but are quickly distracted by the central sphere.
I recall you've done work in the past to ensure MICT works well vs. normal CWIR Outposts used by the races. However, the Xenon one is fairly new, so needs a little tweaking attack-wise.
Cheers,
Scoob.
A minor issue I've spotted with a MICT crew vs. the new Xenon Outpost in CWIR...
The CWIR Xenon Outposts have a large central sphere, a MICT controlled ships fire seems to be drawn to this, even once it's been destroyed.
I've observed attacks from all angles, yet this central sphere remains the target.
Saving my game during an attack on an outpost exhibiting this behaviour, removing MICT then reloading, sees my ship target other station components right away.
Note: During the initial attack, my ships will often strip a few surface elements that they have LoS on, but are quickly distracted by the central sphere.
I recall you've done work in the past to ensure MICT works well vs. normal CWIR Outposts used by the races. However, the Xenon one is fairly new, so needs a little tweaking attack-wise.
Cheers,
Scoob.
Apologies, these posts are gonna look a bit spammy when you see them!
Anyway, something else I've noticed which I assume is linked to the MICT movement scripts - specifically when a ship is in formation with another...
I have a Taranis with two sub-ordinate Taranis. I order the lead ship to Patrol a neighbouring Zone, and it turns to face the target Zone just fine. However, where the lead ship should now boost at this point, to be followed by its subordinates, the two subordinate ships - even though they've not oriented themselves in the right direction yet - boost before their leader. This then confuses the leader, who, despite being perfectly oriented on the target Zone, goes into so sort of avoidance thing.
Basically, this leads to the group of ships not actually getting to the target Zone promptly, as the leader is stuck avoiding the subordinates, which are stuck boosting....well, the effect is showing, but they appear to be stuck until the leader finally flies off.
Not a huge deal, but it does regularly delay movements of small fleets - considering I tend to be sat on the bridge of the lead ship, this is likely a "player in-Zone" type issue only.
Anyway, if the subordinate ships weren't boosting prematurely, the lead ship would have been able to boost just fine, as it was correctly oriented.
Scoob.
Anyway, something else I've noticed which I assume is linked to the MICT movement scripts - specifically when a ship is in formation with another...
I have a Taranis with two sub-ordinate Taranis. I order the lead ship to Patrol a neighbouring Zone, and it turns to face the target Zone just fine. However, where the lead ship should now boost at this point, to be followed by its subordinates, the two subordinate ships - even though they've not oriented themselves in the right direction yet - boost before their leader. This then confuses the leader, who, despite being perfectly oriented on the target Zone, goes into so sort of avoidance thing.
Basically, this leads to the group of ships not actually getting to the target Zone promptly, as the leader is stuck avoiding the subordinates, which are stuck boosting....well, the effect is showing, but they appear to be stuck until the leader finally flies off.
Not a huge deal, but it does regularly delay movements of small fleets - considering I tend to be sat on the bridge of the lead ship, this is likely a "player in-Zone" type issue only.
Anyway, if the subordinate ships weren't boosting prematurely, the lead ship would have been able to boost just fine, as it was correctly oriented.
Scoob.
Hey Scoob,
sorry for the long delay. Been a bit crazy here.
The retreat thresholds are a bit harder to find, and are in the conditions for the retreat actions themselves. Could move those up as well.
And all of these things could be moved to a separate configuration file, but I don't see much advantage in having a separate file vs having them at the top of the file. Hm, unless other configuration options are added impacting different behaviors. Could be tricky having all options for the different behaviors in one file though since the mod's modular.
Re: station assault, all of the station's modules and surface elements are just added to the turrets' target list. Which they fire on depends on which are in line of sight and are in range of each individual turret. That's done in the code though. In script, we could only control what's in the target list. So, for example, we could control whether or not that central sphere is fired on at all in addition to other things, but not when that sphere is fired upon.
By the way, what's shown as target in the ship's display (on the event monitor) is what the captain is maneouvering relative to. It does not show what the defence officer is firing at.
Re: movement to neighboring zone, thanks. Hmm. Right now, the moment a leader decides to go somewhere, he/she sends a signal to all of his/her subordinates to go there, and they go separately. What's odd is their firing their boosters immediately since it's the same turn-then-boost movement to the same location. Will take a look. Offhand, can't see why the leaders movement would be different from the subordinates'. At that point, they'll be running the exact same script with the same parameters!
sorry for the long delay. Been a bit crazy here.
Should already be relatively simple to configure. The combat target distances and thresholds are all at the very top of aiscripts\MICT.move.attack.object.capital. Allowing boost and allowing jump are a bit further in, but could be deactivated with a simple switch from "true" to "false". Guess could move those up so that everything's in one place.Scoob wrote:I was wondering if you'd consider making aspects of MICT configurable via a file to allow fine-tuning of behaviours?
The retreat thresholds are a bit harder to find, and are in the conditions for the retreat actions themselves. Could move those up as well.
And all of these things could be moved to a separate configuration file, but I don't see much advantage in having a separate file vs having them at the top of the file. Hm, unless other configuration options are added impacting different behaviors. Could be tricky having all options for the different behaviors in one file though since the mod's modular.
Re: station assault, all of the station's modules and surface elements are just added to the turrets' target list. Which they fire on depends on which are in line of sight and are in range of each individual turret. That's done in the code though. In script, we could only control what's in the target list. So, for example, we could control whether or not that central sphere is fired on at all in addition to other things, but not when that sphere is fired upon.
By the way, what's shown as target in the ship's display (on the event monitor) is what the captain is maneouvering relative to. It does not show what the defence officer is firing at.
Re: movement to neighboring zone, thanks. Hmm. Right now, the moment a leader decides to go somewhere, he/she sends a signal to all of his/her subordinates to go there, and they go separately. What's odd is their firing their boosters immediately since it's the same turn-then-boost movement to the same location. Will take a look. Offhand, can't see why the leaders movement would be different from the subordinates'. At that point, they'll be running the exact same script with the same parameters!
20.August 2016 - Miscellaneous IZ Combat Tweaks updated to v0.71
Settings to configure capital ship combat movement added to the top of aiscripts\MICT.move.attack.object.capital.
Thanks to Scoob for the suggestion.
...
Configuration options are as follows:
Distance targets and thresholds for long ranged-ships:
Distance targets and thresholds for ships with very large drone capacities:
Distance targets and thresholds for destroyers:
Escape distance targets:
Switches to allow/disallow jump and boost in combat:
Retreat shield thresholds:
Approach shield thresholds:
Settings to configure capital ship combat movement added to the top of aiscripts\MICT.move.attack.object.capital.
Thanks to Scoob for the suggestion.
...
Configuration options are as follows:
Distance targets and thresholds for long ranged-ships:
Code: Select all
<do_if value="this.ship.macro.ismacro.{global.$MICT_LR_Ships}">
<set_value name="$MICT_MaxAimDist" exact="this.ship.maxcombatrange.all"/>
<set_value name="$MICT_MinAimDist" exact="this.ship.maxcombatrange.all * 0.5f"/>
<set_value name="$MICT_MaxJumpDist" exact="this.ship.maxcombatrange.all * (1.9f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinJumpDist" exact="this.ship.maxcombatrange.all * (0.3f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
<set_value name="$MICT_MaxShortAimDist" exact="3570m * (2.0f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinShortAimDist" exact="3570m * (0.1f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
</do_if>Code: Select all
<do_elseif value="this.ship.units.maxcount gt 300 and this.ship.availableunits.{unitcategory.defence}.count gt 0">
<set_value name="$MICT_MaxAimDist" exact="8000m"/>
<set_value name="$MICT_MinAimDist" exact="8000m * 0.5f"/>
<set_value name="$MICT_MaxJumpDist" exact="8000m * (1.9f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinJumpDist" exact="8000m * (0.3f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
<set_value name="$MICT_MaxShortAimDist" exact="3570m * (2.0f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinShortAimDist" exact="3570m * (0.1f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
</do_elseif>
<do_elseif value="this.ship.maxcombatrange.turrets lt 7200">
<set_value name="$MICT_MaxAimDist" exact="this.ship.maxcombatrange.turrets"/>
<set_value name="$MICT_MinAimDist" exact="this.ship.maxcombatrange.turrets * 0.15f"/>
<set_value name="$MICT_MaxJumpDist" exact="this.ship.maxcombatrange.turrets * (1.5f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinJumpDist" exact="this.ship.maxcombatrange.turrets * (0.1f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
<set_value name="$MICT_MaxShortAimDist" exact="3570m * (2.0f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinShortAimDist" exact="3570m * (0.1f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
</do_elseif>Code: Select all
<do_else>
<set_value name="$MICT_MaxAimDist" exact="this.ship.maxcombatrange.turrets"/>
<set_value name="$MICT_MinAimDist" exact="this.ship.maxcombatrange.turrets * 0.3f"/>
<set_value name="$MICT_MaxJumpDist" exact="this.ship.maxcombatrange.turrets * (1.8f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinJumpDist" exact="this.ship.maxcombatrange.turrets * (0.25f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
<set_value name="$MICT_MaxShortAimDist" exact="3570m * (2.0f - ((this.skill.navigation + this.skill.morale)f / 10.0f))"/>
<set_value name="$MICT_MinShortAimDist" exact="3570m * (0.1f * (1.0f + (1.0f * ((this.skill.navigation + this.skill.morale)f / 10.0f))))"/>
</do_else>Code: Select all
<do_if value="$target.container.exists">
<set_value name="$MICT_MaxEscapeJumpDist" exact="($target.container.maxcombatrange.all + $target.size) * (1.0f + ((this.combinedskill)f / 100.0f))"/>
<set_value name="$MICT_MinEscapeJumpDist" exact="($target.container.maxcombatrange.all + $target.size) / (1.9f - ((this.combinedskill)f / 100.0f))"/>
</do_if>
<do_else>
<set_value name="$MICT_MaxEscapeJumpDist" exact="($target.maxcombatrange.all + $target.size) * (1.0f + ((this.combinedskill)f / 100.0f))"/>
<set_value name="$MICT_MinEscapeJumpDist" exact="($target.maxcombatrange.all + $target.size) / (1.9f - ((this.combinedskill)f / 100.0f))"/>
</do_else>Code: Select all
<set_value name="$AllowJump" exact="true"/>
<set_value name="$AllowBoost" exact="true"/>Code: Select all
<set_value name="$ShieldPercentage_RetreatThreshold_Argon" exact="0.2"/>
<set_value name="$ShieldPercentage_RetreatThreshold_Split" exact="0.0"/>
<set_value name="$ShieldPercentage_RetreatThreshold_Teladi" exact="0.4"/>Code: Select all
<set_value name="$ShieldPercentage_ApproachThreshold_Argon" exact="0.4"/>
<set_value name="$ShieldPercentage_ApproachThreshold_Split" exact="0.1"/>
<set_value name="$ShieldPercentage_ApproachThreshold_Teladi" exact="0.8"/>
for anyone who got problems with high Pitch Values consider trying this Mod - it removes all Angular limitations (pitch limit) for all Ships, so they can turn completely free. This might Synergize good with w.evans Changes (will be part of my Manager/(fleet managment) Script in the future, but i am currently working on a bigger change (seperating everything in diffrent packages), so a new Version could still take a few weeks - but this part can be used individually anyway, so making it a pre-release here, too ^^
https://www.dropbox.com/s/junfqsjl8nfxc ... on.7z?dl=1
https://www.dropbox.com/s/junfqsjl8nfxc ... on.7z?dl=1
if not stated otherwise everything i post is licensed under WTFPL
Ich mache keine S&M-Auftragsarbeiten, aber wenn es fragen gibt wie man etwas umsetzen kann helfe ich gerne weiter
I wont do Script&Mod Request work, but if there are questions how to do something i will GLaDly help
Ich mache keine S&M-Auftragsarbeiten, aber wenn es fragen gibt wie man etwas umsetzen kann helfe ich gerne weiter
I wont do Script&Mod Request work, but if there are questions how to do something i will GLaDly help
-
Nemesis_87
- Posts: 730
- Joined: Sat, 19. Mar 11, 16:26
