Advanced Civ

so - how were you able to test games on mp? was it because you tried on two similar processors?
Intel M and Athlon X4. Not so similar I thought, but they yield the same results for the test computations that I've added and I'm getting the same game state when I run Auto Play games from the same initial save. That is, so long as they both use the same DLL build; – debug and release builds do compute floating points numbers differently (not sure why exactly).
 
so for now you have oos?
For now I get no OOS errors at all. The screenshot of the error message was created by running two BtS instances on my PC and using _fpcontrol to set a higher internal precision in one instance. Sorry if I'm not making myself clear. A lot of hypotheticals as, to my knowledge, no one except me has attempted a multiplayer game with the mod. You and I could arrange a (Auto Play) test via direct IP connection if this worries you.

--
Another bug in v0.95: Crash to desktop when hovering over a tile containing a visible Spy unit together with a Barbarian unit. Can disable the "List Units per Owner" on the "Map" tab of the BUG menu as a workaround. I've added a list of known issues to the database page.
 
@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.

Yeah I agree Dales mod is not perfect but adds great features for air units especially. Also giving ranged to Archers is somewhat silly, as on small maps you can archer bombard Wales from London :lol:
Also the enemy units have to be stacked (at least 2) in order to work, I guess that has to do with the collateral damage system, introducing something else would be a separate system from the collateral damage
one, maybe someone has implemented that already though?

Even for later artillery unless it is rockets it is somewhat a stretch unless on larger maps, but for Ships it would be a really cool and realistic feature as that is the doctrine of the day, you want to rain missiles
on the other guy and not give broadsides as in Civ4 vanilla. But as keldath mentioned the biggest drawback is perhaps the a.i:s ability to understand the tactics involved.

His air unit orders I really like though, as surgical bombardment of specific buildings.
 
@devolution: Thanks for all the info and rationales. I'll take another day to digest that.

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.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).

Yes I sort of got stuck and haven't had the time really to experiment much more the Sevopedia screen, as I mostly make units. Integrating Platypedia would be a great feature, I have to say though that once Sevopedia and BUG is installed it is
really hard to get rid of, it is sort of a Trojan horse :).
 
@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.

Nice work, that looks much better at least! I think I tried all kinds of stuff, how many other values needed to be changed? For me I would really have to take the time to familiarize myself with the Python Code but currently
spending all free time doing doing 3d-work and units. I understand you want a "clean" mod without a lot of content, which I think is a very good Idea, but should there be any desire to expand with units just let med know, perhaps
a scenario or two!
 
Nice work, that looks much better at least! I think I tried all kinds of stuff, how many other values needed to be changed?
Mainly just the positions of the controls in the footer; these were all absolute values. Here's a Git commit with the changes I've made so far. Vertical enlargement should work similarly, but will again take a bit of trial and error until everything is in its proper place. I hope I'll get around to it.
I understand you want a "clean" mod without a lot of content, which I think is a very good Idea, but should there be any desire to expand with units just let med know, perhaps a scenario or two!
Thank you. Those camouflaged vehicles of yours do look exciting to me. I'd like to keep the main download lean, also in terms of file size, but having an optional pack with artwork or scenarios customized for the mod (its AI behavior) would be nice. I'm certainly not the right person to implement such things though.
 
Mainly just the positions of the controls in the footer; these were all absolute values. Here's a Git commit with the changes I've made so far. Vertical enlargement should work similarly, but will again take a bit of trial and error until everything is in its proper place. I hope I'll get around to it.Thank you. Those camouflaged vehicles of yours do look exciting to me. I'd like to keep the main download lean, also in terms of file size, but having an optional pack with artwork or scenarios customized for the mod (its AI behavior) would be nice. I'm certainly not the right person to implement such things though.

I'll make a modmod :)
 
On limited combat rounds

Found some time to work on this and I finally got the odds display to work. Also put in quite a bit of effort (in vain) with respect to first strikes. However, I've realized that first strikes cannot coexist at all with limited combat rounds since it is way too powerful. Depending on the number of first strikes, they make take up most or all of the combat rounds and effectively make is impossible for a unit without first strikes to injure a unit with several first strikes.

Now, I do have some positive news though since I've finally realized the definite need for variable (or adaptive) combat rounds and how it should be implemented. Consider two undamaged units of equal strength. When any unit wins, it does 20HP worth of damage to the opponent. We can easily see that the maximum number of combat rounds for evenly matched units is 9 (One unit sustain 5*20HP damge and dies and the other lives with 4*20HP damage).

What should the combat round limit be ?

I've come up with two alternatives:

The self preservation principle (SPP) which states that a unit should only be willing to attack as long as it does not risk dying. From this we can derive that the "base" number of combat rounds for evenly matched full health units will be 4. In this case, initial combat will always end in a draw.

The minimal risk principle (MRP) which states that a unit is willing to risk its own death given that it also has a chance of winning. From this we derive from the example above that the base number of rounds will be 5. The risk of either winning \ dying is about 3% though so rather low (one of the unit would have to either win all 5 rounds or loose all of them)


What about injured units ?

Consider combat between injured units. In this case a fixed number of combat rounds will probably not matter at all since the battle will have concluded before the combat round limit was reached. To rectify this we need to ensure that the combat round limit is effectively lowered. Either of the principles that I've outlined will result in the number of combat rounds being lower "than normal" so that the limit still matters, even for combat between severely injured units. Note that there will still be a significant chance of either of them dying though.

What about differences in combat strength ?

This is where this proposal shines :)
It will now be possible for several weaker units to "gang up" on stronger units without having to (necessarily) sacrifice the first attacker(s) since the attacking units gets to decide the number of combat rounds. The weaker\more injured an attacker is, the less combat rounds.
Note that a much stronger attacker (combat ratio > 1.5) will have a decent chance of killing the defender outright, albeit a draw will still be the most likely outcome.

What about the combat limit ?

This is currently used to ensure that siege units do not get to kill the defender. To be consistent, I think that we should restate the limit in terms of combat rounds. I also intend to have promotions (i.e. flanking\skirmisher) or unit classes (i.e. light cavalry) engage in fewer combat rounds to represent flank attacks and to ensure a high survival probability (i.e. draw) for these. No more suicide flanking and\or siege!

Some observations from testing:
- Strong attacker will now be much less likely to die when attacking, which should boost units with attached great generals.
- Battles will take additional turns to resolve. It will be important to reserve defenders for the inevitable counter-attack.
- Numerical advantage will matter more in the sense that the side with a numerical advantage can better distribute damage over their units (i.e. combat entropy increases since there are more outcomes than the death of either the attacker or defender)
- Neither the attacker nor the defender is necessarily favored by these changes. For example, besieging cities will most like take at least one extra turn which gives defenders the chance to bring extra defenders unless the attacker had at least twice the number of units at strength parity.
Brief summary:

- First strikes will be removed (I prefer to repurpose them for meaning C4R range but we need to discuss this). In my opinion, FSs were always counter-intuitive and confusing to reason about anyways.
- We need to decide on how much entropy we want and then choose a suitable principle that we can derive the number of combat rounds from. Feel free to propose an alternative principle!
- The attacker effectively decides the number of combat rounds based on the strength of the defender. Think of this as the attacker's "initiative"
- Note that a combat round limit will in itself favor stacking to achieve the damage distribution effect so it must be combined with other measures to make stacking less desirable (combat width, defender set, collateral scaling etc)
 
Last edited:
Oh. Well, in that case, if I can support this somehow on the DLL side, please let me know.

I probably would have a few suggestions for making awesome scenarios, such as altering the random events system and making that part more fun,
but I am super busy making units at the moment so I'll let you work on the mod in peace :)

I implemented your sevopediamainscreen, the title "Sevopedia" seemed to be missing but that might be bcause I am running RevDCM currently, I really
like the widescreen sevopedia, although I will try to expand the window in the "y"-direction since I am playing on 1920X1080.

One thing I was thinking of in sevopedia: There is a possibilty to alter the button size, I upsized it to 128, looks fine in game (screenshot below), the game
then stretches out the 64-icon, but possibly one could make 128-buttons with better resolution, but that would make the buttons not show up in game
and it would be hard to have 128-buttons in the game interface (or would it?). I am all about the eye-candy but for modern resolutions the 64-icons is
really small. Well the question would be, does the in-game interface require the button to be 64 or does it automatically reduce the size as long as it is 32, 64, 128 etc?

Civ4ScreenShot0010.JPG
 
Last edited:
I probably would have a few suggestions for making awesome scenarios, such as altering the random events system and making that part more fun,
but I am super busy making units at the moment so I'll let you work on the mod in peace :)
OK. :c5faith:
I implemented your sevopediamainscreen, the title "Sevopedia" seemed to be missing but that might be bcause I am running RevDCM currently,
I've changed the title to "CIVILOPEDIA" (I hope Sevo won't/wouldn't mind). The text key is in Civ4GameText_advc.xml:
Spoiler :
Code:
<TEXT>
  <Tag>TXT_KEY_CIVILOPEDIA_TITLE</Tag>
  <English>CIVILOPEDIA</English>
  <French>CIVILOPÉDIA</French>
  <German>ZIVILOPÄDIE</German>
  <Italian>CIVILOPEDIA</Italian>
  <Spanish>CIVILOPEDIA</Spanish>
</TEXT>
One could use TXT_KEY_MAIN_MENU_CIVILOPEDIA instead and convert it to upper case in Python.
I really like the widescreen sevopedia, although I will try to expand the window in the "y"-direction since I am playing on 1920X1080.
Thanks for the screenshot. The panels in the left column (stats, requires, abilities) are all a bit small. I've tried to fix that; see the attached screenshot and this Git commit. I think the stats box has always been too small for air units, though the larger font I use exacerbates the problem. Increasing the total height would take care of that. (And hopefully also the small issue with the too-low "History" box in your screenshot.)
One thing I was thinking of in sevopedia: There is a possibilty to alter the button size, I upsized it to 128, looks fine in game (screenshot below),
Already a bit blurry. I've tried 96. That looked OK to me, but a bit too similar to the regular size.
[...] Well the question would be, does the in-game interface require the button to be 64 or does it automatically reduce the size as long as it is 32, 64, 128 etc?
I don't have a 128x128 button at hand either for a test. You'd think that, if addDDSGFC can scale up, it should also be able to scale down. There might be other parts of the UI where larger buttons would look better, though probably also some where there isn't enough (vertical) space. However, mixing high-res and los-res buttons may not look so nice (in the Civilopedia, where there is just one large button per page, it's less of a problem). For any change, it should be helpful to add a function for showing the button to CvSevopediaMain that the other Sevopedia classes can call. So that the same button style is used for all types of pages.

Regarding ranged attacks by ships:
Also giving ranged to Archers is somewhat silly, as on small maps you can archer bombard Wales from London :lol: [...] Even for later artillery unless it is rockets it is somewhat a stretch unless on larger maps, but for Ships it would be a really cool and realistic feature as that is the doctrine of the day, you want to rain missiles on the other guy and not give broadsides as in Civ4 vanilla. But as keldath mentioned the biggest drawback is perhaps the a.i:s ability to understand the tactics involved.
I'd like to add that we do have a Missile Cruiser. It just needs to become available a bit earlier than in BtS and Guided Missile needs some work. I've been thinking of giving it an ability similar to Ballista Elephant: target the most expensive defender. And it should arguably only target mechanized units and the damage should be randomized a bit.

I'll also have something to add about (adaptive) limited combat rounds; tomorrow I guess.
 

Attachments

  • sevopedia-unit.jpg
    sevopedia-unit.jpg
    210.3 KB · Views: 154
OK. :c5faith:I've changed the title to "CIVILOPEDIA" (I hope Sevo won't/wouldn't mind). The text key is in Civ4GameText_advc.xml:
Spoiler :
Code:
<TEXT>
  <Tag>TXT_KEY_CIVILOPEDIA_TITLE</Tag>
  <English>CIVILOPEDIA</English>
  <French>CIVILOPÉDIA</French>
  <German>ZIVILOPÄDIE</German>
  <Italian>CIVILOPEDIA</Italian>
  <Spanish>CIVILOPEDIA</Spanish>
</TEXT>
One could use TXT_KEY_MAIN_MENU_CIVILOPEDIA instead and convert it to upper case in Python.Thanks for the screenshot. The panels in the left column (stats, requires, abilities) are all a bit small. I've tried to fix that; see the attached screenshot and this Git commit. I think the stats box has always been too small for air units, though the larger font I use exacerbates the problem. Increasing the total height would take care of that. (And hopefully also the small issue with the too-low "History" box in your screenshot.)Already a bit blurry. I've tried 96. That looked OK to me, but a bit too similar to the regular size.I don't have a 128x128 button at hand either for a test. You'd think that, if addDDSGFC can scale up, it should also be able to scale down. There might be other parts of the UI where larger buttons would look better, though probably also some where there isn't enough (vertical) space. However, mixing high-res and los-res buttons may not look so nice (in the Civilopedia, where there is just one large button per page, it's less of a problem). For any change, it should be helpful to add a function for showing the button to CvSevopediaMain that the other Sevopedia classes can call. So that the same button style is used for all types of pages.

Regarding ranged attacks by ships:I'd like to add that we do have a Missile Cruiser. It just needs to become available a bit earlier than in BtS and Guided Missile needs some work. I've been thinking of giving it an ability similar to Ballista Elephant: target the most expensive defender. And it should arguably only target mechanized units and the damage should be randomized a bit.

I'll also have something to add about (adaptive) limited combat rounds; tomorrow I guess.

Yeah 128 is probably a bit large, 96 works fine as well, I wonder how it would look in game, might experiment later on. I did try to increase the height of Sevopedia, but it goes off centre again and only expands downwards for some reason.

The missile cruiser actually carries missiles was something I'd completely forgot :lol: sorry but when you mod the game for 4 years straight but hardly ever actually play you get completely lost lol. That sort of explains why firaxis never made long range missile attack animations for the missile cruiser. That makes it all the cooler as now I have lots of ships-to-ship missile models to find!
 
@devolution: Thanks for sharing your progress. That's some food for thought.
Quoted for context:
Spoiler :
Adaptive Limited Combat Rounds

The purpose is to allow skirmisher \ harassment \ gang-up tactics in which several weaker units collaborate to take down a much stronger unit. The simplest implementation of this is to think of this as an initiative mechanics in which the attacker, if weaker than the defender, will choose the terms of the engagement and thus engage in fewer than normal combat rounds. After all, an attacker is unlikely to want to commit to the full number of combat rounds if it is likely to loose a "full fight", thus I propose that the weaker the attacker is relative to the defender, the fewer combat rounds will take place.
It sounds like this could make the combat round limit less arbitrary, and it avoids having very low survival odds, which, on the attack, are somewhat implausible with regard to morale. Can we come up with a simple formula for this, or some, say, boardgame-like rule that determines when the number of rounds is decreased? If not, a variation of the withdrawal ability could be more intuitive. The current ability checks after each hit if:
Code:
getDamage() + iAttackerDamage >= maxHitPoints() && GC.getGameINLINE().getSorenRandNum(100, "Withdrawal") < withdrawalProbability()
On limited combat rounds

Found some time to work on this and I finally got the odds display to work. Also put in quite a bit of effort (in vain) with respect to first strikes. However, I've realized that first strikes cannot coexist at all with limited combat rounds since it is way too powerful. Depending on the number of first strikes, they make take up most or all of the combat rounds and effectively make is impossible for a unit without first strikes to injure a unit with several first strikes.

Now, I do have some positive news though since I've finally realized the definite need for variable (or adaptive) combat rounds and how it should be implemented. Consider two undamaged units of equal strength. When any unit wins, it does 20HP worth of damage to the opponent. We can easily see that the maximum number of combat rounds for evenly matched units is 9 (One unit sustain 5*20HP damge and dies and the other lives with 4*20HP damage).

What should the combat round limit be ?

I've come up with two alternatives:

The self preservation principle (SPP) which states that a unit should only be willing to attack as long as it does not risk dying. From this we can derive that the "base" number of combat rounds for evenly matched full health units will be 4. In this case, initial combat will always end in a draw.

The minimal risk principle (MRP) which states that a unit is willing to risk its own death given that it also has a chance of winning. From this we derive from the example above that the base number of rounds will be 5. The risk of either winning \ dying is about 3% though so rather low (one of the unit would have to either win all 5 rounds or loose all of them)


What about injured units ?

Consider combat between injured units. In this case a fixed number of combat rounds will probably not matter at all since the battle will have concluded before the combat round limit was reached. To rectify this we need to ensure that the combat round limit is effectively lowered. Either of the principles that I've outlined will result in the number of combat rounds being lower "than normal" so that the limit still matters, even for combat between severely injured units. Note that there will still be a significant chance of either of them dying though.

What about differences in combat strength ?

This is where this proposal shines :)
It will now be possible for several weaker units to "gang up" on stronger units without having to (necessarily) sacrifice the first attacker(s) since the attacking units gets to decide the number of combat rounds. The weaker\more injured an attacker is, the less combat rounds.
Note that a much stronger attacker (combat ratio > 1.5) will have a decent chance of killing the defender outright, albeit a draw will still be the most likely outcome.

What about the combat limit ?

This is currently used to ensure that siege units do not get to kill the defender. To be consistent, I think that we should restate the limit in terms of combat rounds. I also intend to have promotions (i.e. flanking\skirmisher) or unit classes (i.e. light cavalry) engage in fewer combat rounds to represent flank attacks and to ensure a high survival probability (i.e. draw) for these. No more suicide flanking and\or siege!

Some observations from testing:
- Strong attacker will now be much less likely to die when attacking, which should boost units with attached great generals.
- Battles will take additional turns to resolve. It will be important to reserve defenders for the inevitable counter-attack.
- Numerical advantage will matter more in the sense that the side with a numerical advantage can better distribute damage over their units (i.e. combat entropy increases since there are more outcomes than the death of either the attacker or defender)
- Neither the attacker nor the defender is necessarily favored by these changes. For example, besieging cities will most like take at least one extra turn which gives defenders the chance to bring extra defenders unless the attacker had at least twice the number of units at strength parity.
Brief summary:

- First strikes will be removed (I prefer to repurpose them for meaning C4R range but we need to discuss this). In my opinion, FSs were always counter-intuitive and confusing to reason about anyways.
- We need to decide on how much entropy we want and then choose a suitable principle that we can derive the number of combat rounds from. Feel free to propose an alternative principle!
- The attacker effectively decides the number of combat rounds based on the strength of the defender. Think of this as the attacker's "initiative"
- Note that a combat round limit will in itself favor stacking to achieve the damage distribution effect so it must be combined with other measures to make stacking less desirable (combat width, defender set, collateral scaling etc)
A base limit of 4 or 5 seems very low to me. With the SPP rule, I guess, the non-Advanced combat odds will just say "100% retreat" unless the attacker has greater strength than the defender? I fear that too few (human) units will die and that the importance of healing will increase. It also sounds like the pace of combat will be much slower than in BtS, which mostly resolves battles in a single turn. Considering that we can't be consistent with the game date anyway (e.g. 1 turn = 5 years) and that deployment and bombardment are quite slow, I feel that there is some leeway for slowing combat down as well, but I don't think it needs to be that slow. And the more the round limit favors large stacks, the more pronounced the anti-stacking measures will have to be, potentially creating further ripples (or waves).

I can think of constraints on the combat odds that result in a higher limit, but none simple enough for my taste, and it's not clear to me that the proper limit should depend on the odds or hitpoints. On the one hand, the more one-sided the odds are, the greater the potential frustration for the owner of the stronger unit. So it would seem that the limit should decrease as the attacker's odds increase. However, one-sided odds already lead to a smaller expected number of rounds.
As for units with significant damage, see above (pace, healing); better not to protect those.

Suicide attacks don't feel good. I guess mainly because they make the attacker seem inanimate (lacking self-preservation). How high does the survival probability have to be to avoid this impression, and how small does the round limit have to be accordingly? I'd say ideally close to 50% survival; can be much lower, but that should be exceptional. If the strength ratio is extremely unfavorable, then the attack is unlikely to accomplish anything and it's of no real concern as players won't normally order such attacks. If the attacker is at least half as strong as the defender (BtS odds: a bit less than 1%), then I expect that your 4 or 5 round base limit would be fine. I can't do the math; I hope 7 or 8 would also do.

Ganging up: Wouldn't it be enough to make units with first strike, withdrawal chance or damage limit good at that?

How do we distinguish skirmishing/harassment (BtS withdrawal chance), ranged infantry (BtS first strike) and artillery (BtS damage limit and collateral damage), none of which work well in BtS?
To be consistent, I think that we should restate the [damage] limit in terms of combat rounds. I also intend to have promotions (i.e. flanking\skirmisher) or unit classes (i.e. light cavalry) engage in fewer combat rounds to represent flank attacks and to ensure a high survival probability (i.e. draw) for these.
That sounds good. But I guess there should still be some distinction between a light cavalry attack and an artillery attack, apart from collateral damage? For one difference, I'd imagine it to be difficult to totally eliminate a military unit just through shelling, whereas cavalry should be good at mopping up.

I'm not sure that BtS first strikes couldn't coexist with a combat round limit of 7 or 8 – provided that the combat odds can be calculated. To ensure that units with multiple first strikes don't become invincible, one could omit first strike rounds of the defender when counting combat rounds.
In my opinion, FSs were always counter-intuitive and confusing to reason about anyways.
First strike doesn't play very differently from a 7% (or so) combat bonus, and the subtle differences are, I agree, counterintuitive. The combat round limit should make the (fairly intuitive) aspect of preserving the Archer's health more pronounced. And the alternative, the range ability would be an attack bonus against smaller range and fewer combat rounds?
 
Back
Top Bottom