Arrakis.py map script discussion

[Ahriman]

Deliverator; your new Arrakis script (from David's beta) is creating badlands tiles.

 

[Deliverator]

Mmmm, none of my changes should have caused that since I only changed the options around. David's changes only flattened a few mesas.

We should really remove badlands from the XML completely to be doubly sure it won't turn up.

 

[davidlallen]

We should really remove badlands from the XML completely to be doubly sure it won't turn up.

"We" will do that right away. In xml/terrain/civ4/terraininfos.xml, search "Badlands":

		<TerrainInfo>
			<Type>TERRAIN_TUNDRA</Type>
			<Description>Badlands</Description>

Go to the start of the TerrainInfo line, and delete from there to the matching </TerrainInfo> line. No other changes should be required.

@ Ahriman, do you actually make any of these temporary xml edits, or should I stop giving the details?

@ Deliverator, I guess it should be ok to delete the badlands dds files from the terrain/textures directory, right? badlandsdetail, badlandsgrids, badlandsblend?

EDIT2: Don't make the xml change! The changes are not so simple. TERRAIN_TUNDRA is used in multiple other files.

 

[Deliverator]

@ Deliverator, I guess it should be ok to delete the badlands dds files from the terrain/textures directory, right? badlandsdetail, badlandsgrids, badlandsblend?

Yes, safe to delete. In fact for 1.6 the textures root directory can be emptied out, the subdirectories blend and detail now hold all the required files.

References to Tundra will need to be removed from a few places, and the mapscripts too. A bit of a fiddly job.

 

[Ahriman]

@ Ahriman, do you actually make any of these temporary xml edits, or should I stop giving the details?

I do them, usually. I won't do this one for a while since I have a game I am testing with badlands tiles in it, and deleting it would break the game I assume.

EDIT2: Don't make the xml change! The changes are not so simple. TERRAIN_TUNDRA is used in multiple other files.

See, procrastination preserves option value.

 

[davidlallen]

Popping the last tangent and returning to the previous tangent, here is an example of Fremen dying young. They are in last place by a huge margin, with a huge space available to expand into. (Blue color at lower left of minimap, can easily expand west)

 

[Ahriman]

Harkonnen Messianists? Hilarious

An interesting thing to test; is Fremen dying young just from lack of having the scout thopter? Or does the sandrider on the settler also somehow stop them from using suspensor transports to transport settlers?
Or is there a different AI for these two units; one is a transport, the other a combat transport?

 

[davidlallen]

An interesting thing to test; is Fremen dying young just from lack of having the scout thopter? Or does the sandrider on the settler also somehow stop them from using suspensor transports to transport settlers?

This is an early game expansion problem, before the suspensor transport is available.

 

[davidlallen]

And, popping back one more tangent to the original purpose of this thread (the mapscript) here is an interesting start position I had.

I guess there are still occasions when the start positions are too close together.

 

[davidlallen]

David's transport loading/unloading changes have meant that a transport unit can't unload if it has zero movement points left ...

If it helps: the transport still has an unload button when it is out of moves, but pressing it doesn't do anything. Transport units no longer have an unload from transport button when the transport runs out of movement points.

I am not sure we are seeing the same behavior. For the unit being carried, (1) loading takes all movement points but (2) you can load if you have no movement points. Unloading is only allowed if (3) the unit being carried has movement points left. It does not matter whether the transport has movement points left; the unit can still unload.

There is one consequence you may have overlooked, and there is one button which appears when it should not; but the above behavior is what I designed and how it works in 1.5.4, 1.5.5, and 1.6.

The consequence of (1) and (3) is that a given cargo unit can not be loaded and unloaded in the same turn. Try this. Load a unit into a transport. Click next turn. Move the transport its full distance. Now unload the unit. The unit is unloaded although the display may not look any different. You can prove this by clicking next turn again, and then moving the *transport*. The (former) cargo unit does not move, indicating that it was unloaded in the previous turn. Do you agree?

The unload action button on the transport is always displayed regardless of whether or not the cargo can unload. That is confusing, and I will try to fix it without breaking anything else; but it does not affect the behavior.

So I think the design and implementation are both correct; you can unload a transport which is fully moved, but you cannot load and unload a cargo unit on the same turn.

 

[Ahriman]

I am not sure we are seeing the same behavior. For the unit being carried, (1) loading takes all movement points but (2) you can load if you have no movement points. Unloading is only allowed if (3) the unit being carried has movement points left. It does not matter whether the transport has movement points left; the unit can still unload.

There is one consequence you may have overlooked, and there is one button which appears when it should not; but the above behavior is what I designed and how it works in 1.5.4, 1.5.5, and 1.6

Hmmm. Ok. It sounds like have misinterpreted. It sounds like the system is working as you designed it.

Then that would suggest that it *is* an AI issue that they aren't unloading transports immediately once the transport is next to the enemy city, but also suggests that an AI that unloaded them and reloaded them *every* turn when they were over land would fail too, because if they load them up at the start of the turn then they will be unable to unload them once the transport moved.

We may need to decide then which is worse; AI that is very vulnerable to having their transports destroyed while the troops are still cargo, or humans exploiting transports.

My ideal design would be:
i) Units can always be unloaded or loaded into transports, no matter whether they have any movement points left.
ii) Unloading from a transports uses up all the movement points left that a unit has *if* and only if it has any left.

That way, you don't have the exploits where a human player can unload a unit, attack with that unit (or unload a worker and have it spend a turn building an improvement), then reload the unit and move away, but you also allow land units to defend the transports while they are over land (by having the AI unload and reload them every turn).

So I think your code is correct, but your design is not optimal.

 

[davidlallen]

My ideal design would be:
i) Units can always be unloaded or loaded into transports, no matter whether they have any movement points left.
ii) Unloading from a transports uses up all the movement points left that a unit has *if* and only if it has any left.

That way, you don't have the exploits where a human player can unload a unit, attack with that unit (or unload a worker and have it spend a turn building an improvement), then reload the unit and move away, but you also allow land units to defend the transports while they are over land (by having the AI unload and reload them every turn).

Getting the exact description seems to be eluding both of us. One goal seems to be to prevent "unload, do work, and move away" in the same turn. Then (i) cannot be what you meant. The second part of (ii) also seems meaningless; if unloading uses up all the cargo unit's movement points, it does not matter how many movement points it had.

 

[Ahriman]

Getting the exact description seems to be eluding both of us. One goal seems to be to prevent "unload, do work, and move away" in the same turn. Then (i) cannot be what you meant. The second part of (ii) also seems meaningless; if unloading uses up all the cargo unit's movement points, it does not matter how many movement points it had.

I did not mean i) OR ii).
I meant 1 AND 2. I agree that the only if is redundant.

But the point is, even a unit that has already moved should be able to unload. That way the AI (or human) could unload its troops each turn to protect its transports.

Being able to load and unload in the same turn is only a problem if the unit can move or attack or build after being unloaded. I can't see any obvious exploits from being able to load and unload when unloading takes up all movement points.

It *seems* like your code already removes movement points from a unit after it unloads. Or at least it sometimes does.

 

[Ahriman]

I think we should probably either remove the outer Dunes or remove the ability to build outposts on Dunes; the human player can build outposts on the Dunes to get some culture and harvest extra spice, but the AI doesn't know how to do this.

 

[cephalo]

I think we should probably either remove the outer Dunes or remove the ability to build outposts on Dunes; the human player can build outposts on the Dunes to get some culture and harvest extra spice, but the AI doesn't know how to do this.

Aw man, I worked hard on those dunes. Great Job on the mod everyone! Sorry I can't help out more.

 

[Ahriman]

I'd be fine with removing the outposts and keeping the dunes.

 

[Deliverator]

I'd be fine with removing the outposts and keeping the dunes.

This is a simple XML change and is probably the best option.

 

[cephalo]

This is a simple XML change and is probably the best option.

Actually the best option would be to teach the AI how to use the outposts. Don't be afraid! Understanding the AI is a matter of reading the code for a weekend. No big deal.

I shall now run and hide!

 

[davidlallen]

Understanding the AI is a matter of reading the code for a weekend. No big deal.

I bow before your genius. I have spent a weekend reading *one AI function* (AI_foundValue) without success.

 

[Deliverator]

I think outposts on Dunes are wrong from a theme perspective anyway. Shifting sand is not the best foundation for a base.