Question to all EU veterans

[Hobbes]

I'm trying to figure out some AI issues and I'm wondering if anyone has a clear recollection of the aliens specifically targeting terrain on X-COM Bases or even trying to destroy the Skyranger dropship during tactical missions.

[Tycho]

I'm trying to figure out some AI issues and I'm wondering if anyone has a clear recollection of the aliens specifically targeting terrain on X-COM Bases or even trying to destroy the Skyranger dropship during tactical missions.

 

I'm pretty sure, I've only seen aliens target xcom agents or civilians (in terror missions.) Of course, they are lousy shots so they have done things by accident which made a huge problem for me: Destroying stairs by a bad throw of a grenade or a cyberdisk stuck in the wall outside the door on the second floor of a terror ship. Destroy it and it takes out the entire floor. I thought the skyranger was indestructible (except for the mountain tile set bug).

[Bomb Bloke]

I assume you're wanting to get them to intentionally destroy base modules. I've trapped aliens in a room with the tiles that needed to be roasted to take out a mind shield, but even after 30+ turns they showed no interest in firing until I sent some soldiers up there too. Aliens don't destroy base modules, players who think it's funny to shell the science lab do.

 

But even if aliens can't be made to destroy the relevant tiles intentionally, they could be redefined and/or moved to somewhere where they may be destroyed unintentionally. Their default locations are just about impossible to hit by accident even when battling with blaster launchers alone.

[Space Voyager]

I can't remember aliens being overall destructive. I guess they are after the people, if they get those, all your base are belong to us.

[Bomb Bloke]

It occurred to me that there was a mistake in my testing - just putting the aliens near the route nodes is not sufficient, I forgot to actually tell them to GO there (well, that and it turned out I was working with a hyper-wave decoder, not a mind shield).

 

Setting their "end" nodes to the one in the room did nothing. Setting both their start AND end nodes to that value resulted in them FIRING, even before they got to the node... Use of the "big brother" function in Seb's loader gave me just enough time to capture this flash of light as the alien detonated a blaster launcher shell at point-blank range:

 

 

So there you have it, aliens can be made to fire at terrain.

 

There's a catch though, straight after the shot connects the game crashes. The debug functions in the loader give indications as to why, perhaps it can be fixed?

 

GAME_10.rar

[Hobbes]

Setting their "end" nodes to the one in the room did nothing. Setting both their start AND end nodes to that value resulted in them FIRING, even before they got to the node... Use of the "big brother" function in Seb's loader gave me just enough time to capture this flash of light as the alien detonated a blaster launcher shell at point-blank range:

 

OK, just had a look. If I understood correctly, you've edited the UNITREF.DAT file and set bytes 69-70 as the start and end nodes for the current movement. XBASE15.RMP contains 1 node on the 2nd level, did you add a 2nd node? If so, what values did you use for bytes 21 and 22?

 

I'm trying to currently replicate this but so far no success.

[Hobbes]

OK, I managed to repeat it 1 time in Dawn City. I changed all of the furniture victory points to 1 (same as those mind shield thingies) then changed a few nodes (bytes 21&22 both to 5) inside the Urban01 map (the blue apartments) then used XComUtil to changed all the alien weapons to blaster launchers.

 

I got a crash just like your game, where a Snakeman decided to do some interior decoration inside the apartment. However, I can't repeat the same behaviour afterwards for some reason and I'm wondering if Seb's loader might be the cause of the crash.

[Bomb Bloke]

I didn't modify the nodes at all, just the alien's locations, equipment and their start/end node assignments. I also deleted all the other aliens from the map to speed up turn times.

 

I've now performed another test, placing a hyperwave decoder tile into a hanger filled with floaters. Let things run normally a few turns but nothing happened, mostly they just shot at my troops.

 

Then I sealed the room, making it so they couldn't see or exit out of the area, but they just wandered around aimlessly inside it.

 

Finally I set one of the aliens to use the same start/end nodes again, and he promptly fired at the decoder thing, setting off a beautiful chain reaction before crashing the game again.

 

More tests will be required to work out what exactly is going on. One thing I noticed is that the alien I messed with this time was initially set to travel to a node that was no where near him. I can tell you Seb's loader isn't behind the crash, as the game fails regardless as to whether I use it - it could well be that it doesn't like me messing with the node assignments, and will crash regardless as to whether the altered alien sees something to shoot at.

 

I'll see if I can nail down the exact behaviour later this evening.

 

Regarding the "firing point" nodes, I'm suspecting that aliens who are actively fighting will tend to use these as fall-back points for sniping or something like that. Especially in TFTD, I've noticed that aliens may step into your LOS, then step back out; you'll end up finding a group of them there. Odds are they were wanting to shoot at you from that point. Just conjecture on my part though, I've never really looked into alien movement patterns.

 

Edit:

 

Aliens will not fire on "target" tiles UNLESS the last node they reached is one of the upstairs nodes (or his start/end nodes are the same - he may fire on target objects regardless of the node's properties in this case, but I don't think this will ever happen without someone manually editing the UnitRef table mid-game so that probably isn't worth thinking about). That is to say, it seems to hinge on them reaching a node which has offset 22 in its record set to 5 (or at least, something that isn't 0 - I haven't tried modifying the nodes themselves as yet). This would suggest there is a special AI mode triggered with the specific purpose of making them shoot at terrain. I was thinking for a moment that perhaps aliens inherit an AI mode value based on byte 22 from the node they just stepped on, but I can't find any evidence to support this in my save files.

 

Some aliens start battle with destination nodes set to the upstairs chambers. I wiped all of my units from a map, except one who I buried in the dirt - Extender let me watch the muton invaders bee-line their nodes, travel up the stairs and fire. So presumably if you want some aliens to frog-march clear across a map from the start of battle, regardless of where they spawn, setting that byte 22 to something non-zero can encourage that.

 

If an alien is confused by his to/from nodes, he won't move or fire. Odd that I can't seem to get aliens to travel between nodes that aren't right next to each other, though they'll happily pathfind over long distances - even up stairs - if the vanilla game asks them to do so. Hmm. There may be some extra memory values involved in the transit that haven't been spotted yet, in addition to the start/end node values I've been playing with.

 

The crash is definitely caused by aliens shooting at terrain and I can't work out a way to avoid it. Whether or not Seb's loader is used merely determines whether you get a generic Windows error message or one of his debug messages. Just reaching one of the nodes that allows them to fire isn't enough to make it fall over, they have to be able to see and shoot at one of the tiles that are flagged as a target. Game dies as soon as they finish firing. This is probably the cause of some random crashes seen when allowing aliens to take their turn in the course of normal gameplay. Seb's loader states:

 

XCOM crashed at 0x4032C9 with error 0xC0000005 trying to access 0x0000000A

(Quick note for those following along - reading this and this will help you keep track of what the heck we're on about).

[Hobbes]

whoa, what a ton of information

let's see if we can figure this out

 

I didn't modify the nodes at all, just the alien's locations, equipment and their start/end node assignments. I also deleted all the other aliens from the map to speed up turn times.

 

I've now performed another test, placing a hyperwave decoder tile into a hanger filled with floaters. Let things run normally a few turns but nothing happened, mostly they just shot at my troops.

 

Then I sealed the room, making it so they couldn't see or exit out of the area, but they just wandered around aimlessly inside it.

 

Finally I set one of the aliens to use the same start/end nodes again, and he promptly fired at the decoder thing, setting off a beautiful chain reaction before crashing the game again.

 

More tests will be required to work out what exactly is going on. One thing I noticed is that the alien I messed with this time was initially set to travel to a node that was no where near him.

 

What do you mean by the italic expression? That the aliens start combat already assigned with end nodes on UNITREF (like prestarting targets)?

 

Regarding the "firing point" nodes, I'm suspecting that aliens who are actively fighting will tend to use these as fall-back points for sniping or something like that. Especially in TFTD, I've noticed that aliens may step into your LOS, then step back out; you'll end up finding a group of them there. Odds are they were wanting to shoot at you from that point. Just conjecture on my part though, I've never really looked into alien movement patterns.

 

They might just be looking for cover. Again from the debug on the beta it looked more like 'firing points' have to do more with LOF.

 

 

Edit:

 

Aliens will not fire on "target" tiles UNLESS the last node they reached is one of the upstairs nodes (or his start/end nodes are the same - he may fire on target objects regardless of the node's properties in this case, but I don't think this will ever happen without someone manually editing the UnitRef table mid-game so that probably isn't worth thinking about). That is to say, it seems to hinge on them reaching a node which has offset 22 in its record set to 5 (or at least, something that isn't 0 - I haven't tried modifying the nodes themselves as yet). This would suggest there is a special AI mode triggered with the specific purpose of making them shoot at terrain. I was thinking for a moment that perhaps aliens inherit an AI mode value based on byte 22 from the node they just stepped on, but I can't find any evidence to support this in my save files.

 

Another thing is to check if bytes 21 and 22 are separate, if the alien still fires with byte 21 being set to 0 and 22 to 5 (or another value).

 

Some aliens start battle with destination nodes set to the upstairs chambers. I wiped all of my units from a map, except one who I buried in the dirt - Extender let me watch the muton invaders bee-line their nodes, travel up the stairs and fire. So presumably if you want some aliens to frog-march clear across a map from the start of battle, regardless of where they spawn, setting that byte 22 to something non-zero can encourage that.

 

This reminds me of the discussion regarding byte 43 of UNITREF where specific aliens are 'flagged' to scout the battlefield. On Terror Sites it would seem that they will check some specific locations to patrol (namely the nodes with a non 0 value on byte 21), while on XCOM bases those 'flagged' units are set to destroy certain locations on the base.

 

If an alien is confused by his to/from nodes, he won't move or fire. Odd that I can't seem to get aliens to travel between nodes that aren't right next to each other, though they'll happily pathfind over long distances - even up stairs - if the vanilla game asks them to do so. Hmm. There may be some extra memory values involved in the transit that haven't been spotted yet, in addition to the start/end node values I've been playing with.

 

I saw the long pathfinding as well when looking at the TFTD route files. The question would really be to know the function it uses to calculate paths and to determine which are more important.

 

Another idea I had - that aliens might fire from a distance if there's a clear path to the base module with blaster launchers. That way they could be coordinates for blaster bomb firing, which would make more sense than having the aliens move to the module to commit kamikaze afterwards.

 

The crash is definitely caused by aliens shooting at terrain and I can't work out a way to avoid it. Whether or not Seb's loader is used merely determines whether you get a generic Windows error message or one of his debug messages. Just reaching one of the nodes that allows them to fire isn't enough to make it fall over, they have to be able to see and shoot at one of the tiles that are flagged as a target. Game dies as soon as they finish firing. This is probably the cause of some random crashes seen when allowing aliens to take their turn in the course of normal gameplay. Seb's loader states:

 

 

(Quick note for those following along - reading this and this will help you keep track of what the heck we're on about).

 

What I am wondering is if we are causing it to crash with the changes we are making to testing. Or maybe this was a function never fully tested because base defense turned out differently than it was expected. To me it doesn't make sense to keep a function that would crash the game AND repeat it on TFTD. But who knows?

[Volutar]

According game code:

	  if ( route1->Routes1_ref == route2 )
  {
	if ( v_CurrentPlayingSide == osAlien )
	  a_Routes_DAT[route2].SpawnUnitType |= 0x10u;
	if ( a_MisData_DAT_BattleType == bt_XCOM_BaseDefence && a_Routes_DAT[route2].route_field_16 )
	  return;
	v_Selected_UnitRef_addr->Routes2_ref = xc_BF__AI_Set_Patrol_Point(v_Selected_UnitPos_Idx);
	route1 = v_Selected_UnitRef_addr;
  }

This is the only fragment of game code which involves using of 0x16 field of Routes array. This is the part of function called from "patrol" mode processing.

If you have trouble reading code, in human language it means "stop searching for another patrol nodes if it's the BaseDefence mission and field22>0". In short this field mean "flag of point of attraction in patrol mode in base defence mission".

 

And I didn't found any use of field 0x15 in code.

 

This is not empirical, it's just the game code analysis. So I don't have to proof this. If you collect statistics (hundreds of trials) of AI paths, you can find real tends and evidence of "using" of it.

For the moment i'm tending to treat these "evidences" as stochastic events.

[Alienated]

I guess the game crashes because it can't erase your base facility in the Geoscape as you just hacked the tiles in the terrain. I believe the game immediately does the modifications in your base, even before it kills the alien who shot.

[Hobbes]

According game code:

	  if ( route1->Routes1_ref == route2 )
  {
	if ( v_CurrentPlayingSide == osAlien )
	  a_Routes_DAT[route2].SpawnUnitType |= 0x10u;
	if ( a_MisData_DAT_BattleType == bt_XCOM_BaseDefence && a_Routes_DAT[route2].route_field_16 )
	  return;
	v_Selected_UnitRef_addr->Routes2_ref = xc_BF__AI_Set_Patrol_Point(v_Selected_UnitPos_Idx);
	route1 = v_Selected_UnitRef_addr;
  }

This is the only fragment of game code which involves using of 0x16 field of Routes array. This is the part of function called from "patrol" mode processing.

If you have trouble reading code, in human language it means "stop searching for another patrol nodes if it's the BaseDefence mission and field22>0". In short this field mean "flag of point of attraction in patrol mode in base defence mission".

 

Thank you very much.

 

Looks like byte 22 is explained, the only thing missing is what is happening when the aliens try to destroy the base module and it crashes.

 

And I didn't found any use of field 0x15 in code.

 

This is not empirical, it's just the game code analysis. So I don't have to proof this. If you collect statistics (hundreds of trials) of AI paths, you can find real tends and evidence of "using" of it.

For the moment i'm tending to treat these "evidences" as stochastic events.

 

I consider code to be a better proof than 'empirical testing' because, like you said, you can make out 'trends' out of data. Looking at your example of code I can also see that it should be easy to find out if field 0x15 is used.

 

However there are 3 facts left unexplained:

1) On some missions (UFO assault, Alien Base) the aliens deliberately guard some sections of the map (the bridge, the examination room on the Abductor, etc.), on UFO assault that lasts until turn 20 (where they know all the location of your soldiers and are automatically set to Combat mode).

2) The nodes on those areas have field 0x15 with a non-zero value.

3) Both facts above happen also in TFTD - some areas are guarded and nodes have non-zero values on field 0x15.

 

Thus I got 3 questions:

1) What mechanism the AI uses to know which areas to guard? (empirical evidence clearly points it regarding UFOs and there's circunstancial evidence that the AI does this, since Laser Squad and XCOM: Apocalypse AIs do it)

2) If it is not used by the AI to do this, can there be another use for field 0x15 since it is non-zero in so many nodes?

2) If field 0x15 is a completely unused function, why would they keep using field 0x15 to mark specific nodes on TFTD's maps?

 

I guess the game crashes because it can't erase your base facility in the Geoscape as you just hacked the tiles in the terrain. I believe the game immediately does the modifications in your base, even before it kills the alien who shot.

 

With my crash that would make sense but on BB's saved game he's playing a vanilla game on a base so that logic doesn't seem to make much sense.

[Volutar]

1) On some missions (UFO assault, Alien Base) the aliens deliberately guard some sections of the map (the bridge, the examination room on the Abductor, etc.), on UFO assault that lasts until turn 20 (where they know all the location of your soldiers and are automatically set to Combat mode).

2) The nodes on those areas have field 0x15 with a non-zero value.

3) Both facts above happen also in TFTD - some areas are guarded and nodes have non-zero values on field 0x15.

Have you tried to zero these bytes, and did it lead to alteration of routes?

 

1) What mechanism the AI uses to know which areas to guard? (empirical evidence clearly points it regarding UFOs and there's circunstancial evidence that the AI does this, since Laser Squad and XCOM: Apocalypse AIs do it)

SpawnRankType (byte 20/0x14) used for "filtering" patrol routes. Some part (predefined) of each rank of UFO crew marked as "scouts" and patrol through "scout" nodes, not through their actual rank nodes.

2) If it is not used by the AI to do this, can there be another use for field 0x15 since it is non-zero in so many nodes?

I haven't found any use of it. I could miss something. The only way to find this out is to change these values in routes.dat to something else, gather statistics of new routes, and compare it with original.

2) If field 0x15 is a completely unused function, why would they keep using field 0x15 to mark specific nodes on TFTD's maps?

Well, I can presume originally they did have some functons or parts of functions which were using it, but "commented" them out because of some... maybe bugs, or something else.

[Hobbes]

Have you tried to zero these bytes, and did it lead to alteration of routes?

 

With my modified maps, yes. I first saw it with a terrain called Area51 where I wanted the aliens to remain on the upper levels of the buildings where they are spawned and I found out that setting the 0x15 field to non zero on those nodes clearly has an effect on the aliens. With Dawn City you can see it also, specially on the Urban01 map where the nodes by the staircases all have a 1 setting and the aliens converge on those locations.

One simple test is to remove the nodes from the UFO's bridge and compare the behavior of the aliens starting there. I haven't had time so far but I've just discovered Seb's UFO Extender where you can watch the aliens during their turn, so it's much better than my previous method.

 

SpawnRankType (byte 20/0x14) used for "filtering" patrol routes. Some part (predefined) of each rank of UFO crew marked as "scouts" and patrol through "scout" nodes, not through their actual rank nodes.

 

I've just looked at the UFOs route nodes and there's clearly movement patterns if you superimposed the values of that byte over the UFO floorplants. (another 'coincidence' is that the value of byte 0x15 is almost always the same of byte 0x17, whatever it means).

But this actually means that some higher ranked aliens won't move from the beginning of the game until they spot an enemy unit if there's only 1 node on the entire battlefield. This happens, but can it be that simple?

 

I haven't found any use of it. I could miss something. The only way to find this out is to change these values in routes.dat to something else, gather statistics of new routes, and compare it with original.

 

Well, I can presume originally they did have some functons or parts of functions which were using it, but "commented" them out because of some... maybe bugs, or something else.

 

I'm going to test a few things more... the idea about byte 0x14 is very interesting because it explains how some alien ranks are always found in certain areas.

About byte 0x15, for instance, the nodes of Medic rank on the Harvester have that byte set as it follows: 1, 5, 5, 7, 2, with the 7 value node being the best one to ambush XCom units (on the other side of the room). But byte 0x17 also has those same values, maybe it is that byte that gives 'importance' to the node not only when spawning but also when patrolling.

 

Questions, questions

[Bomb Bloke]

This is feels obvious now I type it out, but I've done a few tests with node navigation and can now see why I had difficulty getting aliens to travel between nodes that are a long way apart. Through whatever process, the game chooses a node connected to the node UnitRef[69] (0x45) indicates, and pathfinds to that. [69] then changes to that node, and the process repeats until the alien hits whatever node is indicated by [70]. [69] will also update if an alien crosses a node that is not part of his planned path. Hence, when I told an alien to walk from one side of the map to the other then positioned him right next to his destination, the pathfinder got confused because it was trying to send him to a node connected to his "start" point (miles away).

 

Volutar, if I'm understanding that code snippet you posted correctly (and I'm not sure I do), it's saying that if an alien has reached his destination node and that node has a non-zero offset 22, then don't bother to switch to another?

 

This would suggest that there's another bit of code which looks for aliens that have the same value in [69] as they do in [70] after this function runs, and initiates the AI function that makes them shoot at scenery if so (which makes sense, given that I can make aliens fire at valid terrain targets from ANY location if I manually set those two offsets to the same value).

 

Note that if an alien reaches an upstairs waypoint and fails to crash the game (ie he doesn't see any tiles worth shooting at), he'll then start wandering over to another node (probably also an upstairs one). I thought it might be worth seeing what happens if an alien targets a tile and fails to destroy it. Swapped a heavy plasma for a pistol, but nope, still crashes.

 

Did a few more tests. Given that the only nodes I can find in a base with non-zero values for 21 + 22 are the upstairs ones:

 

* Normally, most (probably all) aliens will try to go to an upstairs node from the start of battle. Under usual circumstances the only thing stopping them is your troops, who'll they'll typically end up fighting instead.

* If all nodes in a base have offset 21 (0x15) set to 0, aliens still prefer to target the upstairs ones.

* If all nodes in a base have offset 22 (0x16) set to 0, aliens still prefer to target the upstairs ones.

* If all nodes in a base have offset 21 (0x15) AND offset 22 (0x16) set to 0, most (all?) aliens end up targeting node 255 (0xFF)... regardless as to whether that node actually exists (in my test base, there were only about 211 valid nodes).

 

So something in the code is definitely paying attention to both of those offsets.

[Volutar]

Volutar, if I'm understanding that code snippet you posted correctly (and I'm not sure I do), it's saying that if an alien has reached his destination node and that node has a non-zero offset 22, then don't bother to switch to another?

A sort of, yes.

 

This would suggest that there's another bit of code which looks for aliens that have the same value in [69] as they do in [70] after this function runs, and initiates the AI function that makes them shoot at scenery if so (which makes sense, given that I can make aliens fire at valid terrain targets from ANY location if I manually set those two offsets to the same value).

That not quite right. After getting to destination point (field22>0 & basedefence) there's no patrolling happen. "Try to attack" function gets to work. Normaly it evaluates enemies in shooting range, but it also treats some of xcom tiles as enemies, so they start to shooting, or even grenading.

 

Note that if an alien reaches an upstairs waypoint and fails to crash the game (ie he doesn't see any tiles worth shooting at), he'll then start wandering over to another node (probably also an upstairs one). I thought it might be worth seeing what happens if an alien targets a tile and fails to destroy it. Swapped a heavy plasma for a pistol, but nope, still crashes.

It's a pity I never got aliens killing my base At least I cannot remember.

 

Did a few more tests. Given that the only nodes I can find in a base with non-zero values for 21 + 22 are the upstairs ones:

 

* Normally, most (probably all) aliens will try to go to an upstairs node from the start of battle. Under usual circumstances the only thing stopping them is your troops, who'll they'll typically end up fighting instead.

* If all nodes in a base have offset 21 (0x15) set to 0, aliens still prefer to target the upstairs ones.

* If all nodes in a base have offset 22 (0x16) set to 0, aliens still prefer to target the upstairs ones.

* If all nodes in a base have offset 21 (0x15) AND offset 22 (0x16) set to 0, most (all?) aliens end up targeting node 255 (0xFF)... regardless as to whether that node actually exists (in my test base, there were only about 211 valid nodes).

 

So something in the code is definitely paying attention to both of those offsets.

The thing is.. You better test classic bases, not custom one. I'm not sure if nodelist with all these flags are legit. Game crash means it's not.

movsx   eax, di
lea	 eax, [eax+eax*2]
mov	 cl, a_Routes_DAT.route_field_16[eax*8]; <-----
test	cl, cl
jnz	 short loc_401A7F

To get 100% guarantee of these fields used or not - I have to make a memory break on them in debugger. Plus save of base defence mission (original, not custom) to test on.

If you provide me with such save, I could make this debug run.

--------------

Addition:

		if ( a_MisData_DAT_BattleType == bt_XCOM_BaseDefence )
	{
	  if ( !*(_BYTE *)(field15) && !*(_BYTE *)(field16) && v_BF_CurrentTurn <= 30 )// 
		goto LABEL_36_NEXT_ROUTE; //skip this node
	}

So you were right about 0x15&0x16 bytes. This snippet have 2 appearences in "find next patrol point" function.

It mean both of these fields have to be 0 and it must be <=30 turn to get aliens attracted to these nodes.

And nevertheless first snippet is there and it checks only field16.

 

I may presume they made these 2 fields to keep every alien to his first chosen target, without switching between them.

I wonder if aliens get to the next base block after finishing killing all XCOM tiles in first one...

[Bomb Bloke]

That not quite right. After getting to destination point (field22>0 & basedefence) there's no patrolling happen. "Try to attack" function gets to work. Normaly it evaluates enemies in shooting range, but it also treats some of xcom tiles as enemies, so they start to shooting, or even grenading.

So if they reach a "normal" node, I guess this "try to attack" function doesn't start, and they just keep patrolling?

 

It's a pity I never got aliens killing my base At least I cannot remember.

 

.

.

.

 

The thing is.. You better test classic bases, not custom one. I'm not sure if nodelist with all these flags are legit. Game crash means it's not.

To be clear on this, the game crashes regardless of whether I edit the base/route nodes or not. You've never caught them doing it because of this, and the fact that usually aliens get slaughtered or distracted long before they get the chance.

 

The save game I posted earlier has no base modifications at all, and will always crash when the aliens start shooting. I can produce more saves if you're not convinced the "shoot at tile" function is what's leading directly to the crash.

 

Those last test results I posted involved changing the RMP files and nothing else. I'm not sure what you mean by a "custom" base.

 

You might find this tool handy if you want to do tests of your own, it lets you send an alien battleship to your bases whenever you want.

 

So you were right about 0x15&0x16 bytes. This snippet have 2 appearences in "find next patrol point" function.

It mean both of these fields have to be 0 and it must be

And nevertheless first snippet is there and it checks only field16.

Er, they have to be non-zero, the way I read it? Basically this segment says "if it's a base mission and it isn't past turn thirty yet, then aliens are only allowed to patrol to nodes with both 0x15 and 0x16 set to something non-zero"?

 

Hence if there are no such nodes, then it just keeps skipping them until the "current" node caps out at 255... That fits the observed behaviour exactly.

 

I wonder if aliens get to the next base block after finishing killing all XCOM tiles in first one...

Yes, they would, assuming they aren't armed with a blaster launcher. I removed all the tiles from one block myself. When an alien patrolled up there, he straight away set off towards the upstairs area of a different map module.

[Volutar]

Er, they have to be non-zero, the way I read it? Basically this segment says "if it's a base mission and it isn't past turn thirty yet, then aliens are only allowed to patrol to nodes with both 0x15 and 0x16 set to something non-zero"?

Actually no. "!a" means (a==0), so both these values must be 0 (and it must be <=30 move) to be skipped.

[Bomb Bloke]

Erm, that's what I'm saying - you said "both of these fields have to be 0 and it must be

 

That is to say, don't worry, I understand.

[Alienated]

Heck! Is it then actually a bug? I can confirm the PSX version is free of it because I remember my laboratory or workshop blastered without crashing the program. Another example how the coders could not realise the game design. It is a poor thing when you have to play this and that way not to let the game crash.

[Bomb Bloke]

Affects TFTD CE as well. Works fine in the DOS versions, though (the alien happily blasts away until he runs out of things to shoot - or ammo, those sonic cannon clips aren't very big), so it must've been a mistake made when porting to Windows (similar to the infamous blaster bomb waypoint bug).

[Hobbes]

Works fine in the DOS versions

 

May not be completely bug free, unless that crash I had (I only play DOS btw) that I mentioned was a complete fluke (never managed to reproduce it again, and it was on a Terror Site, not base defense).

[Bomb Bloke]

Didn't test a terror site myself, so anything's possible.

 

When you say you "couldn't reproduce it", do you mean the crash, or getting the alien to fire?

 

My observations and what I'm reading from the code snippets Volutar posted suggests to me that you'll have a hard time getting them to shoot at terrain outside of base missions. The reason seems to be that normally when they patrol to a node, they just keep patrolling to another node; they only go into combat mode when they see one of your units.

 

However, in the base missions, it seems that when they reach their node they should stay locked onto that node (sorta like a guard). But they don't, they go into combat mode even if no soldiers are in sight, and that allows them to start firing at the terrain. Manually setting their start/end nodes to the same value also kicks them into combat, so I'm guessing that is specifically what the game is looking for before it'll have them start churning up the scenery - but I guess the odds of an alien deciding to navigate to the same node directly after reaching it would be pretty low (outside of base missions).

 

(Further tests suggest that they'll usually go back to patrolling before completely destroying a room. And so long as even one tile remains undamaged, you get to keep the module. Whoops. Not very effective, unless the alien happens to have a blaster launcher.)

[Volutar]

This snippet is from "patrol" function, and executed when patrol node is reached in base defence mission.

if (xc_BF_AI_Choose_XcomBase_Tile_at16x16() )
{
 if ( !xc_BF__AI_Firing(target_tile_x, target_tile_y, target_tile_z, 1) )
 {
xc_BF__AI_Moving(target_tile_x, target_tile_y, target_tile_z);
if ( Global______AI_mode != 6 )
  xc_BF__AI_Firing(target_tile_x, target_tile_y, target_tile_z, 1);
 }
}
else
{
 v_Selected_UnitRef_addr->Routes2_ref = xc_BF__AI_Set_Patrol_Point(v_Selected_UnitPos_Idx);
}

So AI obviously tries to fire reachable xcom tile after getting to every node. If there are no xcom tiles in line of fire - it goes further.

[Hobbes]

Didn't test a terror site myself, so anything's possible.

 

When you say you "couldn't reproduce it", do you mean the crash, or getting the alien to fire?

 

It may matter because I just remembered that I was using CE on that crash - I was watching the alien's turn when a Snakeman that was facing tiles that I had edited with the same properties as XCom base decided to do something (which I have no idea, I just remember a weird sound) that crashed the entire game. (I got the message XCOM crashed at dadadadadadada)