Version 1.7 feedback

Please visit the download page again. I have added instructions for any player who is having trouble with the installer failing to detect your BTS 3.19. Hopefully we will be able to fix the installer at some point.

Ah, nice! I extracted it with 7zip as you mentioned earlier though and everything seems to be working, so I don't think I'll need to redownload.
 
the advantage of Cvgame is that it is run after ALL units have moved. So you prevent cases in which a transport unloads before other units move to escort the transport or destroy threathening units.

I am not an expert, but CvPlayerAI::AI_unitUpdate does not take any arguments such as a unit, and it appears to loop over all units. So by placing my code at the end of this function, I am pretty sure it is also called only once, after all of the player's units have moved.

Thanks again for your help! This had been a big limitation of the AI.
 
The BG *should* be forbidden to found Technocracy. So should Fremen.

Ah-ha! Documentation bug. In the code, BG are forbidden to found Technocracy. So the code is working correctly. However, in my implementation the help text and pedia text are written manually instead of generated from the actual game data, and it appears I left this out of my help text by accident.

(a) I will definitely fix the help text, thanks for finding the bug. (b) I should really change the implementation a little, to avoid manually written help.

anotherpacifist said:
Inquisitors seem not to be able to do anything except move around.

It sounds like something has gotten left out, or merged improperly, when bringing the new version of Revolutions Inquisitor modcomp into Dune Wars. I will check.
 
So by placing my code at the end of this function, I am pretty sure it is also called only once, after all of the player's units have moved.

Isn't that what we want? At the end of the AI player's turn, after all its stuff has moved, it unloads any of its transports that have threatened units near them.

I had another thought on this too.
Suspensor transports have double-move in desert (from suspensor transport promotion), and so automatically stick on desert tiles until they make landfall thanks to pathfinding.

But carryalls don't do this. So carryall pathing could take them over land much earlier, which will potentially make the need for an If_threatened check more important.
 
I am not an expert, but CvPlayerAI::AI_unitUpdate does not take any arguments such as a unit, and it appears to loop over all units.
Thanks again for your help! This had been a big limitation of the AI.
there are so many update functions I thought you meant the one in CvUnitAI. That CvPlayerAI::AI_unitUpdate sounds pretty good to me.

So by placing my code at the end of this function, I am pretty sure it is also called only once, after all of the player's units have moved.
that's not 100% true. The function loops through all selectionsgroups and calls AI_unitupdate for them, but will break if one of them returns true and the game will call CvPlayerAI:AI_unitUpdate later again. Probably won't happen in dunewars.

In general the Turn functions run only once, the Update functions might run several times
 
Suspensor transports have double-move in desert (from suspensor transport promotion), and so automatically stick on desert tiles until they make landfall thanks to pathfinding. But carryalls don't do this. So carryall pathing could take them over land much earlier, which will potentially make the need for an If_threatened check more important.

I don't understand your point about "sticking" on desert tiles. Yes, the suspensor unit's move rate decreases when it goes over land. But why would it "stick" on desert tiles?

Although it is not obvious from the text description in our conversation, the code segment posted by sephi does check danger:
Code:
int iOurDefense = player.AI_getOurPlotStrength(pLoopUnit->plot(), 0, true, false);
int iEnemyOffense = player.AI_getEnemyPlotStrength(pLoopUnit->plot(), 4, false, true);
if (iOurDefense < iEnemyOffense) bDanger = true;
I don't know much about the AI code so I can't say what they do, but by the function names, this seems a much better check than the simple "is an enemy unit in range" functions I had considered before.

}
 
I don't understand your point about "sticking" on desert tiles. Yes, the suspensor unit's move rate decreases when it goes over land. But why would it "stick" on desert tiles?

Sorry, casual language use.

Imagine the following: there are three moderate size islands in a row, A B C, each with significant desert gaps between them. Imagine that the civ on island A is invading the civ on island C, that both A and C have open borders with the civ on B.

Imagine also that island C has some very jagged borders, with lots of jagged rock outcrops, and fingers of desert (like fiords) going in towards its cities, and imagine that its cities are several tiles from the coast.

If A has a stack of suspensors, their pathfinding will guide them around island B, staying on desert tiles, because they move faster that way; each desert tile only takes half a movement point. And then their pathfinding will move them up the desert fiords, leavnig the desert only when they arrive right on the doorstep of their target city.
So there are no particular issues with worrying about them being on land before they get to their target.

In contrast, a stack of carryalls will fly directly over B, potentially risking being attacked by any ground units there, and then will fly over the rock outcroppings in the most direct route to get up to the target city on C (rather than following the desert fiords), again exposing them to enemy ground units.

I guess the point I am trying to make is, the fact that some transports (carryalls) take a route that flies them over a lot of land tiles means that a simple function that unloads as soon as they are over land, or as soon as they are over land with a single enemy unit nearby, could end up dumping them on island B, or could end up dumping them on island C a long way from their target city.
[It could be even worse if island B is connected to island C by a narrow pathway somewhere else, so they are technically on the same continent).
Hence, we ideally need some knid of function that will force unload only when there is a signicant number of enemy units nearby.
Hopefully the code above from Sephi will do this.
Depending on how iOurDefense and iEnemyOffense are defined, we might want to bias this a little more towards danger.
Eg: if (iOurDefense + X < iEnemyOffensve) bDanger = true;
for some X
 
Sorry, casual language use.
OK, got it. Suspensors will "prefer" desert tiles while carryalls won't. I understand your point; let's playtest what we have. Sometimes there are effects we worry about from a theoretical standpoint, which wind up not bothering us during actual play.
 
@ghor

I'd really like to know if the new logic in the install script I have for LoR fixes your issue ghor. Could you try downloading and installing Legends of Revolution. This will let davidlallen and I know if the new install script fixes the problem you had. If the 116MB download is too much I can package you up a small like 100KB installer to try to test the updated logic on. You're just the only user that has confirmed an installation issue, and I'd really like to know if this is fixed or not.
 
Thanks I just repeated my reply to ghor but addressed it to arkham. Hopefully one of them responds and I can then be sure whether or not the new logic works. On the plus side his was a Steam Complete install as well, so it's likely only that single installation varient is missing the regular BtS registry key.
 
The folder structure for Steam game installs different from the standard box installs. I have Steam Civ4 BTS installed on another PC so I can try the installer on that, but I wouldn't be surprised if there is a general problem with Steam installs.
 
That would be nice for you to test LoR's installer then. First ensure that the DW installer messes up though. If you get an abort with the DW installer, but not with LoR's, please let me know what messages you get durring installation; actually screenshots would be nice here. Finally if this is the case we may need to have you go digging in your registry so that we can add an apropriate registry check to the install script for Steam installs. Thanks again for looking into this Deliverator.
 
The 1.7 Dune Wars installer does fail on my Steam install. The full path to my mod directory is C:\Program Files\Steam\steamapps\common\sid meier's civilization iv beyond the sword\Beyond the Sword\Mods\Dune Wars if that is any help.
 
It's good to know that it fails, we can now be certain the Registry for Steam Complete is different then other configerations. Now what I really need to know is if the logic in the LoR installer works correctly for you.

As for the paths, that's not useful. We need to use registries for the installer so that it works on different computers. What we really need to know is what the Registry is for BtS on a Steam Install. Do you know how to check your computer's registry to retrieve it? Unfortunately I do not, if you and davidlallen don't know, I'll PM ori and have him give us directions.
 
I have no interface at all and can't turn it on with Alt+I or Ctrl+I. It is nearly impossible to change production, look unit name and statistics, find correct shortcut command.
As i see on screenshot, everything is fine with interface.
Can smbd help me to fix my problem?
(I have localized russian version of the game. Can it be the problem? Other mods are OK)
 
I have no interface ...I have localized russian version...
Download this. Extract it in the BUG folder of Dune Wars Python files, say yes when it asks you if you want to overwrite (if it doesn't, you're extracting it in the wrong place).

@Deliverator
Are you going to test out LoR's installer? Are you willing and able to check your registry?
 
Per here: http://forums.civfanatics.com/showpost.php?p=8730947&postcount=396

OK, so aparently Steam just messed up when they wrote their 3.19 patch for their version of complete. Steam Complete still has a BtS registry, but it doesn't have a 3.19 key when patched, which all other versions do :mad:

@Deliverator

You're the only developer here who has a Steam Complete version, so we really need your help. Could you please look at your Registry and see if there is any valid test we can set up to figure out if your copy of BtS is updated to 3.19, or at least tell if it's steam version. Hopefully Ori or EF can give decent directions on how to search the registry, as I don't know. But in order to get the installer to work correctly there needs to be a way to find out, from the registry, the version number or that it is a steam copy.

Edit: Also I'd like to move further discussion on the installer to here: http://forums.civfanatics.com/showthread.php?t=340727
Though there isn't much discussion. It now just comes down to Deliverator and his registry.
 
We have a hint for mulitplayer game oos problem.
The oos message came right after anyone from us attacks smuggler unit.
 
Another problem, this time ingame so I think this is the appropriate place to post:
When starting a game:
Spoiler :
screen1.bmp

And ingame it hides all of my "turn" messages with this :
Spoiler :
screen2.bmp


First of all, I found the file in question but it's in the Dune Wars folder, second why is it even looking at it in a folder named after an older version of the mod? Any ideas? The easiest thing is to just create a folder with the desired name and just paste the file from the proper Dune Wars mode...

P.S. Sorry for the big images, fresh window installed and no Photoshop installed currently...
 
Back
Top Bottom