[MOD] Miscellaneous IZ Combat Tweaks

[Marvin Martian]

edit: forgot:

also it might be better not jump/boost/move around and stay in position as long as possible but always nose straight to main-target

At the moment, this is set to <set_value name="$MICT_MinAimDist" exact="this.ship.maxcombatrange.all * 0.5f"/>

If MOCT_supp3 is installed, Sucellus IHC range is 18,000m bringing bug-out range to 9,000m, which is excessive. That gives you a 1km buffer before anything other than a Balor's torpedoes come into play.

However, set it to that because if someone does not have MOCT_supp3, IHC range drops down to 8km, and bug-out range is then 4km. Well into JET/MA range, and coming into Plasma/MA range. Could fix it to a particular distance, but then it won't work very well for something like your Cerberus which uses that behavior but at a closer range.

Effectively, compromise is between modularity, compatibility with any other mods, and absolute effectiveness.

Think it's an ok compromise for now, but am open to suggestions.

i take a closer look for this into the script

i think the main-"problem" is, that the fight is one big while
so you can't work with label and resume for to do what you need instead of whats next, so the movement process will be done always, and like i said in the other thread, sometimes the enemy come close for a good fight, but the ship is processing a movement to a position that outdated long ago

then i found some Aimvectors that only used from non-LR ships, that may be the reason why the LR ship often jump/boost on top of the enemy, mainweapon direction straight into nowhere

now it works like
you positioning the LR ship at start - so far so good, but then the the movement-actions beginning and the LR ship never gets really placed against the target into a good position again

i know to change that skript now is a problem, but i had used more label and resume-label to process movements, do wait actions, calculate postions and so on

maybe it might be possible to add a own section lable name=lrfight in front of the "label fight"-while for LR ships that only positioning look_at target and do only wait, if nothing happend resume that, don't move, otherwise resume-fight to process movements

you could do that also with more do_if/else/elsif stuff inside the while but that makes more redundant code and isn't necessary

[w.evans]

Miscellaneous IZ Combat Tweaks is unfortunately broken as of X Rebirth 4.0 Beta 6 due to extensive changes in the vanilla AI scripts.

I do not know when I will be able to find the time to fix it. When I do (and I fully intend to), I will announce it on this thread.

In the meantime, if you are running the beta, you can simply safely uninstall this mod. If you think you still might be interested in it in the future, simply stay subscribed to this thread so that you don't miss the announcement.

[w.evans]

then i found some Aimvectors that only used from non-LR ships, that may be the reason why the LR ship often jump/boost on top of the enemy, mainweapon direction straight into nowhere

I think I found the problem. It's MICT_Target_AimVector_Vert. For some strange reason that I can no longer remember I have that set to quadrant.up for LR ships, where they shouldn't have a direction2 at all (so that they'll be pointing straight on target.) Working on a fix, and a general fix for MICT and MOCT with 4.0.

now it works like
you positioning the LR ship at start - so far so good, but then the the movement-actions beginning and the LR ship never gets really placed against the target into a good position again

Actually rather pleased with myself regarding the solution to that problem. Problem was I needed an orientation from where the ship was going, and I needed it before the ship goes there because it has to be plugged into the movement itself. (That way, ships end their movement already in the correct orientation.) Problem is, there is no object where they're going, so I can't plot an orientation from that position. Solution was to draw a line from the target to the target position, and have the ship look away from that orientation. Works pretty well except for that MICT_Target_AimVector_Vert thing that I added in later.

I'm trying to remember why I added MICT_Target_AimVector_Vert for LR ships though. I think I intended it to be used against fighters, because it checks vertical turret placement, then I forgot and used it for movement against everything.

edit: just remembered: MICT_Target_AimVector_Vert checks the target's turret placement! Was designed so that ships move off the ecliptic and into the vertical position relative to their target that is least defended. Bias towards going under opposing capships because that's where jump drives usually are.

Hm, and I'm back where I started.

[w.evans]

Been looking into getting MICT working with 4.0 which looks like it might go release soon since it's in RC1. As far as I can tell, there are only really two problems with it, and I'd like some opinions on how to proceed.

.......
PROBLEM 1: Balor torpedo launch and capship drone launch control.

They were set to use the ammo and drone resupply tickboxes in the Defence Officer's details because those boxes didn't do anything for capship-based DOs before. Now, they were correctly removed by Ego.

Option 1: learn lua and write in menu options to activate these options. (proper way to go, but may take a very very long time depending on how much time I can put in (and motivate myself to putting in!) plus the supply of bat tongue and lizard ear hairs is rather low in town at the moment.)

Option 2a: tie them to the Defence Officers' attack/defend setting.
Problems:
- you will no longer be able to set a Defence Officer to attack without also authorizing drone/torpedo usage
- DO attack/defend setting is set in MICT to be passed on to the whole squadron, and it is sometimes a good idea to hold off on launching torpedoes but have the rest of the squadron attack. - make an exception for Balors?

Option 2b: tie them to the Defence Officer attacking, regardless of explicit "Attack" / "Defend" setting. (as described in Sparky's post immediately below this one)

Option 3: allow them to fire torpedoes and launch combat drones all the time.

Personally, I prefer Option 2 because I can do it right now with minimum fuss while still giving the player a bit of control over when they fire. Can do it in such a way that Option 1 can later be shoe-horned in if we ever get to that.

Option 3 is easiest, of course, but makes Balors somewhat dangerous.

Another possibility is to do Option 2 for torpedoes and Option 3 for drone use.

.......
PROBLEM 2: Station-based drone launch (MICT_supp4, for those of you who went the modular Nexus route).

Stations launch combat drones in the 4.0 beta; and since it appears to be working fine, I don't expect that to change. However, how Ego treated drone launch is very different to how it is treated in MICT.

Option 1: retire MICT's station-based drone launch stuff.

Option 2: suppress Ego's station-based drone launch stuff.

That's it. Afraid I don't see a middle ground to this. For those of you who are using the Nexus version of the mod, this will stay in MICT_supp4, of course.

Which opens up a possibility: Option 2 for Nexus and Option 1 for Steam Workshop? (I'm pretty sure that those of you who get the mod from the Steam Workshop can then just drop MICT_supp4 from the Nexus into your extensions folder and it'll work as a sort of MCT+. You'll have to keep the file from the Nexus updated manually or use the Nexus Mod Manager though.)

[Sparky Sparkycorp]

Posting at the risk of misunderstanding the conundrum through a rusty memory.

The DO setting of "Attacking Enemies" or "Defending" doesn't change in the ship Detail Menu when the Captain is ordered to attack something. Within the DO Detail Page that isn't the case as a Defending DO on an attacking ship still adopts "Attack Enemies. Attacking.".

Is there any chance that you could use that dichotomy as a fix for Problem 1 for the Balor (maybe drones too)?

a) DO set to "Attacking Enemies": Balor uses missiles at all times.
b) DO set to "Defending" and following an Attack order*: As above.
c) DO set to "Defending" and ship isn't attacking: No missiles.

* Maybe also when it's Commander's DO is set to "Attacking Enemies".

I'm not sure about the other Problem 2. Although you're very supportive of modularity, I'm inclined to think that if you would personally be happy with vanilla drone usage by stations in your game, that is probably reason to go with option 1. Or perhaps to consider a separate mod for Problem 2 based around adapting the Ego implementation if that more desirable than option 2.

[pref]

Hey!

I was tampering with a certain MICT.move.escort.capital script (and its version modified by BR for CWIR).
I had some concerns about what happens with attention change and already selected enemies. So for ex in order to be able to enter the attack phase (keeping on target would be important for my changes) there are different variables that need to be set properly (IZ this.$goattack and $enemy, OOZ $MICT_OOZ_SquadAttack and $MICT_OOZ_Enemy).

Is there any special action needed to handle seamless attention change?
Is adding a handler necessary that sets up the variables according to attention and jumps back to the fight label?
Or this is taken care of somehow internally via a process i have no idea about?

Could you do tests with attention change? I find it hard to trigger in just the right moment(s) so that it can cause trouble.

Sorry for OT, this thread seemed the most relevant.

[w.evans]

hey pref,

as far as I could tell, upon attention change:

it runs as normal until it gets to the bottom of the current section of the script, then resumes at the appropriate section.
In cases of:

Code: Select all

<attention min="visible">
...
<attention min="unknown">

if moving from high -> low attention, the first section runs to the end and it simply continues to the second section.

If moving from low -> high, the second section runs to the end then begins again in the first section.

If you had something like:

Code: Select all

<attention min="unknown">
...
<attention min="visible">

not sure if you'd just have to go through everything in unknown, then run the stuff in visible only if in visible attention or greater, or if the high attention part would never run.

Now that I'm writing this though, I'm starting to have doubts. That particular script you mentioned, like the vanilla script it was built upon, has a do_while in the high attention section and the conditions for that loop don't negate when you go to low attention. Suspect that attention level is checked after every blocking action and, if no longer true, continue as appropriate.

You could control it more by having, say, an interrupt handler that checks for attention change, but can't think of a use for it in flow control that would result in things being better.

ps. if you were to simply change all instances of $MICT_OOZ_Enemy to $enemy, I think that it won't switch enemies upon attention change because the variable would already be set.

pps. Thanks, Sparky.

[pref]

Thanks!

The script is looped for both attention levels, so it jumps back to start unless job timer expired.
So what you say means the script runs in same attention as long as cancelled for whatever reason, or the first <resume/> will jump to the label in the appropriate attention node?

I cant imagine how it mixes the code form the two levels without problems.

[w.evans]

egads! I am getting rusty! Missed the resumes near the ends of both sections.

What I used to do (partly) to trace flow is to add notifications and logbook entries to certain points. (Most modders, and the devs, use the debug command, but I kind of like how it appears in the event monitor, plus the logbook's written to the save file with time stamps so the record's easy to retrieve.) I'm pretty sure I left those in the published version. Activate all of the feedback by setting $MICT_FeedbackAll, which is set at the start of both big sections, to true. I usually wrap that in a do_if filtering ships I want to track like just player-owned ships or ships of a particular type or something like that. You could also trace where in the script ships go to the low attention section or vice versa by activating $MICT_FeedbackAll in one section and one of the more selective filters in the other section.

Or add something like:

Code: Select all

<show_notification caption="'=== MICT Reset ==='" details="'%1 \n escorting %2 \n now in low attention'.[this.ship.knownname, $target.knownname]" queued="false" priority="2"/>
<write_to_logbook category="general" text="'%1 \n escorting %2 \n now in low attention'.[this.ship.knownname, $target.knownname]"/>

at the beginning of the low attention section. with $MICT_FeedbackAll active in high attention.

[pref]

I was thinking a bit, and realized the only sensible way is that the same attention script runs until finished, and the caller scripts must resume in the attention level they called the script as well, or everything gets messed up.
Except when attention change event resumes with abort called scripts.

Sorry to disturb you with this, i thought there is a trick for this in the escort script i didn't notice. But it probably works without any extra handling this way. Though i'd be curious how the engine handles apply_attackstregth IZ. I think the vanilla escort script has the same structure so it must work somehow.

Anyway sorry again for OT.
And thanks!

[w.evans]

I'm a bit confused. apply_attackstrength is used in the low attention sections of fight scripts used by defence officers. The escort scripts are used by captains. So the escort scripts shouldn't go to any situations where apply_attackstrength is called.

I think I get your point though. And as far as I remember, no, that part of the DO script never gets called in high attention. At least I don't remember ever logging any ships in high attention back when I was testing low attention combat extensively. Then again, those tests didn't involve me moving around a whole lot, so it could just be that no battles in those tests moved from low attention to high.

And don't worry about going OT on this thread. I like talking shop, and talk of this sort could very well benefit the mod at some point, so I think it's very much relevant.

edit: forgot to mention: when a script is called from another script, and it goes back up the call stack, it continues at the label from which the call was made, presumably at the appropriate attention section if the calling script has more than one. There is an intriguing new attribute called resumeflag that can supposedly change this behavior to continuing from the action that called the other script. Haven't played with it yet though.

[pref]

Wait what??

You mean i call a script, and on return the caller will resume at a label, not right after the run_script command?

[w.evans]

pretty sure, yes. just found out myself.

[birdtable]

Obviously w.e had a hearty breakfast ....

[w.evans]

Hey birdtable, how's it going?

[pref]

Thanks, have to check on that new param..

Regarding apply attacksrtrength:
The DO script is also looped, and has no attention change event.

Also captain/pilot scripts include the command - fight.attack.object will eventually call it in the end via some other scripts for ex (without a check for attention change event).

[birdtable]

Doing fine (edit in w.e ..pref popped in) .. well, not ordered the gravestone yet ...waiting to test MICT again from the non bonnet lifter give the tyre a kick point of view ....

[w.evans]

@pref, nope. capship captains escorting capships go:

move.escort -> move.escort.capital -> (vanilla high attention) fight.attack.object -> move.attack.object.capital

then they drop back to move.escort capital when the hostile's dead. similar path for capship captains attacking and patrolling, with a couple additional steps for those running the new move.patrol.route.

capship DOs go to fight.attack.object.capital or fight.attack.object.station (depending on where they're at), but can't remember how they get there. They just mostly stay there though.

can't remember what exactly smallship pilots do. Think they either stay do the same as capship captains when escorting except they either go to fight.attack.object.fighter or scoot on over to fight.attack.object.fighter.bigtarget depending on what they're shooting at?

@birdtable, i'll try to get something to you sometime, er, after 4.0 comes out. If you're using the nexus version, should be ok without MICT_supp4 though, except Balors won't shoot torpedoes and capships won't launch drones. Want to cast a vote on this?

[pref]

fight.attack.object.fighter has an apply attackstrength. Thought its normal for main controlentity, but probably it only works for pilots then.
Scripts must restart on attention change then, ES wouldn't have coded them like this otherwise i assume.
Thanks for clarification!

[w.evans]

sure. hope that helped.