[MOD] Miscellaneous IZ Combat Tweaks

[debstar2610]

I do not know why but, this.ship.race is null and this.ship.makerrace is null too.
So that the condition is never true.

Something is broken somewhere

[w.evans]

this.ship.race is null

not surprising since the ship doesn't have a race! "race" is a property of entities, so looking up "this.race" in an aiscript should print the race of the character running that script, or "this.ship.pilot.race" should output that of the pilot/captain of this.ship.

Depends on where you use it though. If working from an MD script, "this" would refer to the cue where it's written. You'd have to define which entity you're referring to in that case.

and this.ship.makerrace is null too.

This one i don't know much about since i haven't used it at all. "makerrace" is a property of a defensible, so this.ship.makerrace should print something. Best guess is that it has to be defined in the ship macro and it wasn't. (?)

[debstar2610]

this.ship.race is null

not surprising since the ship doesn't have a race! "race" is a property of entities, so looking up "this.race" in an aiscript should print the race of the character running that script, or "this.ship.pilot.race" should output the pilot/captain of this.ship.

Depends on where you use it though. If working from an MD script, "this" would refer to the cue where it's written. You'd have to define which entity you're referring to in that case.

and this.ship.makerrace is null too.

This one i don't know much about since i haven't used it at all. "makerrace" is a property of a defensible, so this.ship.makerrace should print something. Best guess is that it has to be defined in the ship macro and it wasn't. (?)

OK ! I get it know.

I was wondering why all my ships try to escape the same way before

Attempt to differentiate captain tactics from background and training. At the moment, only the retreat thresholds are affected:

The escape was always done by MICT ship because the last condition is true. (when attacking Ennemy Cap ship)

Code: Select all

(this.ship.distanceto.{$target} le (@$target.maxcombatrange.all + $target.size))

Now, as i m starting to kill big station, this condition is always false because, if the @target is an Infopoint ( componentslot ), id does not have turrets.
And so @$target.maxcombatrange.all is always null.

SO that MICT ship will not try to escape !
So i have to do two fixes ?
- 1) check if target is an 'Infopoint', the use @$target.container.maxcombatrange.all in the above condition

- 2) change all this.ship.race to this.ship.pilot .race

[w.evans]

- 1) check if target is an 'Infopoint', the use @$target.container.maxcombatrange.all in the above condition

I don't think you can attack an infopoint. If you set a ship to attack a station by selecting an infopoint, the ship should attack either the station, a station module, or a surface element. Those cases should be covered by looking up the container of whatever your ship is actually targeting, if it has one.

In the notifications you get from your ship captain, what does he or she say that they're attacking?

- 2) change all this.ship.race to this.ship.pilot .race

I'm confused. I searched the script in case I remembered wrong, and I didn't use "this.ship.race" anywhere.

[debstar2610]

- 1) check if target is an 'Infopoint', the use @$target.container.maxcombatrange.all in the above condition

I don't think you can attack an infopoint. If you set a ship to attack a station by selecting an infopoint, the ship should attack either the station, a station module, or a surface element. Those cases should be covered by looking up the container of whatever your ship is actually targeting, if it has one.

In the notifications you get from your ship captain, what does he or she say that they're attacking?

- 2) change all this.ship.race to this.ship.pilot .race

I'm confused. I searched the script in case I remembered wrong, and I didn't use "this.ship.race" anywhere.

The captain says that he is attacking the station !
But the $target is an 'Adsign'.

edited : .. i am sorry , there is no this.ship.race, it is this.race ....it is me who is confused ..i ll recheck, i am not drunk yet

Edited 2 : so the main problem is only when using the attack command from Infopoint.

[w.evans]

The captain says that he is attacking the station !
But the $target is an 'Adsign'.

The display uses $target.knownname. Why do you think $target is an Adsign?

Look, I don't doubt that you're seeing what you're seeing. But that display uses the name of $target so it can't display something other than $target's name. There has to be a different reason why it isn't escaping.

Does the captain say that he's trying to escape?
If so, is the distance that he says he's trying to escape to a lot shorter than it should be?
Does the station that the captain's targeting, or the station module that it's targeting, not have any turrets?

Come to think of it, think 3rd might be most likely, if the captain is targeting a station module and that module does not have turrets, or doesn't have any left.

THe 'this.ship.race' is in the MICT.move.attack.object.capital.xml file.
( from nexus or steam )

In all three versions that are out, it's written this.race Been like that since 0.06 which was released on the 7th of March last year.

Just downloaded and checked all three versions again. Searching for "this.ship.race" came out empty.

[debstar2610]

The captain says that he is attacking the station !
But the $target is an 'Adsign'.

The display uses $target.knownname. Why do you think $target is an Adsign?

Look, I don't doubt that you're seeing what you're seeing. But that display uses the name of $target so it can't display something other than $target's name. There has to be a different reason why it isn't escaping.

Does the captain say that he's trying to escape?
If so, is the distance that he says he's trying to escape to a lot shorter than it should be?
Does the station that the captain's targeting, or the station module that it's targeting, not have any turrets?

Come to think of it, think 3rd might be most likely, if the captain is targeting a station module and that module does not have turrets, or doesn't have any left.

THe 'this.ship.race' is in the MICT.move.attack.object.capital.xml file.
( from nexus or steam )

In all three versions that are out, it's written this.race Been like that since 0.06 which was released on the 7th of March last year.

Just downloaded and checked all three versions again. Searching for "this.ship.race" came out empty.

this.ship.race ...my mistake. is is really written as this.race.

So i deleted the w-mct folder.
I redownload from steam. so that threre is no longer all my debug notifications.
And i did some iteration to the same scenario :
Load my save.
Click in the Infopoint of a PMC radar.
In the monitor display, there is a MICT message saying that the ship is Jumpint to an 'Ad sign'
In the map, my capital ship cammander is attacking (Command relay')

The cap ship go next to it and stay there even if his shield is less than 0%

Sometimes, one of the wingman was too damaged , and tried to flee ( in the logbook, it says that the ship is force to flee from PMC station )
One time, it used the flee jump to a jump beacon with full of PMC ships lol ! it died immediately !

In the radar monitor, i ve seen some messages with ' Ship jumping to 'Ad Sign' '

Some screenshots here :
http://s000.tinyupload.com/?file_id=000 ... 8623998324

Sorry again for the 'this.ship.race' it was my mistake

[w.evans]

no prob. for a moment there, thought i missed a spot somewhere.

looks like the stuff for switching targets is missing a case. will look into it, possibly during the weekend. could you send me a save right before this happens? preferably right before you give the attack order, if the attack order triggers the behavior you described reliably.

[debstar2610]

no prob. for a moment there, thought i missed a spot somewhere.

looks like the stuff for switching targets is missing a case. will look into it, possibly during the weekend. could you send me a save right before this happens? preferably right before you give the attack order, if the attack order triggers the behavior you described reliably.

yes, i ve saved the savegame for testing later !
http://s000.tinyupload.com/?file_id=889 ... 3460063934
Ony CWIR mod is mandatory as i used 2 ships from it.

Ships are in front of the PMC station, and ready to fire.

I may know why wingmen are destroyed or are using vanilla flee.
If I understand well, only Ship that is running the Mict.move.attack.capital can use the MICT flee behaviour, because the code is only there.

So what will happen if the ship is stuck with 'Command : Escorting XXXX - flying'. For some reason, they does not received the attack order from their leader, and try to stay near the leader and the station. As a result, they just stay and wait for death ( unless the vanilla flee is triggered ).

[w.evans]

If you went with the Nexus upload, do you have MICT_supp2? (Do you have MICT.move.escort.capital.xml?) Escorts of MICT ships should also try run MICT even if their crews suck, although they might be bad at it.

Thanks for the save. Will try to make time to take a look tomorrow.

[debstar2610]

If you went with the Nexus upload, do you have MICT_supp2? (Do you have MICT.move.escort.capital.xml?) Escorts of MICT ships should also try run MICT even if their crews suck, although they might be bad at it.

Thanks for the save. Will try to make time to take a look tomorrow.

Yes I have it, i set all the debug notifications to true.
And, I m now looking for the event : 'event_object_signalled'.

For the moment, the wingmen are always receiving the event : 'event_object_enemy_found'.
So that the target of the commander is not choosen by them ?

[w.evans]

For the moment, the wingmen are always receiving the event : 'event_object_enemy_found'.
So that the target of the commander is not choosen by them ?

Code: Select all

<check_any>
  <event_object_attacked group="$target.pilot.$escortgroup"/>
  <event_object_attacked object="$target"/>
  <event_object_enemy_found object="this.ship"/>
  <event_object_enemy_found object="$target"/>
</check_any>

If someone in the escort group is attacked, their commander is attacked, the escort detects an enemy, or their commander detects an enemy.

Enemies are found if they come into the ship's radar range (if the enemy is a small ship), or if it comes to within 40km (if a big ship or station).

If you want to get detailed info on what your MICT escorts are doing, you could go into MICT.move.escort.capital and set $MICT_FeedbackAll to true. Might give you more information than is useful though. I usually place it in a do_if to filter, or use one of the more limited filters directly below that.

[w.evans]

About MICT ships targeting ad signs when attacking a station, think I found the problem:

Code: Select all

<find_object_component name="$MICT_StationModule" object="$target" class="class.destructible" functional="true" indestructible="false" surfaceelement="false"/>

Ad signs are also class.destructible, as are most things. Thought, I could fix it by specifying class="[class.radar, class.production, class.storage]" but some structural parts of stations are only class.destructible.

Alternative would be to explicitly filter objects with class.adsign out. But that might miss other things that are incorrectly targeted. Have you noticed your ships targeting anything else strange? (From the battle display notifications in the event monitor, do your captains say that they're jumping towards/away other strange things?) If not, then filtering adsigns out might very well do it.

Wouldn't be a problem anywhere but in CWIR since you can't tear stations down anyway, and the three classes in the list are the big parts of stations that it would make sense to wreck, but in CWIR, I think all parts of the station have to be destroyed? Will think about how to fix it.

Will look into your escort problem.

edit: fix incoming

[w.evans]

9.April 2016 - Miscellaneous IZ Combat Tweaks updated to v0.65

Fixed MICT ships targeting silly things like ad signs when attacking a station.

Fix was done via adding a size filter to the node that looks for station modules to switch targeting for movement to. (Adapted from the vanilla DO script.)

Thanks to debstar2610 for reporting the issue.

[debstar2610]

For the moment, the wingmen are always receiving the event : 'event_object_enemy_found'.
So that the target of the commander is not choosen by them ?

Code: Select all

<check_any>
  <event_object_attacked group="$target.pilot.$escortgroup"/>
  <event_object_attacked object="$target"/>
  <event_object_enemy_found object="this.ship"/>
  <event_object_enemy_found object="$target"/>
</check_any>

If someone in the escort group is attacked, their commander is attacked, the escort detects an enemy, or their commander detects an enemy.

Enemies are found if they come into the ship's radar range (if the enemy is a small ship), or if it comes to within 40km (if a big ship or station).

If you want to get detailed info on what your MICT escorts are doing, you could go into MICT.move.escort.capital and set $MICT_FeedbackAll to true. Might give you more information than is useful though. I usually place it in a do_if to filter, or use one of the more limited filters directly below that.

It works very well with the patrol / attack all ennemies.
It works as intended too with 'attack object' command, if there is there is only one enemy or the ennemies are stacked or the squad is stacked.

In the savegame, you can see that the 2 succellus are ignoring the Vanguard Destroyer 's target, and are engaging the 2 PMC harvesters in the top of the map.
The heavy sul and phoenix may also attack the mining ship in the right, even if I ask the all squad leader to attack the station.
Maybe, the squad leader can't force his wingmen to shoot at his target ?

When asking the squad leaders to attack an object, it seems that the wingmen does not reach this part of the MICT.move.escort.capital ( or should not they ? )

Code: Select all

							<!-- Commander signal this -->
							<do_if value="event.name == 'event_object_signalled'">
								<do_if value="$target.isoperational and event.param2.isoperational">
									<!-- if is enemy -->
									<do_if value="$target.mayattack.{event.param2}">
										<set_value name="$enemy" exact="event.param2"/>
										<!-- Shoot while in formation-->
										<shoot_at object="this.ship" target="$enemy" slot="tag.primary_slot" tolerance="10.0deg" locktarget="true" weapontype="combat"/>

										<!-- MICT: fire missiles as well -->
										<shoot_at object="this.ship" target="$enemy" slot="tag.secondary_slot" tolerance="30.0deg" locktarget="true" weapontype="combat"/>

										<!-- Escortee enemy relation-->
										<do_if value="not this.mayattack.{$enemy}">
											<add_relation_boost object="this" otherobject="$enemy" value="-0.1" decay="1" delay="10min" silent="true"/>
										</do_if>
									</do_if>
								</do_if>
							</do_if>

Is there something like 'player attack event signalled' or such .. so that, it will trigger the event_object_signalled ?

[debstar2610]

9.April 2016 - Miscellaneous IZ Combat Tweaks updated to v0.65

Fixed MICT ships targeting silly things like ad signs when attacking a station.

Fix was done via adding a size filter to the node that looks for station modules to switch targeting for movement to. (Adapted from the vanilla DO script.)

Thanks to debstar2610 for reporting the issue.

There is no Ad Sign targeting anymore, especially with patrol or attack ennemies command, Sometimes, when I click on the InfoPoint and click on the 'attack', ship are targeting 'Ad Sign', but, they switch to the station module in the next round.

I think Station module does not have turrets ... , the $target.maxcombatrange is always null.
The station module 's weapon systems is operational. All turrets are working.

Maybe, turrets do not belong to station module but to its container ? So my quick fix is :

Code: Select all

<set_value name="$MICT_MaxTargetCombatRange" exact="@$target.maxcombatrange.all" />
				<do_if value="$isstation">
					<set_value name="$MICT_MaxTargetCombatRange" exact="@$target.container.maxcombatrange.all" />
				</do_if>

And use this $MICT_MaxTargetCombatRange for the flee conditions

Code: Select all

				<do_if value="(((this.ship.shield le (this.ship.maxshield * 0.2f)) and (this.race != race.split)) or ((this.ship.shield le 0.0f) and (this.race == race.split)) or ((this.ship.shield le (this.ship.maxshield * 0.4f)) and (this.race == race.teladi))) and (this.ship.distanceto.{$target} le ($MICT_MaxTargetCombatRange + $target.size))">

[w.evans]

Maybe, the squad leader can't force his wingmen to shoot at his target ?

Ah, yes. That was deliberate. Tried to design squadron logic such that they work more effectively as a squadron:

- close-ranged ships attempt to protect the squadron commander by engaging any ships that might endanger the squadron commander thereby preventing him/her from fulfilling the mission. They sort through targets, and choose whatever is closest to the squadron commander.
- long-ranged ships select whichever target can do the most damage to the squadron as a whole and attempt to take those out.

For both above, capital ships are prioritized. Small ships or stations are only engaged if they couldn't any other targets in their priority list. Reason was that capital ships are more of a threat than any small ships out there, and stations aren't going anywhere

- non-combat ships try to stay close to their squadron commander and repair any ships that get damaged and come back to within their radar range.

Works with the retreat function since any ships that get damaged tend to try and form up with their squadron commander, thus bringing them close to the repair ships, if there are any around. Even if there aren't any repair ships in the squadron, that area would tend to be relatively safe since other close-ranged ships would be engaging any ships that come close.

Is there something like 'player attack event signalled' or such .. so that, it will trigger the event_object_signalled ?

The bit that listens for event_object_signalled, and the part immediately below the interrupt conditions in that section of the script, are from vanilla and were kept in, with higher priority than the MICT stuff, to maintain compatibility: that is, if they do get a signal, they will prefer to respond to that signal. To be honest though, I can't remember where in the vanilla ai scripts that signal comes from. Would think that logical place would be in fight.attack.object (where all ship captain AIs go when they get in a fight), or command.fight.attack (which player-owned ship captains do when they're given an attack order), but I don't see it there.

[w.evans]

sorry, missed your last post. Good to hear confirmation that they aren't such ad-hating-anti-corporation-anarchists anymore.

About the retreat stuff, actually they shouldn't be using maxcombatrange at all when they find themselves having to retreat from a station, or while engaging a station. That's overridden by this:

Code: Select all

<set_value name="$MICT_MaxEscapeJumpDist" exact="10km * (1.0f + ((this.combinedskill)f / 100.0f))"/>
<set_value name="$MICT_MinEscapeJumpDist" exact="10km / (1.9f - ((this.combinedskill)f / 100.0f))"/>

edit: missed this:

Code: Select all

<do_if value="(((this.ship.shield le (this.ship.maxshield * 0.2f)) and (this.race != race.split)) or ((this.ship.shield le 0.0f) and (this.race == race.split)) or ((this.ship.shield le (this.ship.maxshield * 0.4f)) and (this.race == race.teladi))) and (this.ship.distanceto.{$target} le (@$target.maxcombatrange.all + $target.size))">

so while the distance they'll retreat to is taken care of, they might not decide to retreat if their target (which could be a production module with turrets stripped off) doesn't have a maxcombatrange. Hm.

Thanks for the report.

edit: fix incoming

[w.evans]

9.April 2016 - Miscellaneous IZ Combat Tweaks updated to v0.66

Fixed MICT ships failing to retreat while engaged with a ship, station, or station module that does not have working weapons.

Thanks to debstar2610 for reporting the issue.

[debstar2610]

9.April 2016 - Miscellaneous IZ Combat Tweaks updated to v0.66

Fixed MICT ships failing to retreat while engaged with a ship, station, or station module that does not have working weapons.

Thanks to debstar2610 for reporting the issue.

Thanks ! I m starting a new game with all those new features !

Last but not least, I still have some issues from the retreat thing. Ships running the 'sup 2 Mict.move.escort.capital' will not retreat.
( E.g. if they are under heavy attack from big ships or station, while joining the commander )

so I added something like this in the unterrupt block of Mict.move.escort.capital

Code: Select all

<interrupt>
						<conditions>
							<check_all>
								<event_object_attacked object="this.ship"/>
								<check_value value="this.ship.shield le (this.ship.maxshield * 0.5f)"></check_value>
							</check_all>
						</conditions>
						<actions>
							<do_if value="(this.ship.owner == faction.player) and not $this.ship.isclass.[class.drone, class.ship_xs, class.ship_s, class.ship_m] and this.ship.isoperational">
								  <run_script name="'move.flee'"  result="true" >
									<param name="method" value="boost" />
									<param name="attacker" value="event.param" />
									<param name="debugchance" value="0"/>
								  </run_script>
							</do_if>
						</actions>

May I externalize the 'retreat code' from MICT.move.attack.capital in something like 'MICT.move.flee' so that, I can call it in both MICT.move or MICT.escort ?