Advanced Civ

i have 0 c++ knowledge,
i know python and jscript...
so i dont know what everything means.
Noted.
[...] anyway, know that i deeply appreciate and of your assistance :)
It's interesting for me to see which of my changes are causing conflicts and if this whole undertaking is feasible at all. However, since I don't expect anyone else to follow this closely, I've started a private "conversation" with you. I can invite additional people if anyone would like to chime in after all, and when it makes sense for some particular issue, we can of course still discuss that here in the thread.
 
Just a quick update from me. After a very busy April \ early May I have finally found the time to start implementing the new combat mechanics as described in item 1): https://github.com/f1rpo/AdvCiv/blob/master/future gameplay changes/readme.txt

So far I've implemented the attack limit rule and I am working on the limited defender set (which is surprisingly tricky and has a number of special cases!. We may do with a discussion at some point...). The limited combat rounds feature was just a trivial merge from WTP, but I still have to get the odds right (which is tricky due to first strikes not being in WTP and I had to account for that. Note that I want to remove FS anyway to make way for the C4R collateral\range mechanic eventually).
I do not intend to implement the limited free healing ( which really is a concealed supply mechanic in my view) for now since it is not clear to me how it would work.

I will probably add some other mechanics as well:
- In Koddy I already implemented "collateral target scaling" which increases the number of collateral targets based on the number of defenders. This is a nerf to defender stacking which works well in my opinion. Besides it was a quick fix to implement a counter to "dense" stacks.
- C4R collateral\range
- Possibly the BTS Defense \ Realism Invictus stack combat strength penalty.

I've added a new tab to the bug options where parameters like max combat rounds, attack limits etc can be altered "on the fly" to allow people to experiment.

At this point it is all mechanics, so no specific AI support. I think we should put that on hold until we have decided on the actual mechanics that we want to move ahead with.
 
Last edited:
Just a quick update from me. After a very busy April \ early May I have finally found the time to start implementing the new combat mechanics as described in item 1): [link]
I had (of course?) not expected you to do all the legwork for these prototype implementations. I could jump in whenever you upload the code that you have. Nor did I expect my (tentative) favorite ideas to be implemented first of all; not that I'm complaining ...

I've gone through my slightly dated notes about the combat rule changes; here's what might still be relevant (though most of it is probably not relevant at this stage):
Spoiler :
Defender set:
* Subsets data:
Probably a bAvailable flag at CvUnit that gets updated once per turn. To save computing time, one could instead randomize the available units on the fly when hovered over or attacked. Would then have to use a hash value of the turn number and e.g. of the plot index so that availability is unpredictable but doesn't change throughout a turn.
* Subset selection:
Never select civilians. Damaged units should be less likely to be selected. Outdated/ weak units also less likely? May not want them to be employed as meat shields. Special treatment for fast units would make sense, but better to consider that separately.
* Collateral damage:
Damage the available units first. Meaning that, if the maximal number of collateral targets is smaller than the maximal number of available units (4?), then unavailable units can't be affected by collateral damage at all.
* UI:
- Availability info should be visible only to the stack owner's rivals; don't want the owner to move his or her units around to manipulate availability.
- Rivals see the unavailable units grayed out and available units listed on top in the tile hover text.
- The center unit, whose 3D model is shown on the main map, should be chosen from among the available units.
- Message when another defender becomes available after a human attack: "A Roman Rifleman has filled the ranks of the defenders."
- The combat log should arguably document the initially available units and each unit that becomes available subsequently.

Attack Limit (just two vague alternative ideas):
* Limit the attacks per turn against a single tile to some function of stack size (S), e.g. max{1.5 * S, 4} or S+4. This probably disadvantages large stacks of weak units too much.
* When a unit dies that has fought for the second time this turn, the "weakest" unit in the same stack retreats. Retreated units stay where they are, but can't be attacked anymore this turn, making it impossible for hostiles to enter the tile when all defenders have retreated.

Limited City and Fort capacity:
* Should perhaps apply to all defensive modifiers; can't fit arbitrarily many soldiers into a natural defensive position either.
* Formula for the capacity limit (L): For cities, something based on population; otherwise a flat limit or based on the era number. Don't count units that can't receive defensive bonuses.
* Simple rule: No defensive bonuses so long as the stack size exceeds L.
* Alternative: If L is exceeded, multiply the defensive bonus by the ratio of L divided by the number of defenders.
So far I've implemented the attack limit rule and I am working on the limited defender set (which is surprisingly tricky and has a number of special cases!. We may do with a discussion at some point...).
For discussions, we could start a thread in "Creation & Customization" at any time. To my knowledge, that's the place for discussing mods that don't have a release yet (although that subforum hasn't been used for that purpose in a long time). I could create a thread and quote all the relevant posts from this thread; but I reckon you'd rather write an introduction/ blurb yourself. Which isn't to say that we can't just continue to use this thread for the time being ...
I do not intend to implement the limited free healing ( which really is a concealed supply mechanic in my view) for now since it is not clear to me how it would work.
It's not clear to me either; I have notes for various approaches. I hope once I can experiment with the things your're implementing now, it'll become clearer to me which healing change is needed if any and what for.
I will probably add some other mechanics as well: [...]
Great. I'd be happy to try those out as well (without having to acclimate to all the other C4R or RI changes at the same time).
I've added a new tab to the bug options where parameters like max combat rounds, attack limits etc can be altered "on the fly" to allow people to experiment.
That sounds very practical. One could even leave it in the mod permanently for single-player mode. Edit: Now I remember where I've seen that before: in RevDCM.
At this point it is all mechanics, so no specific AI support. I think we should put that on hold until we have decided on the actual mechanics that we want to move ahead with.
Fully agree. Also any special interactions can hopefully be put off, and, while some UI support is going to be needed, bits of hardcoded help text should suffice at first.

Regarding AdvCiv: I'm now almost through with a pass through all frequently changed C++ files, updating my older code and making various style changes to BtS and BBAI code to improve readability (for myself at least). After this, I intend to give any nonfunctional changes a long rest. Also, I've found out that my old Notebook actually has a Pentium processor, so I should be able to work out the potential multiplayer issue with floating-point nondeterminism.
 
Last edited:
Impressive amount of work!

I really like that there is still advanced dll-modding of civ4 ongoing .

Also very good manual and documentation.

I was wondering whether there are any planned changes to the interface to better adapt it to modern screen resolutions? Mostly it is problematic in Sevopedia and in some in-game screens, for example could a Platypedia type interface be integrated? Or is BUG a limitation in that regard?

On the wishlist would also be an incorporation of Dales combat mod

Again thanks for all the work you have commited
 
@MatteM
Dale's combat mod (DCM) has some interesting components that we should consider for the combat mechanics overhaul that we're planning (and started implementing). It makes sense to me that artillery and battleships should have a farther range than the adjacent plot since roughly at the same time we have fighters and bombers with a range of 10 plots!
Ranged bombardment should strictly be a late game feature though to make modern combat more interesting and to not "unbalance" the earlier ages.

On a related note I am indenting to add the Civ4 Reimagined (C4R) range\collateral system where for instance archer units act as collateral units with a range of 1 plot. The attacking archer gains a combat bonus when attacking units with a lesser range but it is still likely to suffer some damage since it actually engages in regular combat, albeit with a bonus and a combat limit. Note that C4R removed the catapult and trebuchet units but I think that they should remain in the game as specialized\powerful city attackers and for balance be worthless in the field since archers now become the default collateral damage capable unit.

This system fixes the main issues with DCM \ Archer bombardment for pre-artillery units: 1) No risk of taking damage or even dying when attacking 2) Need a separate accuracy stat rating to avoid every ranged strike from hitting 3) Violates "flavor and realism" due to the scale of the map.
 
Last edited:
@f1rpo

Thanks for sharing your notes with me. I now see that we have a lot to discuss concerning the combat mechanics so I thought I'd start out be explaining how I implemented the attack limit (perhaps combat width is a better term):

The limit is applied between pairs of adjacent plots and not to the target plot itself.

My rationale is the following: The attack limit represent the attacker's logistical limitation on maneuvering when confronted with the enemy defensive line. The real limit is the surface area of the attacker's line vs. the defender and hence it would not make sense to me to let the target plot be the only consideration. Since the attacker may attack up to 8 adjacent plots, it makes sense that they would distribute the troops so that they would be practically scattered across all of these potential fronts. In other words, the attacker should be able to muster attacks versus several adjacent plots but not be capable of concentrating their full force on a single plot.
Another motivation for the limit to be applied to plot pairs is that it incentives the attacker to split up their unit into smaller stacks (to maximize the attacking "bandwidth") which in turn creates tension with the defender set limit. This should lead to more interesting combat behavior such as besieging cities from several adjacent plots and even make combat more about controlling land than creating a single SoD and then parking it on a plot next to the target city.

If the attack limit is n, then any given tile can be the target of a maximum of 8*n attacks assuming that the attacker has fully surrounded the plot to be attacked. For now the limit is a (hard) constant but I am considering to instead let it be a (soft) limit and allow more than n attacks per turn but in that case apply a combat penalty for attacks that exceed n (the combat "width" for this plot pair). This is actually the reason for considering the RI stack size combat penalty mechanism. This would avoid the issue that you raised about fortified cities\forts on choke points being practically unassailable.

Her are some thought about extending this mechanics:

- Certain Paradox games have the concept of a front and back line. We could allow ranged units (e.g. archers\siege) units to be considered part of the "back" line and allow them to attack without affecting the limit or have a separate limit for them.

Implementation details:

Every plot has an m_attackLimit[NUM_DIRECTION_TYPES] array. When an attack has completed, the attack counter for the orginating plot (indexed by the array) is incremented. The attack counter is then reset on every turn.
 
Last edited:
I was wondering whether there are any planned changes to the interface to better adapt it to modern screen resolutions? Mostly it is problematic in Sevopedia and in some in-game screens, for example could a Platypedia type interface be integrated? Or is BUG a limitation in that regard?
hi there,
im currently converting my Doto mod to be adv based mod. i have already did a merge with platypedia (without adv added changes to bug , though i hope to do so).

Dales combat mod
i never realy trusted dale code, since ai problem and lack of ai code for it plus multiplayer instability.

On a related note I am indenting to add the Civ4 Reimagined (C4R) range\collateral system where for instance archer units act as collateral units with a range of 1 plot. The attacking archer gains a combat bonus when attacking units with a lesser range but it is still likely to suffer some damage since it actually engages in regular combat, albeit with a bonus and a combat limit. Note that C4R removed the catapult and trebuchet units but I think that they should remain in the game as specialized\powerful city attackers and for balance be worthless in the field since archers now become the default collateral damage capable unit.
i didnt realy like the Reimagined ranged system. i much rather have the vanila civ system or a mix of dale mod or - the civ air range for land units style .
 
i didnt realy like the Reimagined ranged system. i much rather have the vanila civ system or a mix of dale mod or - the civ air range for land units style .

So you think it's preferable to let archers\catapults range bombard without any risk of suffering damage \ sustaining return fire ? I think this is just broken but that it just my opinion.

Besides, the C4R system is about more than that. It's also about enabling early collateral capable units to repel a rush since it takes a fair amount of time to tech to catapults in "stock" BTS.
In Koddy (my K-Mod balance overhaul) I added a single new unit for this purpose, the scorpio ballista which is a str4 collateral unit enabled with BW\Archery to allow players to defend themselves during the early game. I gave it a combat penalty vs. cities to avoid it becoming "a too early" catapult.
 
Last edited:
So you think it's preferable to let archers\catapults range bombard without any risk of suffering damage \ sustaining return fire ? I think this is just broken but that it just my opinion
well, these units should be low on attack power, and have ranged power and defense power. i like the air ranged option.
of course , each has hes own thoughts, i also have low play exp in civ4, mostly ...modding :(. i loved dale combat ranged, but it had ai issues and multiplayer. i would welcome a functioning system of that sort, more than C4R.

did you publish it?
 
@f1rpo On the limited defender set

Initially I wanted to create the set "on the fly", but I realized that hoovering over an enemy defender set in CvGameTextMgr::setCombatPlotHelp would lead to OOS issues. Sadly I did not realize at the time that your hash idea would have solved that!

So instead I then went ahead and implemented the following:

Maintain a defender set (i.e. vector) of available units per plot that is:
- Randomly generated on every turn i.e. CvPlot::doTurn() (As an alternative the list could be created at the end of every player's turn though)
- Regenerated \ updated any time CvUnit::setXY() resulted in a unit being added to or removed from the plot. If a unit died, the list would also be regenerated.

CvPlot::getBestDefender() was then changed to query the defender set rather than iterating through CvPlot::headUnitNode()

However, I quickly ran into some *ahem* interesting issues:

1) What if units from different domains were present. This applies to cities\forts where it is possible to have land,sea and air units stationed.
2) Some units should probably never contribute to the defender set: units in a transport (e.g. cargo), always invisible (spies), civilian units like workers, missionary (would a check against canDefend() be enough?)
3) Air units have their own stack limit so they should probably be excluded as well
4) What about invisible units like submarines that are visible to certain units classes (e.g. destroyers) ?
5) What if there were enemy units from 5 teams and the defender set limit was set at 4. We could then have a situation in which at least one team would not be represented in the defender set which would cause confusion for the AI since getBestDefender() could be called with a wide variety of parameters (i.e. "filters") and I would have to ensure that the defender set would always return a valid subset as if getBestDefender did not use the defender set. Otherwise we'd confuse the AI or create subtle bugs.

To solve this, I came up with the following:
Rule: The defender set must include one representative of any team's unit that is on the plot.
If team A,B and C have units on the same plot. The defender set must include at least one unit from these players. If A,B,C,D,E has units on the same plot, one unit is selected from each player. This is the only exception to the rule about having n defenders. It matters not which subset (or all) is at war with the player.

Without this rule it would be possible for the defender set to be composed entirely of units that the attacking player is not at war with which could confuse the AI and cause other weird bugs.
(Note that we would need other criteria like the list must also always contain at least one hostile unit that can defend)
 
"Limited capacity of cities and Forts: No defensive bonus while stack size exceeds capacity."

Since I didn't want to just simply eliminate the defensive bonus once the stack exceeded the threshold I decided to create a "rank set" and then apply the defense bonus to only the first n best defenders in the set.
However, this turned out to be impractical due to the way getBestDefender() works.
For this to work we'd have to do multiple passes, and then remove the defensive bonuses from the "leftover" defenders after having drawn out the first n "top" defenders. This became so complicated that I decided to completely abandon this approach.

Fortunately I had a bit of an epiphany at that point :p since I realized that in principle cities should not be worse off than any random plot with a defensive bonus.

For example, consider a non-city plot. In this case the defender set is limited but all the units still eventually receive the defensive bonus, if applicable and capable while on the other hand, cities and forts would stop granting a defensive bonus if the defenders exceeded the threshold. I then determined that the defensive bonus should be dealt with in a uniform way. If the stack size exceeded the threshold I would scale down the defensive bonus ( capped at 0 at this point, but we could consider to allow it to become negative) based on the number of excess defenders. This threshold could then be modulated by city infrastructure like walls or plot infrastructure like a fort.

This rule would also help with the "hostile SoD camping on a forested hill adjacent to our city" problem by simply reducing the defensive bonus bases on the stack size. Cities would have a larger threshold so that defending inside cities would always be better than being in a random plot.
 
@devolution: Thanks for all the info and rationales. I'll take another day to digest that.

I was wondering whether there are any planned changes to the interface to better adapt it to modern screen resolutions? Mostly it is problematic in Sevopedia and in some in-game screens, for example could a Platypedia type interface be integrated? Or is BUG a limitation in that regard?
Enlarging the Foreign Advisor is on one of my to-do lists, and I'd like to include Platy's Religion and Corporation Advisor screens, which fill the entire screen. BAT already has a wider Foreign Advisor screen, so that shouldn't be too difficult to adopt. It's needed mostly for the Glance tab, which currently can't fit all 18 players and doesn't have a horizontal scrollbar either. The other tabs are going to look a little worse I think because there won't be anything to fill the wider panel.

Enlarging Sevopedia is a good idea. I see that you've already experimented with that (link). I guess some other values will have to be adjusted, also to make the lists on the left a bit wider. I'll look into that.

Alternatively, I could adopt PlatyPedia from keldath. That would most likely be more work because I've already customized Sevopedia a little bit for AdvCiv and there are some things I'd want to change about PlatyPedia in addition, like removing some of the menus and categories (too much work to keep that up to date) and adjusting icons and colors.

As for the Religion and Corporation Advisor, the BUG Religion Advisor will have to remain optional, and ideally the BtS Advisors too. So making Platy's code optional and extending the BUG menu is probably the main effort here.
Impressive amount of work!

I really like that there is still advanced dll-modding of civ4 ongoing .

Also very good manual and documentation.
Thank you. :)

--
On the floating point issue: I can't get different results on my two machines. Perhaps Athlon 64 X4 and Pentium M use the same precision and rounding; I guess that's good. However, debug builds and release builds do behave differently on the same machine and have arrived at slightly different game states in an Auto Play test after 150 turns. The _controlfp settings don't seem to help here, but might still help when two release builds produce divergent results due to platform differences. For now, I've only added a test at game start that warns players when their machines don't produce the same results (see attached screenshot).

Edit: By the way – a before/after screenshot showing the expanding scoreboard (extra columns on mouse-over) that I've added in late April; to be included in v0.96 (optional of course).
 

Attachments

  • fp-warning.jpg
    fp-warning.jpg
    141.3 KB · Views: 259
  • exp_scoreboard.jpg
    exp_scoreboard.jpg
    193.1 KB · Views: 246
Last edited:
@devolution (and anyone else following the combat system discussion):
Combat width:
Spoiler :
I now see that we have a lot to discuss concerning the combat mechanics so I thought I'd start out be explaining how I implemented the attack limit (perhaps combat width is a better term): [...]
My main motivation for wanting to limit attacks was to give an inferior defending stack a chance to retreat some of its damaged units units rather than being wiped out in one big attack. Especially the 90+x% odds once all defenders are damaged bother me. Your pairwise width mechanism takes a pretty different approach: I'd say it offers such wipeouts as a reward for surrounding/ flanking the target stack. Well, at least it'll make annihilation less common, and I agree that it's more logical than a per-tile attack limit. That said, treating diagonal adjacency just the same as orthogonal is a bit awkward as the former is represented by just a corner on the map (infinitely small width geometrically speaking); or one might say that this mechanism draws attention to the strange geometry of movement in Civ 4.
More serious concerns:
* Fast units aren't affected much by a pairwise limit. Fanning out before the attack will leave them exposed afterwards, but that's only a concern if the defending stack is still capable of striking back. As a corollary, owned roads will likely become more powerful.
* Displaying multiple attack counts per tile could be cumbersome. I'd only show the counts for directions from which an attack has already occurred, but still ...
For now the limit is a (hard) constant but I am considering to instead let it be a (soft) limit and allow more than n attacks per turn but in that case apply a combat penalty for attacks that exceed n (the combat "width" for this plot pair). This is actually the reason for considering the RI stack size combat penalty mechanism. This would avoid the issue that you raised about fortified cities\forts on choke points being practically unassailable.
That's true – even if a limit is placed on defensive modifiers, a large enough stack on a chokepoint could become unassailable if a flat attack limit is imposed. Making the width dependent on the size of the defending stack should get around this problem without the need for a separate mechanism. I admit that this wouldn't be so flavorful – if the frontline is narrow and the armies are big, then you'd expect the battle to take multiple turns; a stack-size-based width eliminates that effect.
Defender set:
Spoiler :
Maintain a defender set (i.e. vector) of available units per plot that is:
- Randomly generated on every turn i.e. CvPlot::doTurn() (As an alternative the list could be created at the end of every player's turn though)
- Regenerated \ updated any time CvUnit::setXY() resulted in a unit being added to or removed from the plot. If a unit died, the list would also be regenerated.
Ideally, I think, there should be just one update per round/ game turn. There will have to be some exceptions (bumped units), but any updates triggered by state changes could be exploited to manipulate the defender set. Most of the setXY calls are going to happen during the owner's turn. During that turn (and the turn of the owner's teammates), the defender set doesn't matter and shouldn't be displayed. Therefore, I'd do the update at the end of the owner's turn. (For this initial version, this probably doesn't matter.) Does the update select units uniformly at random so far?

As for units dying: When a unit dies in combat, then reshuffling the set would be implausible (they can't all suddenly change positions in the middle of a battle) and would make sequences of attacks impossible to plan for the attacker. So that simple rule of making one more defender available after each attack (whether a defender was killed or not) still seems promising to me as it avoids a reshuffle and helps stacks that get attacked many times in a row (see attack limit above).
CvPlot::getBestDefender() was then changed to query the defender set rather than iterating through CvPlot::headUnitNode()
My instinct was a flag at CvUnit, which avoids adding a datastructure (vector) and makes CvUnit::isAvailable an O(1) operation. However, it seems that your implementation has a performance advantage in getBestDefender – and CvUnit::isAvailable may not actually be needed often.
[...] 1) What if units from different domains were present. This applies to cities\forts where it is possible to have land,sea and air units stationed.
2) Some units should probably never contribute to the defender set: units in a transport (e.g. cargo), always invisible (spies), civilian units like workers, missionary (would a check against canDefend() be enough?)
3) Air units have their own stack limit so they should probably be excluded as well
Perhaps two separate sets, one against land attackers and one against sea attackers. Each set should only contain units that are able to defend against the respective domain. So sea units would never be in the anti-land set and air units would never be in any set.
4) What about invisible units like submarines that are visible to certain units classes (e.g. destroyers) ?
Make invisible combat units always available? If our explanation for unavailable defenders is limited maneuverability, then it seems justifiable to make submarines an exception. If there are more cases in which the eligible defenders depend on the attacking unit, then always computing the set on the fly for the given attacker (or the currently selected unit for mouse-over) should be considered.
5) [...] If A,B,C,D,E has units on the same plot, one unit is selected from each player. This is the only exception to the rule about having n defenders. It matters not which subset (or all) is at war with the player.

Without this rule it would be possible for the defender set to be composed entirely of units that the attacking player is not at war with which could confuse the AI and cause other weird bugs.
I see. That sounds like a good solution.
(Note that we would need other criteria like the list must also always contain at least one hostile unit that can defend)
If the defender set can only contain units that are able to defend, then I guess your rule for multiple teams should already cover the "hostile unit that can defend" constraint?

Another special case that comes to mind: Ballista Elephant. Target any unit or just the available ones? I'd just implement whatever is easier for now.

Air strikes (with a single target): Should imo not hit unavailable units until all the available units are maximally damaged. I'm not sure how well air strikes can be timed with ground attacks in reality. It could make sense to reshuffle after an air strike, meaning that the defenders get to regroup. (This only makes sense if there is a bias for healthy units when choosing the available defenders at random.) Edit: Never mind. Can't allow the attacker to shuffle away any inconvenient defenders through a single air strike.
Defensive modifiers:
Spoiler :
[...] Since I didn't want to just simply eliminate the defensive bonus once the stack exceeded the threshold I decided to create a "rank set" and then apply the defense bonus to only the first n best defenders in the set.
Then the units that are assumed to be inside the city defend first? Protecting the units that didn't find room in the city? That's pretty illogical too (if I understand correctly).
I then determined that the defensive bonus should be dealt with in a uniform way. If the stack size exceeded the threshold I would scale down the defensive bonus ( capped at 0 at this point, but we could consider to allow it to become negative) based on the number of excess defenders.
Sounds like we've arrived at the same conlusion. I guess the "but" in parentheses corresponds to the penalty in Realism Invictus.
This threshold could then be modulated by city infrastructure like walls or plot infrastructure like a fort.
The area enclosed by a wall would, in reality, be less or equal to the entire city area. I don't think we'd want to penalize walls. City population would make more sense to me, so that the threshold tends to increase over the course of the game as stacks get larger as well.
Cities would have a larger threshold so that defending inside cities would always be better than being in a random plot.
That doesn't seem imperative to me. If a city is totally overcrowded, then excess units would camp outside and be no better off than somewhere in the countryside.
Ranged attacks, coll. damage:
Spoiler :
It makes sense to me that artillery and battleships should have a farther range than the adjacent plot since roughly at the same time we have fighters and bombers with a range of 10 plots!
The M109 howitzer (3D model for Mobile Artillery) has a range of 30 km according to Wikipedia, whereas a B-17 (Bomber 3D model) has a range of 3219 km. The length of the equator divided by the grid width of a Huge map is 40000 km / 128 = 312.5 km. You probably know these things better than I do; so I suppose you're arguing for a logarithmic scale; after all, 30 km is much farther than a service rifle can shoot. And perhaps artillery with a 2-tile range is needed to get the proper feel of modern warfare across.
DCM code: Even if the AI code for Ranged Bombardment isn't top-notch (I wouldn't know), it's at least a starting point. The VIP mod btw also has an implementation of ranged strikes with some AI code.
[...] archers now become the default collateral damage capable unit.
If you go down that road, to avoid making Archer too complex, perhaps Spearman should become the standard city defender? Though that would require significant changes to all early units ...
 
Last edited:
@MatteM: I've taken a stab at the Sevopedia. Indeed a bit tricky. This call
screen.setDimensions(screen.centerX(0), screen.centerY(0), self.W_SCREEN, self.H_SCREEN)
was responsible for the displacement when increasing W_SCREEN. I've adjusted a bunch of other values too. Still not too happy with the result (see attachments - after/before). I had to make the leftmost column quite thick so that the hover text can appear there (rather than appearing sometimes to the left and sometimes to the right). The tech quote box is a bit of an eyesore. Will have to enlarge the screen vertically too I guess. Currently, it has the same dimensions as the (wide-screen) tech tree. And the "Civilizations" box really should only be shown for starting technologies.
 

Attachments

  • wide-sevopedia.jpg
    wide-sevopedia.jpg
    196.4 KB · Views: 288
  • narrow-sevopedia.jpg
    narrow-sevopedia.jpg
    203.7 KB · Views: 285
hey,
another question - why does the event log keeps popping up?
is it a bug?
You can disable that on the "General" tab of the BUG menu; under "Misc." on the lower right. This reminds me:

I've been thinking about displaying new messages in the unit command area. See the attached mock-up. I'm not sure if that can be implemented within the SDK, and I probably won't do it, but I'd like to get the idea out of my system. So, how it could work is that three or fewer messages are displayed on the main map as in BtS, but, if there are more than three, then unit cycling doesn't immediately start – in order to keep the command area empty – and the messages are displayed down there. The unit pane (lower left) would then also remain empty, so minimized popups could be shown there, along with a button to start unit cycling, instruction labels if needed, and any further buttons that could be helpful at the start of a turn, e.g. buttons for cycling through unhappy and unhealthy cities. All this stuff disappears when a unit is selected. Could also have little buttons next to each message for dismissing only that message, and an indicator next to clickable messages (those with a jump-to location).

There have also been some discussions about improving the notification system on the "We the People" GitHub page (link); though it doesn't sound like they'll develop something that I could adopt.

what is the floating point error in mp?
you explained it to me , but not sure i got it,
can it happen? is it fixable?
Floating point computations don't yield the exact same results on all processors. The differences are very small, but can result in an integer being one greater or smaller after rounding. And then the game can go out of sync. BtS never uses floating point numbers in synchronized code, but AdvCiv does in many places, especially within the UWAI component. My tests suggest that AdvCiv games will go out of sync unacceptably often if the floating point behavior of the processors isn't the same. It could be, however, that all the widely used processors actually behave the same way, perhaps due to the SSE2 instruction set. If there is indeed a problem, then it might be enough to add a couple of _fpcontrol calls that prescribe a certain arithmetic. I could do that right away but don't want to do it blindly/ unnecessarily. Another approach would be to go through my code and replace all floating point computations with similar integer computations. In most cases, this would not be difficult, just tedious. (The difficult cases have to do with exponentiation, but I also have an idea to address that problem.)
 

Attachments

  • messages mockup.jpg
    messages mockup.jpg
    241.6 KB · Views: 197
Last edited:
You can disable that on the "General" tab of the BUG menu; under "Misc." on the lower right. This reminds me:
ok thanks

I've been thinking about displaying new messages in the unit command area.
that not a bad idea, sounds cool, but, if its plenty of work, worth the trouble?

Floating point computations don't yield the exact same results on all processors
ok now i understand, thanks for the explanation.
so - how were you able to test games on mp? was it because you tried on two similar processors?
yeah going over on all points, tedious....i hope you can work around it.
 
Back
Top Bottom