Advanced Civ

[f1rpo]

@xyx: Previously reported here by @carp. The next two posts on the subject are here, and this here is the latest one.
Sometimes, rarely, when I order a unit to move by releasing the right mouse button, the order has no effect. It didn't occur to me that this might be due to a Python error. I don't normally have Python error popups enabled, but I'll enable them now.

 

[xyx]

Sorry, should have read the full thread before reporting. Some additional info:
- difficult to reproduce. seems not be tied to a particular unit or tile, but, I believe, somehow occurs when zooming in or out while having the dotted movement line
- probably really related to screen.setHelpTextString( CyInterface().getHelpString() ) since I couldn't trigger the error when outcommenting this line
- did not occur on 97a

 

[keldath]

great 098 almost

 

[f1rpo]

Sorry, should have read the full thread before reporting.

A bug reported in April should generally be fixed or worked around by August, so I wouldn't expect anyone to browse that far back.

did not occur on 97a

carp's report is from 0.97-pre though, so I'm not going to assume that the bug (if it's indeed the same) was introduced after 0.97a.

[...] I believe, somehow occurs when zooming in or out while having the dotted movement line

Interesting. Or maybe the camera still being in motion somehow, i.e. when rapidly giving an order after cycling.

probably really related to screen.setHelpTextString( CyInterface().getHelpString() ) since I couldn't trigger the error when outcommenting this line

I'm guessing that it's really a bug I introduced in CvGameTextMgr::getPlotHelp. Subroutines included, it's a pretty large function, and I hadn't been aware that a crash there is difficult to debug and goes unnoticed unless Python exception popups are enabled, so I haven't been especially careful to write safe code. Difficult to debug because, even with the popups enabled, the debugger won't break when the crash occurs. However, I've found an MSVC compiler option /EHa that allows hardware exceptions to be caught by try-catch. So I can add try-catch blocks in getPlotHelp to narrow the cause down – if and when I encounter the problem myself.

Edit: I've found an error this way, but only using the G key. Perhaps point and click can have the same result (INTERFACEMODE_GO_TO) sometimes; it doesn't normally.

 

[xyx]

A bug reported in April should generally be fixed or worked around by August, so I wouldn't expect anyone to browse that far back.

wow, that's service to the community. I'd never assume a reported bug gets fixed within a couple of months even (or maybe even particularly) for commercial software, let alone for a mod. So let me thank you for your efforts!

: I've found an error this way, but only using the G key. Perhaps point and click can have the same result (INTERFACEMODE_GO_TO) sometimes; it doesn't normally.

That's probably it, I actually meant moving a unit after having pressed the G key.

 

[Leoreth]

Hover text for water tiles now shows "ice-locked" when this threshold isn't reached. [advc.030] Screenshot

Very minor comment, but it seems that the Civ4 UI has a convention of capitalising its display entries. So it should be "Ice-locked", I would even prefer "Ice Locked", but both appear to be valid.

 

[f1rpo]

That's probably it, I actually meant moving a unit after having pressed the G key.

Great, I think so too. As for my own observation about right-click orders sometimes not getting executed, that doesn't seem to involve any bug. Like probably many players, after selecting a unit, I tend to move the mouse pointer the smallest distance possible to get a go-to cursor via right click at the tile that I want to move to. It's easy to accidentally move the cursor off the target while releasing the mouse button.

Very minor comment, but it seems that the Civ4 UI has a convention of capitalising its display entries. So it should be "Ice-locked", I would even prefer "Ice Locked", but both appear to be valid.

Thanks. I'll capitalize the i; I'd rather avoid giving the whole term the appearance of a novel concept. (Small water areas being unable to produce sea stuff is a BtS rule; the actual novelty is that impassable tiles can separate areas.)

I noticed that there are two screens which cause the pop-ups to re-play: the Civics Screen (F3) and the Religion Advisor (F7). The other screens do not cause this re-playing effect. You can see this in action with the final save, Dingdingdingding.

Entering those screens is supposed to cancel change-civics and change-religion popups. The way I've implemented it, popups are relaunched even when none need to be canceled. I can amend that, but, whenever a popup does have to be canceled, in particular, when giving an order to one of the cities that need orders, all popup sounds will play. Terrible. The DLL only gets to put the popup data – which does not include any audio info – into a list, and the EXE handles everything else. Edit: Actually, the EXE then asks the DLL to launch the popup and that's where the sound is chosen and played; i.e. no real problem after all. So, no straightforward way to suppress the sounds, but maybe there's some, what'd you call it, ... "prosthetic" solution. Otherwise, I'll just have to disable the popup cancellation code either by default or if interface sounds are enabled.

I've watched some games of vanilla BtS on YouTube, where multiple Fish can appear right next to each other. [...]

BtS ignores the distance requirement in normalizeAddFoodBonuses; and that's actually still the case in AdvCiv. I'll change it so that placement rules are only ignored when no food resource could be placed near the city otherwise. (Which is how it already works for normalizeAddExtras.)

When Monasteries are obsoleted by Scientific Method, you can hover over them in the City Screen and see that their output has changed (and any // from the Apostolic Palace, University of Sankore, and Spiral Minaret are no longer shown). But, Monasteries' hover-hints still show +10% after Scientific Method, even if this is actually not true anymore. Even though this is a behavior that is also exhibited in vanilla BtS, maybe that +10% label should be removed after Scientific Method.

I don't think obsolete effects ever get removed from the building hover text. I'm attaching a screenshot from one of Lanstro's saves. Seems OK: Monastery hover text shows all effects, including AP. The building list itself shows only the culture rate, whereas, for Temple, the intrinsic effects and AP effects are listed. As for effects (and building names) getting truncated – displaying the buildings as icons would solve that problem. Yet to be merged from BULL.

I'll look at the revolt saves ... soon.

 

[f1rpo]

Updated the pre-release version attached here. For a manual update, the changed files are the DLL, Assets\XML\Audio\Audio2DScripts.xml, and (unimportant) Assets\XML\Text\Civ4GameTextInfos_advc.xml (two changes: 1 | 2). I've fixed the Go-To mode bug, popup sound bug (not sufficiently tested) and another audio bug, introduced recently, that caused a bunch of sounds never to get played.

 

[xyx]

Got two CTD in the saves attached (immediately after ending the turn), but this is still .97.

 

[f1rpo]

@xyx: Same cause in both: A capitulated vassal breaks free, causing plot groups to be updated for all players. The update disrupts the production in a city of another AI civ (for lack of a required resource), and causes that AI civ to choose a new production order. That choice is based on the attitude toward the vassal, which hasn't properly broken free yet, i.e. has no master (technically: is its own master) and still counts as capitulated. Stack overflow. Seems like a bad idea to let the AI choose a new production order right away; can't expect that to work 100% correctly during other civs' turns. Cities instantly asking for new orders when losing a resource is only needed for humans (to fix an exploit and for usability), so that's how I've fixed it. At least in the year-19xx save, the loss of the resource was only temporary during the plot group update, i.e. production shouldn't have been disrupted. Let's see if that ever occurs for a human civ (not a problem for the AI really) – because that'll be a bit of headache to fix.

I've included the fix for the crash in the pre-release version (link). For a manual update: DLL, Assets\XML\Units\Civ4MissionInfos.xml, Assets\XML\GlobalDefines_advc.xml

Also addressed: the issue with music being inaudible for some players.

[...] Probably due to the changes marked with "advc.004m" in Assets\XML\Misc\CIV4DetailManager.xml. Those changes move the Globe view boundary; apparently, one of them is also responsible for the music volume.

Turns out that the CAMERA_START_DISTANCE (GlobalDefines) affects the music volume; the settings in DetailManager are at least not a major factor. Personally, I use a fairly small field-of-view value because I like playing at a nearly top-down angle, i.e. almost zoomed to Globe view. A high camera start distance works well with this. For players who use a high field-of-view value and then zoom in, a low camera start distance (no greater than in BtS) should work well, not just for the music volume, but also for the proper camera distance at game start or when loading a savegame. So I'm now letting the DLL set the camera start distance dynamically based on the field-of-view value. That's probably not going to be ideal for players who use a high field-of-view value and zoom out far (and I guess play without resource bubbles because those get very large that way). Those players can still set a suitable camera start distance in GlobalDefines_advc.xml.

On the topic of long mission animation times, I've found out the following:

Spoiler :

- Quick Moves already disables the Missionary and Executive mission time; so those are fine.
- Quick Attack disables the air strike animation.
- Neither Quick Moves nor Quick Attack affect the nuke, recon and air bomb missions.
- The aircraft animations aren't much of a concern because they take effect immediately without blocking the UI.
- "No Particle Effects" is responsible for hiding the nuke explosion; I don't think any other option affects it.
- Animations of enemy nukes don't seem to be working at all, at least not for more than one nuke per turn. The camera doesn't move, so it's just rumbling and waiting.
- What blocks the UI is the delayed death of the nuke unit, which lasts until the mission time has passed. Killing the unit earlier cuts the animation off.
- The death of the nuke unit also ends the air recon (visibility) effect of the nuke.
- Seems like an animation can't be played in the fog of war; insofar, the recon effect is necessary.
- Shortening the mission time speeds an animation up. The audio plays at normal speed. (Though it may not play at all depending on the camera distance.)

My changes so far:
• I've reduced the recon, bomb and air strike mission times a little because the animations are kind of distracting and look a bit more realistic to me when played faster. No option needed for those I think.
• Play a 2-sceond animation for the active (human) player's nukes – essentially just the sound and a camera rumble – when Particle Effects are disabled. I haven't added a separate option for now, but might do so along with a bunch of other BUG options that I still want to add. The 2 seconds still allow the player to scout out enemy unit positions revealed by the nuke. Perhaps I'll remove the (rather illogical) recon effect eventually; players could then still see the animation when nuking a visible tile.
• Play an even shorter (1 second) animation for enemy nukes; regardless of options.
• When playing with the full animation, it would be nice if unit cycling were to continue after 2 seconds. This probably could be implemented, but seems like too much effort.

 

[Elkad]

That's probably not going to be ideal for players who use a high field-of-view value and zoom out far (and I guess play without resource bubbles because those get very large that way). Those players can still set a suitable camera start distance in GlobalDefines_advc.xml.

That's me. FoV 70, and zoomed out to straight down. (last click before the globe switch). I only toggle bubbles briefly (and am endlessly annoyed that the forced bubbles take so long to disappear - I'll click the log if I want to know where my copper popped up).

So what value should I be putting in global-defines?

 

[f1rpo]

@Elkad: If I understand the DetailManager settings correctly, then the Globe view boundary is at a height of 7200 er... units. So one zoom level below should be 6000-something. Perhaps going another level lower is better because it'll look less strange at the start of a new game. The 5400 that AdvCiv had used so far should've worked OK; perhaps was a bit too low for you. Currently, with FoV 70 and the dynamically chosen cam start distance (2100 – pretty close to the CAMERA_START_DISTANCE=2200 that BtS had used), zooming out makes the music almost inaudible for me. Maybe I'll have to add a widget to the BUG menu after all. A dropdown menu I guess: "Default cam distance" – "dynamic", "close" [2200], "medium" [?], "far" [?]. Easier to handle than a slider or text box. "Default" describes better what the setting does than "starting."

I'll see if I can also add an option for disabling message location indicators.

 

[Elkad]

I'll see if I can also add an option for disabling message location indicators.

Adjustable timer would probably be better. The problem isn't that they pop up, it's that they hang around too long. Heck, some people might want to set them to something silly like 2 minutes. I'd be happy if they went away in 1-3 seconds instead of whatever the current timer is.

 

[Elkad]

Uh, I don't have any combat noises on 98pre3
Yes I checked my volume levels.

Edit - NVM, your update in #791 fixed it.
But now my scout on auto-explore isn't stopping to heal. Well, he stops sometimes...

 

[f1rpo]

Adjustable timer would probably be better. The problem isn't that they pop up, it's that they hang around too long. Heck, some people might want to set them to something silly like 2 minutes. I'd be happy if they went away in 1-3 seconds instead of whatever the current timer is.

I think they hang around for as long as the message is on display. (Haven't tested it.) That duration can be changed by adding

<Define>
   <DefineName>EVENT_MESSAGE_TIME</DefineName>
   <iDefineIntVal>10</iDefineIntVal>
</Define>

to one of the GlobalDefines files (and then reducing the value). I'm not aware of any separate timer for the indicators.

But now my scout on auto-explore isn't stopping to heal. Well, he stops sometimes...

Oh. I changed that as an AI tweak (already in v0.97 I think). Unless the unit happens to pass through a friendly city, it doesn't heal at all when it takes longer than 3 turns so long as there's still exploring to do; and heals for at most 2 turns when having 0 tile defense (but doesn't seek out high tile defense either). I didn't think of human auto explore. Probably better to heal fully then; if exploration was urgent, it probably wouldn't be automated.

Uh, I don't have any combat noises on 98pre3
Yes I checked my volume levels. Edit - NVM, your update in #791 fixed it.

Seems that all audio except the interface sounds is affected by the camera start distance.

 

[Elkad]

On the subject of timers, what speeds up the combat messages (specifically, the delayed strings of "flanking damage" messages). Same one? Or is it waiting for the sound effect?

 

[crullerdonut]

On the subject of sound, is there any possibility of limiting the number of sounds played at once? Using stack attack with many units is a recipe for awakening one's neighbors and blowing out one's speakers.

 

[f1rpo]

The flanking combat messages are displayed (via the EXE) with the "bForce" parameter set to false. Apparently, this is responsible for the delays in between messages. (Though they appear in the Event Log immediately regardless of bForce.) I don't think the sound adds to the delay. All (most?) other combat messages are displayed with bForce=true, which eliminates the delay, but results in sounds being played on top of each other (maybe resulting in a higher amplitude through constructive interference?).

Using no sound and bForce=true for non-lethal Flank damage seems like a clear improvement. For killed units, the victory/ defeat sound seems appropriate and bForce=false prevents the sounds from stacking up. Though it would also be easy to play the sound only for the first unit killed.

Doing the same for Stack Attack is not as easy, and, when both sides lose units, it may not make sense to play a single victory or defeat sound. Playing no victory and defeat sounds at all when stack-attacking would be easy enough to do.

In some video by Lain, I've seen him split stacks up before fortifying them (or some other command?) in order to avoid a loud sound. I can't seem to reproduce that problem with AdvCiv.

 

[Elkad]

I think the problem is that if you stack enough sounds, it overrides software volume settings.

I leave the analog control for my speakers on maximum volume at all times (I actually CAN'T turn them down, rheostat failed years ago and I just soldered around it to line level), and adjust relative volume in Windows and/or the application (typically set down in the 5-15% range).
Stack attack (or promotion) with enough units gets past that software limit and I get it at full speaker output.

 

[f1rpo]

I think the problem is that if you stack enough sounds, it overrides software volume settings.

I would imagine that the amplitude set by a multimedia application simply gets multiplied by the OS volume percentage. I guess speakers with a (intact) volume control could and should do something more sophisticated to protect the listener. (But I'm pretty clueless about this.)

Stack attack (or promotion) with enough units gets past that software limit and I get it at full speaker output.

Now that you mention it, promotions was probably what I saw in that video, and, yes, they're still just as loud in AdvCiv. Seems pretty easy to play the sound only once. (It might be kind of nice to play it somewhat louder when a lot of units are getting promoted, but let's keep it simple.)

For Stack Attack, I'm now only playing a sound for the final attack. (A bit inappropriate to play the victory sound when most of the earlier attacks failed, but there isn't really a neutral sound that could be played instead.)