Page MenuHomeWildfire Games

bb
User

Projects

User Details

User Since
Jan 24 2017, 12:54 PM (133 w, 4 d)

Recent Activity

Mon, Aug 5

bb committed rP22615: redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb….
redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb…
Mon, Aug 5, 4:13 PM
bb closed D1939: redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb some duplication in the gui.
Mon, Aug 5, 4:13 PM
bb added a comment to D1939: redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb some duplication in the gui.
In D1939#87819, @elexis wrote:

modmod.js saveMods() should also be updated; it wasn't present there since the function was located public/.

We call WriteFile there, so everytime we save the mods, we save everything, sounds wrong...

Mon, Aug 5, 12:49 PM

Sun, Aug 4

bb added a comment to D2112: Fix "GetBestAttackAgainst"-function in "Attack.js"..

This probably wasn't done at the time since I didn't want to change code twice, but the change is in principle correct

Sun, Aug 4, 12:36 PM
bb added a comment to D2038: Let "GetBestAttackAgainst" depend on DPS..

In D368 DPS has its function in the DamageReciever. Range is added as a multiplication factor:

  • in range, the factor is 1
  • inside minrange or outside maxrange we let the factor drop exponentially
Sun, Aug 4, 12:34 PM

Thu, Jul 25

bb added a comment to D2092: Generalise Attack effects - any attack can do damage, capture, inflict status effects, including splash. Also damage bonuses..

D368 way

Template structure:

<AttackType>
   <Effects>
      <Hack>5</Hack>
      <Capture>4</Capture>
      <StatusEffects>
         <Burn>...</Burn>
      </StatusEffects>
   </Effects>
</AttackType>

Not exactly what is proposed:

<AttackType>
   <Effects>
      <Damage>
         <Hack>5</Hack>
         <Capture>4</Capture>
      </Damage>
      <StatusEffects>
         <Burn>...</Burn>
      </StatusEffects>
   </Effects>
</AttackType>

(Even more precise would be without the Effects indentation, but fine with adding that)
Pros:
Effects can be iterated over
Nodes reflect the component it maps to (Damage to DamageReciever, StatusEffect to statuseffectReceiver), thus no hardcoding of these
Damagetypes can be iterated over within all effects, thus statusEffects can capture immediately

Thu, Jul 25, 1:28 PM
bb added a comment to D2109: Move duplicated "Attack.js" schema code to helper..

The question is preferred classes and restricted classes (ping @bb ). Are they a property of the attacker or the attack itself.
Preferred classes seem obviously the first - it's a hint to unitAI, relating to GetBestAttackAgainst (@Freagarach please split from D2044 ;) ).

Well I agree on the statement that preferred classes should be an attacker unitAI hint, which targets it should attack. However that has not much todo with GetBestAttackAgainst since there we already have chosen the target. Maybe preferred classes should be in the unitAI template instead?

There are two behaviours: making attacks ineffective (related to D2044), and hints to unitAI - which may or may not be needed. For walls for example - if we made the impervious to hack/pierce, they would effectively be restricted from damage by non-siege units right now.

If there are two behaviors maybe make two template entries, one for each?

Thu, Jul 25, 1:04 PM

Mon, Jul 22

bb added a comment to rP22527: Easier introduction of new damage types..

However, we never actually need to refer to this script since we can always use the damage types provided by the template/context/object we are looping over/...

That part is contested when/if we want to generalize damagetype to affect other components than just Health or if we want to set any other damageType specific value (i.e. one could think of making "crush" only work on building class units, setting immunities could work for this case too, but there might be other similar ideas)

Mon, Jul 22, 9:57 PM
bb awarded rP22527: Easier introduction of new damage types. a Heartbreak token.
Mon, Jul 22, 9:57 PM

Jul 18 2019

bb updated the diff for D1397: Entities panel error out on hero death.

A replay for current svn:

Jul 18 2019, 12:56 PM
bb updated the Trac tickets for D1397: Entities panel error out on hero death.
Jul 18 2019, 12:21 PM
bb committed rP22504: Clean Gaia's Selectable.
Clean Gaia's Selectable
Jul 18 2019, 12:04 PM
bb closed D1765: Gaia templates' <Selectable> clean-up.
Jul 18 2019, 12:04 PM
bb accepted D1765: Gaia templates' <Selectable> clean-up.
Jul 18 2019, 12:02 PM

Jul 17 2019

bb added inline comments to D1810: Improvements to the translators credits script.
Jul 17 2019, 10:38 PM
bb accepted D1810: Improvements to the translators credits script.
Jul 17 2019, 10:33 PM
bb committed rP22498: Standardize formation tooltips.
Standardize formation tooltips
Jul 17 2019, 10:20 PM
bb closed D2007: standardize formation tooltips.
Jul 17 2019, 10:20 PM
bb accepted D2007: standardize formation tooltips.

Reads correct and complete now

Jul 17 2019, 10:19 PM
bb committed rP22497: Add skirmish templates for range, stable, wonder and workshop.
Add skirmish templates for range, stable, wonder and workshop
Jul 17 2019, 9:41 PM
bb closed D2049: Add four default skirm structures.
Jul 17 2019, 9:41 PM
bb added a comment to D2049: Add four default skirm structures.

Default skirmish placeholders for the elephant stable aren't added, because not all civilizations have one; for comparison, other structures shared by some but not all (e.g. library, rotary mill, theatre) don't have them either.

Notice that houses have a skirmish replacer and there actually are 2 types of them i.e. small and big houses, so that would be the way to handle the structures that not all civs have

Jul 17 2019, 9:40 PM
bb accepted D2049: Add four default skirm structures.
In D2049#86151, @Nescio wrote:

Good point! Not all skirmish templates specify a footprint, though; should those (barracks, blacksmith, civic centre, etc) be updated here as well?

The skirmish templates could inherit the correct value from the parent, if that is not the case it needs to be updated, however sounds like a topic of another patch, excluding the barracks chance for now

Jul 17 2019, 9:29 PM
bb added inline comments to D2007: standardize formation tooltips.
Jul 17 2019, 7:57 PM
bb added inline comments to D2007: standardize formation tooltips.
Jul 17 2019, 7:54 PM
bb added inline comments to D2081: Add status effects support to splash, melee and death damage..
Jul 17 2019, 2:28 PM
bb requested changes to D2081: Add status effects support to splash, melee and death damage..

In the related ticket #1144, it was stated (first comment, by non-team member) that although a unit is not allowed to attack a specific entity, it *should* be able to damage it

You mean https://trac.wildfiregames.com/ticket/1144#comment:1 ? I read more in that that a unit could be restricted to attack another unit with a certain attacktype, however it still can attack with another attackType (i.e it can't use Capture but can use Melee)

Jul 17 2019, 2:04 PM
bb updated the diff for D1398: Implement a press action to be called upon the first keyDown message of a hotkey and use keydown for current press.
Jul 17 2019, 1:14 AM

Jul 16 2019

bb added a comment to D2086: Fix ranges when treating a target as a circle.

But will it get in range? (I did not test it!!) If the minRange is so large the path might end outside the maxRange area and thus we never get there

Jul 16 2019, 9:40 PM
bb added a comment to D2086: Fix ranges when treating a target as a circle.

Didn't test it, but what happens now if minRange =~ maxRange, then it could be that the circumscribed circle for the minRange is bigger than the inscribed circle for maxRange...

Jul 16 2019, 9:30 PM
bb added inline comments to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Jul 16 2019, 5:35 PM
bb committed rP22486: Rename "CauseSplashDamage" to the more generic "CauseDamageOverArea".
Rename "CauseSplashDamage" to the more generic "CauseDamageOverArea"
Jul 16 2019, 5:16 PM
bb closed D2065: Rename "CauseSplashDamage" to the more generic "CauseDamageOverArea"..
Jul 16 2019, 5:15 PM
bb accepted D2065: Rename "CauseSplashDamage" to the more generic "CauseDamageOverArea"..

greps complete, CauseDamageOverArea good with me => accept

Jul 16 2019, 4:41 PM
bb added a comment to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
In D368#86829, @wraitii wrote:
In D368#86822, @bb wrote:

Can indeed be a nice idea, that way an attackType could in principle have both an instantaneous and a projectile damage (this example sounds weird though, but beam+projectile goes with the same idea, which is more plausible). However implementing this properly sounds like allowing multiple projectiles, which will need a ton of designing work, so would say "out of scope".

I'm not sure why you think this would take a ton of designing work? it seems rather easy to me once we get the above.

One should design what values a projectile can set, its not only Damage, Range is to me even a more prominent candidate, also how do deal with this animation wise, sound wise?

But Capturable isn't the equivalent of Armour, Capturable is the equivalent of Health. Armour will call the correct component based on the damageType.

Thinking some more: is that actually good design, though? Armour does nothing unless Health exists, so shouldn't armour just be a sub-element of health?

The current design is: Attack calls Damage and Capturable, Damage calls Armour, Armour calls Health. Where Attack is from the attacker entity, Damage a system component and Amour, Capturable and Health are defender components.
This patch makes the design: Attack calls Damage, Damage calls Armour, Armour calls Health and Capturable.
You propose (I guess): Attack calls Damage, Damage calls Armour and Capturable, Armour calls Health

Jul 16 2019, 4:38 PM
bb updated the summary of D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Jul 16 2019, 3:25 PM
bb added a comment to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
In D368#86809, @wraitii wrote:
  • Conceptually, ranged and melee attacks become similar except one deals 'instantaneous' damage and the other deals 'projectile' damage. Here the presence of a Projectile node differentiate. I would argue that we should put Damage node in the projectile for such attacks, and thus 'Melee' would probably get an 'Instantaneous>Damage' nodes as equivalents. This would prepare for continuous damage, aka beams.

Can indeed be a nice idea, that way an attackType could in principle have both an instantaneous and a projectile damage (this example sounds weird though, but beam+projectile goes with the same idea, which is more plausible). However implementing this properly sounds like allowing multiple projectiles, which will need a ton of designing work, so would say "out of scope".

  • Allowing attacks to deal both "Damage" or "Capture". I guess this is "AND" here, so first question: should it be xor instead? I guess dealing both damage and capturing is a bit weird, and it sounds like it would trigger annoying edge cases (such as a player wants capturing, we have an attack that captures but slower than it would destroy, the entity gets destroyed instead of captured)

Why would we limit a component to xor instead of leaving it to the template and by that giving full moddability? Yes it might give edgy cases when choosing attackTypes, but with the current implementation we (IMO) return something reasonable, which is IMO enough for the moddability support. In vanilla we could simply avoid this case by not having such a template, if we think it is too broken. Other than that I don't see much problems in allowing the "AND".

  • further, making "Capture" a damage type means handling it in armour, and it conflicts with D1938.

It indeed means handling through Armour, as is done in the patch (one is now also allowed to have a "Capture" armour, seems nice for moddability too). I didn't see a direct conflict though

We already have Capturable, so I think it would be much better to allow any attack to have a "Capture" effect, but not treat it as a damage type.

But Capturable isn't the equivalent of Armour, Capturable is the equivalent of Health. Armour will call the correct component based on the damageType. I here generalized the damageTypes to define a component they deal the damage on ie. Capturable or Health. Maybe we can do something about the "Damage" naming though.

  • UnitAI needs a way to know if it can attack/capture an enemy (related to D2044, immunity, and infinite armour)

See Attack.CanAttack and the function called there

  • UnitAI needs a way to find the best attack/capture attack against an enemy. This is rather easy with equal range using DPS. With unequal range, this becomes much trickier. Here we have "preferred attacks".

See Attack.GetBestAttackAgainst where we do a DPS range.

  • My suggestion would be to implement simple "personalities" in UnitAI, and the units would weight range based on that. e.g. 'artillery' personality would almost always prefer long-range, only fighting short-range if necessary. Would also make it doable GUI-wise.

What one could do (which has pretty much this effect) is setting the base of the power used in GetBestAttackAgainst (the 0.2 now in L420 and L422) in the template. The higher the base the more it will favor short ranged attacks.

  • the GUI needs a way to show these different attack types

For now they are just added in the tooltip

Possible further work:

  • allowing a player to always pick some attack.

Currently hotkeys are implemented to do this to some extend, but more/better ideas are welcome

Jul 16 2019, 3:21 PM
Angen awarded D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks a Love token.
Jul 16 2019, 1:41 PM
bb updated the test plan for D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Jul 16 2019, 1:37 PM
bb updated the diff for D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Jul 16 2019, 1:35 PM
bb updated the test plan for D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Jul 16 2019, 1:09 PM
bb updated the diff for D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.

Build will fail, needs to rebase last week...

Jul 16 2019, 12:49 PM
bb commandeered D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Jul 16 2019, 12:39 PM

Jul 15 2019

bb added a comment to D2016: Rename "ElevationBonus" and "Delay" to "AttackHeightOffset" and "DamageDelay", respectively..
In D2016#86642, @bb wrote:
  1. We shoudn't be talking about melee/ranged and stuff, rather projectile/non-projectile. This because the attack types should all be merged together in only 1 type.

Well, we will still need a way to differentiate between "instaneous" vs "projectile" attacks. We might have "Continuous" damage, too, for beam weapons.

absolutely, we should differentiate between projectile/non-projectile (and possible more types in future)

  1. statusEffect is still different (in its current implementation, but obviously one could change that) since it takes a direct "Damage" instead of taking armour into account too.

Actually, no, it takes armour into account since it goes through CauseDamage/cmpDamageReceiver.TakeDamage

Right, well, didn't expect the code to work in that way judging from the template schema, anyway another discussion

  1. As merging the attack types also means merging their specific handling code in PerformAttack, allowing a Delay for non-projectiles, is achieved by a Timer call on the CauseDamage function...

Mh, I only agree somewhat - the code for ranged attacks triggers "MissileHit" with a delay anyways, including the projectile firing delay (since that's really what delay is). We wouldn't go through that for instantaneous damage I think?

Also very true, projectiles will fire a projectile and go through missileHit, while direct attack go directly to CauseDamage

That would just be duplicate work, since melee attacks don't have the projectile object, the first step in allowing that, would be reverting this patch, sounds like wasting time for me...

Well, it's only if you actually _want_ melee attacks to have an elevation range bonus - and I don't see why we would want that. Regardless, I don't think it's such as big deal since all code dealing with elevation Bonus is in BuildingAI.js/UnitAI.js anyways - allowing melee/instantaneous damage to have an elevation range bonus just means enabling it in the template. if the unitAI changes are done - and as said above this patch doesn't change those.

So why not leave it to "if you want it, enable it in template"? Instead of moving it to the projectile and such implying that a elevationBonus needs a projectile.

How would you handle multiple projectiles with different elevation bonuses then? It must also go in the projectile.

For now I only allowed 1 projectile per attackType, however one could go with several attackTypes per unit (e.g. a unit could have a bow and a javelin) and each attackType can have his own elevationBonus. Allowing more projectiles per attackType might be a topic for a future patch though, but then it is not only a question of elevationBonus, one should consider about every attack template value...

Jul 15 2019, 7:51 PM
bb added a comment to D2016: Rename "ElevationBonus" and "Delay" to "AttackHeightOffset" and "DamageDelay", respectively..
In D2016#86566, @bb wrote:

Just want to note the following: I don't see a reason why melee or other non-projectile components couldn't have a Delay or ElevationBonus

Well, melee attacks are instantaneous by design - having a "delay" doesn't make a _ton_ of sense to me. I just don't see a use case where we wouldn't prefer either status effects or a projectile. Further, handling delay for melee attacks would mean keeping track of the damage to deal in a Timer, and that just sounds like status effects.

  1. We shoudn't be talking about melee/ranged and stuff, rather projectile/non-projectile. This because the attack types should all be merged together in only 1 type.
  2. statusEffect is still different (in its current implementation, but obviously one could change that) since it takes a direct "Damage" instead of taking armour into account too.
  3. As merging the attack types also means merging their specific handling code in PerformAttack, allowing a Delay for non-projectiles, is achieved by a Timer call on the CauseDamage function...
Jul 15 2019, 1:51 PM

Jul 14 2019

bb added a comment to D2016: Rename "ElevationBonus" and "Delay" to "AttackHeightOffset" and "DamageDelay", respectively..

Just want to note the following: I don't see a reason why melee or other non-projectile components couldn't have a Delay or ElevationBonus, a sort of Delay might be possible too with statusEffects, but to me it sounds cleaner to just have it for all attack type. Also with my patch for #252 I allowed this (I rebased it, just need to fix a couple for issues...)

Jul 14 2019, 11:03 PM

Jul 12 2019

bb requested changes to D1838: Add proximity attack component..

vulcan Lint is yelling about some stuff in the tests

Jul 12 2019, 10:16 PM
bb committed rP22461: Add periods and caps to the JSDOCs in Damage.js.
Add periods and caps to the JSDOCs in Damage.js
Jul 12 2019, 9:39 PM
bb requested changes to D2049: Add four default skirm structures.

When doing D723, D726, D727, D728 we took as a convention that the obstruction/footprint of the default buildings should be the greatest of all the civ's buildings such that Atlas guides you to make nothing overlapping. It would be good to do the same for these buildings immediately. e.g. for the range the footprint would be 27x27 and obstruction 26x26 since the ptol is the biggest with those size. Also if there is one building with 20x 25 and another 25x20 we would need 25x25 here.

Jul 12 2019, 8:49 PM

Jul 11 2019

bb added a comment to D2052: remove unnecessary selection panels object.

I absolutely like to see that you want to expand your knowledge from just templates to more areas of the code such as the gui, however it seems like you are fixing a non-existing problem here: The GUI objects incorporate their size from their parent (just like templates incorporate values from their parent). So if you have something like:

<object size="30, 30, 100, 100">
  <object size "0 0 100% 100% "/>
</object>

The inner object will be a square with sides of 70 pixels.

Jul 11 2019, 3:09 PM

Jul 5 2019

bb committed rP22436: Add damage container also in the examples, following rP22379.
Add damage container also in the examples, following rP22379
Jul 5 2019, 8:16 PM
bb closed D1995: Fix missing "Damage"-node in examples..
Jul 5 2019, 8:15 PM
bb accepted D1995: Fix missing "Damage"-node in examples..

Lets avoid some rebasing work by committing this...

Jul 5 2019, 8:11 PM
bb added a comment to D2041: Fix IDLE-related infinite loops.

I have never liked the idle timer, it always have seem a hack to me, I rather get rid of it than moving stuff towards it.

Jul 5 2019, 2:31 PM

Jul 1 2019

bb committed rP22420: Cleanup UnitAI's FaceTowardsTarget function and allow units without a….
Cleanup UnitAI's FaceTowardsTarget function and allow units without a…
Jul 1 2019, 2:33 PM
bb closed D2014: Remove "delta" from "UnitAI's" "FaceTowardsTarget"..
Jul 1 2019, 2:33 PM
bb accepted D2014: Remove "delta" from "UnitAI's" "FaceTowardsTarget"..

I was wondering if it would be possible to cleanly avoid the duplicate behavior between the unitAI code and the code in unitMotion (which is called from here), but in fact they are independent here. Avoiding the duplication would mean adding some extra check here, which sounds to do more harm than good.

Jul 1 2019, 2:23 PM
bb committed rP22419: Fix ESLint semicolon-related warnings.
Fix ESLint semicolon-related warnings
Jul 1 2019, 1:09 PM
bb closed D2004: Linter: Fix ESLint semicolon-related warnings.
Jul 1 2019, 1:09 PM
bb added a comment to D2026: Make Promotion.js use the common Transform helper.

Transform.js got added in rP18467 to enable upgrading, as transform.js is meant to be generic and should be able to perform any change of template, this change makes should make things more clean and easier to handle.

Jul 1 2019, 12:49 PM

Jun 29 2019

Krinkle awarded rP22203: Communicate field diminishing returns to the player in the fields tooltip a Orange Medal token.
Jun 29 2019, 1:30 AM

Jun 28 2019

bb added a comment to D2014: Remove "delta" from "UnitAI's" "FaceTowardsTarget"..

Digging into the origin of the delta we get to https://trac.wildfiregames.com/ticket/831, the attached patch want to check if our rotation is good to attack, and for that uses a delta, but as I can see now, judging the codebase 8 years ago, that would only partially fix the described problem there. The actual fix introduced the faceToTarget function, which did fix the issue for what I can see. I don't see a reason why we shouldn't turn if we are really close (neither then or now), so I would guess it is a relic from the originally proposed fix. Given that I think we are OK to remove the delta and just rotate correctly.

Jun 28 2019, 9:59 PM
bb added inline comments to rP22313: Unit Motion: MoveTo family of function no longer returns false if the move is….
Jun 28 2019, 9:58 PM
bb updated the diff for D1939: redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb some duplication in the gui.
Jun 28 2019, 7:49 PM
bb accepted D2004: Linter: Fix ESLint semicolon-related warnings.

patch reads correct, and jshints complete

Jun 28 2019, 6:29 PM
bb added a comment to D1953: every technology modification on a new line.

I see where the confusion about the array spacing came from, my bad, should have seen it in your code example, anyway thanks for the patch

Jun 28 2019, 6:05 PM
bb committed rP22408: Clean up technologie data files:.
Clean up technologie data files:
Jun 28 2019, 5:59 PM
bb closed D1953: every technology modification on a new line.
Jun 28 2019, 5:59 PM
bb accepted D1953: every technology modification on a new line.

Completeness check forced me to go through all the tech files, so fixed the array spacings and trailing 0's. Grepped for .0, found a couple more and fixed. Units_demo map and structree don't reveal any issues

Jun 28 2019, 5:54 PM

Jun 22 2019

elexis awarded rP22116: Nuke the misleading Structure_Defence from the wallset template name a Like token.
Jun 22 2019, 5:44 PM
elexis awarded rP22115: Move the fish template under template_gaia since fish is a resource like trees… a Like token.
Jun 22 2019, 5:44 PM

Jun 19 2019

bb added a comment to D2002: Support for arbitrary attack types..

For reference this was a WIP while I was working on the full system https://github.com/0ad/0ad/compare/master...bb-bb:t252_secondAttack. I have a little better version iirc, but that needs a rebase before uploading.

Jun 19 2019, 11:36 AM
bb added a reviewer for D2002: Support for arbitrary attack types.: bb.
Jun 19 2019, 11:05 AM
bb added a comment to D2002: Support for arbitrary attack types..

I indeed have a branch for the secondary attacks, which also generalizes the attackTypes. That branch is pretty much a more or less complete version of this revision, I will update that branch to current svn soon, but that will come after my exams of next week...

Jun 19 2019, 11:05 AM

Jun 5 2019

bb added a comment to D1953: every technology modification on a new line.

it "should", but noone was ever crazy enough to spend some hours/days/weeks/month/years/centuries adding all the spaces

Jun 5 2019, 8:56 PM
bb added a comment to D1953: every technology modification on a new line.

Well no, { "key": value } is the convention in js, so also in the json...

Jun 5 2019, 8:37 PM
bb added a comment to D1936: Load damageTypes from "simulation/data/damagetypes"-files..

So to me the main question is really "do we need to soft-code damage types anywhere"? Can we get away with just art and templates specification?

It seems this question is equivalent to asking "do we need a list of all possible damageTypes somewhere in the code?" Retrieving the list from looking at all templates doesn't look like worth it to me. For the sim, the answer seems to be "no", since a type only the present types in an attack schema actually do something, and a nonexisting in a damageReciever can be defaulted to 0. However for the gui consider the case that 1 unit attacks with an unique damageType, than no unit will have that type present in the Armour tooltip, sure the effective value is 0, but shouldn't we communicate that to the player? Considering this I would argue for the need of such a list and thus a softcodation.

Jun 5 2019, 8:34 PM

Jun 4 2019

bb added a comment to rP18964: Merge resource agnostic branch by s0600204, fixes #3934..

While duplicating a file in D1936:

Jun 4 2019, 11:04 PM

May 31 2019

bb committed rP22329: Merge persian and mauryan Archery Tradition technologies.
Merge persian and mauryan Archery Tradition technologies
May 31 2019, 11:35 PM
bb closed D1941: merge archery tradition.
May 31 2019, 11:35 PM
bb accepted D1941: merge archery tradition.

Given that there is more versioning on the persian file, rename that one instead

May 31 2019, 11:05 PM
bb committed rP22328: Rename Stables class to Stable since we use the singular forms..
Rename Stables class to Stable since we use the singular forms.
May 31 2019, 10:48 PM
bb closed D1890: Rename class Stables to Stable following introduction in rP22280.
May 31 2019, 10:48 PM
bb accepted D1890: Rename class Stables to Stable following introduction in rP22280.

No more instances of Stables left in the public mod

May 31 2019, 10:45 PM
bb added inline comments to D1939: redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb some duplication in the gui.
May 31 2019, 5:25 PM
bb created D1939: redo rP21036, Create a ConfigDB_CreateAndWriteValueToFile function to absorb some duplication in the gui.
May 31 2019, 4:59 PM
bb committed rP22326: Set ship status bars in parent.
Set ship status bars in parent
May 31 2019, 2:01 PM
bb closed D1842: Set ship status bars in parent.
May 31 2019, 2:00 PM
bb added inline comments to D1462: Enforce formation required member count.
May 31 2019, 1:56 PM
bb committed rP22325: Reduce defensive_wall* duplication.
Reduce defensive_wall* duplication
May 31 2019, 1:17 PM
bb closed D1794: template_structure_defensive_wall* simplification.
May 31 2019, 1:17 PM
bb accepted D1794: template_structure_defensive_wall* simplification.

Couple of minor issues, fixing while committing

May 31 2019, 1:16 PM
bb added inline comments to D1764: Dynamically sizes the dataCounter overlay.
May 31 2019, 1:46 AM
bb added inline comments to D828: Unselect lobby game if the selected player isn't present in any game.
May 31 2019, 12:54 AM

May 30 2019

bb added inline comments to D1790: Separate stable from barracks.
May 30 2019, 11:01 PM
bb committed rP22322: Seperate stable from barracks.
Seperate stable from barracks
May 30 2019, 11:00 PM
bb closed D1790: Separate stable from barracks.
May 30 2019, 11:00 PM
bb accepted D1790: Separate stable from barracks.
May 30 2019, 10:55 PM
bb accepted D1768: Formations: GetClosestMember passes wrong entity to filter function.

Once someone starts doing anything with formations, having such a big around can only be annoying, so rather fix it beforehand.

May 30 2019, 10:15 PM
bb added inline comments to D1790: Separate stable from barracks.
May 30 2019, 10:01 PM