[WIP] Captain AI overhaul. Updated 09.12.2014

The place to discuss scripting and game modifications for X Rebirth.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Thu, 22. Jan 15, 04:48

oh map captain will attack/fire wpns when I order IF the fighter is within wpn range. then he says awaiting orders after that. the only thing that doesn't happen is the ship does not move towards the fighter. I noticed when the ship is ordered to attack all enemies in zone that the ship vectors away from the fighters as well. weird

cicero111
Posts: 108
Joined: Sat, 13. Aug 11, 14:30
x4

Post by cicero111 » Thu, 22. Jan 15, 19:05

This mod only replaces a small movement section initiated by this check:
<do_if value="not $issmall or this.ship.distanceto.{$target} gt (3km + this.ship.size)">
..i.e. only the L/XL pursue code.

Took a quick peek in the vanilla code (been a while), and the section for XS/S/M is this.

Code: Select all

          <!-- For small targets, do not move (IF NEAR) -->
          <wait>
            <interrupt_after_time time="$updatetime" />
            <interrupt>
              <conditions>
                <event_object_destroyed object="$target"/>
              </conditions>
            </interrupt>
          </wait>
..so I think that is vanilla behavior ("IF NEAR" == same zone, if in another zone it should move there IIRC).

Edit: The DO will recieve the target order as well and start shooting if in range though, both in vanilla and with this mod.

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Thu, 22. Jan 15, 21:34

thanks for that. im thnking ill try modding that code so the cap goes after the little fellas. ill post any successes I have..or don't
thanks again
balog

cicero111
Posts: 108
Joined: Sat, 13. Aug 11, 14:30
x4

Post by cicero111 » Thu, 22. Jan 15, 21:58

Have fun, I'm looking forward to take a peek at your code - and the battle reports :)

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Fri, 23. Jan 15, 02:25

I have made some changes but any changes I make have no effect in game. I have looked through all my extensions to make sure there are no duplicate files ie. move.attack.object.capital but even deleting every occurance of the file both in the aiscripts folder and extensions has no effect ont he game. my cat/dat files are tucked away as well..does the save game store some of this data?

Pimpace
Posts: 257
Joined: Tue, 1. Jan 13, 15:48
x4

Post by Pimpace » Fri, 23. Jan 15, 16:28

Yo!

Which mod is better for fleet fighting?
UFO - Ultimate Fleet Overhaul, or this one?

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Fri, 23. Jan 15, 18:23

well after good old fashion trial end error I noticed the culprit for not allowing my capships to move.to . object on small ships was the the captain script. so what I am doing now is seeing which part of this script (which is great for caps vs caps) I can tweek to still allow the vanilla to do its thing. I did try <add vs <replace and have had some success but not entirely.

Ill keep you posted

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Fri, 23. Jan 15, 19:03

@balogt

Code: Select all

<?xml version="1.0" encoding="utf-8" ?>
<diff>  
	<remove sel="//attention[@min='unknown']/actions/do_while[1]/do_else"/>

	<add sel="//attention[@min='unknown']/actions/do_while[1]">
		<do_else>
			<get_safe_pos object="$target" zone="this.zone" min="this.ship.maxcombatrange.all/2.0" max="this.ship.maxcombatrange.all" radius="this.ship.size/2.0" result="$pos" allowyaxis="false" />
			<set_value name="$posY" min="$target.position.y" max="$target.position.y + $target.height" comment="align the other capital ship"/>
			<move_to destination="this.zone" abortpath="true" object="this.ship" finishonapproach="true" forceposition="false" usehighways="false" >
				<position x="$pos.x" y="$posY" z="$pos.z" />
				<interrupt_after_time time="$updatetime" />
				<interrupt>
					<conditions>
						<event_object_destroyed object="$target"/>
					</conditions>
				</interrupt>
			</move_to>
		</do_else>
	</add>
</diff>
should do it. (uses the same vanilla movement script for target=capship, but for target=smallship.) Should still prioritize capital ships. No idea how well it'll work though since I'm not all that familiar with the movement scripts.

@Pimpace, if I understood Mad_Joker's notes correctly, it should be safe to install both. The UFO movement and firing scripts should only operate on UFO fleets, all other cap ships should use cicero111's awesomeness.

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Fri, 23. Jan 15, 20:36

thanks for that I will play with it. the simple solution I just did that seems to work fine is redifining the $issmall definitions to only include xs ships. thus the small and medium vessles get categorized by the captian ai script as a cap ship or valid target, and my cap ships turns and uses the captain ai script to combat them. thus far I havnt seen it negatively affect the small and medium vessles. they still dock normally that I can see.. can you see any potential problems

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Fri, 23. Jan 15, 20:44

Possibly a problem with prioritizing, although come to think of it, that might be a problem with the code I posted as well. If cap ships think that small ships are as threatening as other cap ships, they might go off chasing tiny interceptors and ignore the Taranis that's following to clobber them.

Maybe replace the do_else with a <do_elseif value="$issmall">*stuff*</do_elseif> and delete the <remove sel=".../do_else"/> and add something to the do_elseif condition to make sure that there are no capships within gravidar range?

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Fri, 23. Jan 15, 22:08

good idea. ill try that next.

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Fri, 23. Jan 15, 22:12

just thinking outloud, but with the change of issmall to include only xs ships now s,m,l,xl are valid targets to moveto..could we just add a couple lines to the code to identify protity ttargets being xl,l first then s,m?

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Fri, 23. Jan 15, 23:49

Hey balogt, hey cicero111,

been thinking of the target prioritization thing and I thought that the most logical place to prioritize targets is in target acquisition since $target seems to always only expect one target.

If I understand this correctly, targets can be acquired in 4 ways:

player orders ship to attack target,
ship is patrolling,
ship is attacking all targets in zone (does this use the same script as patrolling?),
ship is attacked.

In the first case, $target should be whatever player designates.
In the second and third cases, I think it uses this section:

Code: Select all

                  <check_all>
                    <check_value value="$capship" />
                    <check_any>
                      <!-- First search for capitals -->
                      <count_gravidar_contacts result="$capitalenemies" object="this.ship" class="[class.ship_l,class.ship_xl]" functional="true" maybeattackedby="this.ship" min="1">
                        <match_distance object="this.ship" max="@$pursuedistance"/>
                      </count_gravidar_contacts>
                      <!-- Second search for Stations -->
                      <count_gravidar_contacts result="$stationenemies" object="this.ship" class="class.station" functional="true" maybeattackedby="this.ship" min="1">
                        <match_distance object="this.ship" max="@$pursuedistance"/>
                      </count_gravidar_contacts>
                      <!-- Third search for rest (small, ..) -->
                      <count_gravidar_contacts result="$smallenemies" object="this.ship" class="[class.ship_m, class.ship_s]" functional="true" maybeattackedby="this.ship" min="1">
                        <match_parent>
                          <match class="class.highway" negate="true"/>
                        </match_parent>
                        <match_distance object="this.ship" max="@$pursuedistance"/>
                      </count_gravidar_contacts>
                    </check_any>
                  </check_all>
in \aiscripts\move.seekenemies.xml where it looks like targets are already prioritized so: bigships>stations>smallships (and if it acquires a smallship as a target, as per the code that cicero111 posted, the capship stops moving until the target is destroyed.) The vanilla script does indicate, however, that it should only do this if:

value="not $issmall or this.ship.distanceto.{$target} gt (3km + this.ship.size)"

That is, $target is a capship or a station which is too far for guns to engage effectively, in which case it should move closer, or if the target is 3km + this.ship.size away (too far for Plasma/MA to be effective?)

Otherwise, this should be active:

Code: Select all

        <do_if value="$pursuetargets and this.zone != $target.zone">
          <run_script name="'move.generic'" sinceversion="2">
            <param name="destination" value="$target" />
            <param name="endintargetzone" value="true" />
            <param name="debugchance" value="$debugoutputchance"/>
          </run_script>
        </do_if>
EDIT: but only if $target is in a different zone! Sorry, missed that.

Questions then: do vanilla capships pursue smallships if in-zone? If so, maybe changing this line:

Code: Select all

<do_if value="not $issmall or not player.ship">
to this:

Code: Select all

<do_if value="not $issmall or not player.ship or this.ship.distanceto.{$target} gt (3km + this.ship.size)">
plus pursuit code of some sort if value=$issmall might be enough? Although I did notice that cicero111 changed that to remove the this.ship.distanceto... condition. Was there a particular reason for that?

I have to admit though that I haven't really dug into the CaptainAIOverhaul movement script. It's much more a work of love than the vanilla script looks like, and is way too complicated for a mere cursory look.

edit 2: on second thought, pursuit code for $target == $issmall might not even be necessary. I don't think that the CaptainAIOverhaul has target specific movement data, only specific movement data depending on what the ship executing the movement is, is that right?

edit 3: and then there's the fourth case. I don't think that the AI acquires any attackers as targets, does it? Making this as a condition for target acquisition with chance equal to, say, direct proportion to combat skill (sees ships approaching with intention to attack even before they fire), and inverse proportion to morale if ship already has a target (captain gets easily frazzled and distracted, and turns to engage drones over that Taranis firing JET/LR over yonder) might be a good idea. That would probably require altering a script other than the ones already in CaptainAIOverhaul, though.

balogt
Posts: 773
Joined: Thu, 18. Dec 03, 09:00
x3

Post by balogt » Mon, 26. Jan 15, 22:25

a couple days and several battles later the simple redifing of small ships has not created any issues I can detect. it only affects the move command xml and the def $issmall only carries to a couple others. all other tasks seem un affected. im going to stick with this until it breaks :). I will note that when you change the def you have to reassign the defence officer in order for it to take affect.
cheers
balog

cicero111
Posts: 108
Joined: Sat, 13. Aug 11, 14:30
x4

Post by cicero111 » Tue, 27. Jan 15, 20:47

@w.evans:
Good catch there with the removal of "or this.ship.distanceto.{$target} gt (3km + this.ship.size)" - that is part of a bug.
The reason for the removal that the custom movements would get quite weird if also was running when small targets (explosion avoidance, suicide runs, broadside and such).
Small ships should have been caught by the do_elseif statement in the end of the script with the vanilla codebits, but added below the large do_if i$ssmall as as a separate patch. Suspect that is one of the late night changes where the hacks appear - around retest scenario, round 20.
Took a look back at what i have from the mod history and that one have been there a while, i've even added some debug stuff there without noticing.

And you are correct there, the script is based on love of coding on this engine, ideas/what if's, and loads of feature creep :) Did try to comment what each section does to help readability (is a long do_elseif decision chain) and did plan to split off some of it out in a helper library - until a new distraction appeared with that boost thing..

@balogt
Sorry for the wrong information earlier there - guess I need to get my head back in the game and divide with pursuing some of my new time sinks - have some retro computing/r.pie/arduino madness going on - them xmas presents got me a bit distracted :P

I'll make a proper bugfix for this one - and thank you for the bugreport, that was an old one :)

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Tue, 27. Jan 15, 21:03

Boost of doom of my heavy assault flotilla of 4 Arawn led by a Balor towards a fighter sounds fun ... and a bit silly. :) Wouldn't be unreasonable for them to turn and swat if stung by a fly though. Especially if the fly is actually a wasp and is part of a swarm.

cicero111
Posts: 108
Joined: Sat, 13. Aug 11, 14:30
x4

Post by cicero111 » Tue, 27. Jan 15, 21:41

Hehe - yup, could get quite interesting, and on arrival "everybody runaway!!!" when one of them wasps gets below 50% hull, almost worth a try :P

That stop/ignore them totally was not good that slipped through the cracks - got a bit tunnel vision playing groundhog day with my test saves I guess :)
Highly recommend MadJoker's UFO test mod when doing these kinds of scripts, both as a time and sanity saver/for variety - if you are not using it already. I discovered it a bit late. Spawning bunch of caps near the fleet and seeing the code respond in different ways is quite fascinating.

Eightbal1
Posts: 41
Joined: Wed, 7. Jan 15, 03:13
x4

Don't use AJD mod?

Post by Eightbal1 » Tue, 3. Feb 15, 14:16

Cicero, you mentioned in your Captain AI mod description at the start of this thread that the AJD mod conflicts a bit with yours. Sorry if this is a stupid question, but what is the AJD mod?

w.evans
Posts: 2963
Joined: Tue, 18. Nov 14, 16:23
x4

Post by w.evans » Tue, 3. Feb 15, 14:40

@Eightbal1, Nice to see you here! "AJD" maybe means bm01's Automated Emergency Jump. I vaguely remember there being a report of conflicts between that and Captain AI Overhaul. Can't remember for sure, though.

Rubini
Posts: 452
Joined: Mon, 7. May 07, 05:17
xr

Post by Rubini » Tue, 3. Feb 15, 15:23

w.evans wrote:@Eightbal1, Nice to see you here! "AJD" maybe means bm01's Automated Emergency Jump. I vaguely remember there being a report of conflicts between that and Captain AI Overhaul. Can't remember for sure, though.
If it is really the Automated Emergency Jump, any way to make them compatible as they both adds good things to combat aspects of the game?

Post Reply

Return to “X Rebirth - Scripts and Modding”