Page MenuHomeWildfire Games

bb
User

Projects

User Details

User Since
Jan 24 2017, 12:54 PM (213 w, 2 d)

Recent Activity

Sun, Feb 7

bb updated the diff for D3530: Add defeat condition on civil centre loss.
Sun, Feb 7, 4:04 PM
bb added a comment to D3530: Add defeat condition on civil centre loss.

Perhaps the JSON should have a text/json MIME type?

Sun, Feb 7, 3:39 PM

Sat, Feb 6

bb requested review of D3530: Add defeat condition on civil centre loss.
Sat, Feb 6, 10:50 PM
bb requested review of D3528: Bring turnRate back to realism.
Sat, Feb 6, 10:22 PM
bb added a comment to rP24624: Make foundations not ConquestCritical.

Besides the disagreement in the revision, also conquest structure and nomad can be considered broken.

Sat, Feb 6, 10:21 PM
bb requested review of D3527: Compute the formation turnRate from member speeds.
Sat, Feb 6, 10:14 PM
bb retitled D3523: Bring projectile speeds to realistic values from Bring projectile speeds back to realistic values to Bring projectile speeds to realistic values.
Sat, Feb 6, 9:05 PM
bb requested review of D3523: Bring projectile speeds to realistic values.
Sat, Feb 6, 7:08 PM
bb updated the diff for D3267: Make projectiles run physical trajectories..
Sat, Feb 6, 2:44 PM
bb updated the diff for D3267: Make projectiles run physical trajectories..
Sat, Feb 6, 2:32 PM

Jan 19 2021

bb raised a concern with rP24701: Use UnitMotion to predict target position in Attack.js to prevent 'dancing'.

You messed up the height. Prior to the commit the 3d position was linearly extrapolated, so we assumed a constant slope. The new calculation uses the actual position, so we better use the actual height at that position which can be different at different positions. You now assume a horizontal surface. You do need to go through the fuzz of computing the height from the position component (see earlier diff), but add it manually outside the UM.

Jan 19 2021, 5:19 PM

Jan 18 2021

bb added a comment to rP23678: Allow timers to update their interval..

No the issue is not fixed here, since the update function is not used by the unitai component (or anywhere really).

Jan 18 2021, 8:50 PM

Jan 16 2021

bb added inline comments to D3225: Stop dodging arrows by spamclicking or patrol: Change the targetting code to account for "end of path".
Jan 16 2021, 9:37 PM

Jan 15 2021

bb planned changes to D3225: Stop dodging arrows by spamclicking or patrol: Change the targetting code to account for "end of path".

Formations need fixing.

Jan 15 2021, 11:00 AM

Dec 31 2020

bb added a comment to D3274: [gameplay] Increase turn rate of most unit types slightly.
In D3274#145490, @borg- wrote:

It is unrealistic for infantry that takes so long to turn around, its damage the gameplay.

Faster rates are unrealistic. Try it yourself rotating 180deg in .5 seconds is already pretty fast (which is about what 6 means here). The fact it is harder to retreat,is completely realistic. And yes it changes gameplay, but it is a feature not a bug.

Dec 31 2020, 3:22 PM

Dec 30 2020

bb added a comment to D3274: [gameplay] Increase turn rate of most unit types slightly.

Requestign abandonment, completly unrealistic, looks horrible etc.

Dec 30 2020, 3:18 PM
bb requested review of D3271: Try to limit rotations towards obstructions #2.
Dec 30 2020, 2:23 AM
bb requested review of D3270: Try to limit rotations towards obstructions.
Dec 30 2020, 1:21 AM
bb added a comment to D3265: [gameplay] - Permadeath for heroes..

This has been proposed several times. Didn't search any logs, hope you did. Personally no opinion.

Dec 30 2020, 1:17 AM
bb updated the diff for D3247: Use rotation times on all unitMotion driven rotations..

Make sure idle states return to NONE movement state. Remove the faceTowardsTarget state, since we can just tell stopMoving whether it should turn a bit.

Dec 30 2020, 12:21 AM

Dec 29 2020

bb committed rP24471: Only have techs that affect the bolt and art tower researchable there..
Only have techs that affect the bolt and art tower researchable there.
Dec 29 2020, 10:22 PM
bb closed D3266: fix tower production queues.
Dec 29 2020, 10:22 PM
bb accepted D3266: fix tower production queues.
Dec 29 2020, 10:20 PM
bb added a comment to D3266: fix tower production queues.
Dec 29 2020, 10:20 PM
bb updated the diff for D3267: Make projectiles run physical trajectories..

height

Dec 29 2020, 10:15 PM
bb updated the diff for D3267: Make projectiles run physical trajectories..

Remove some redudant template entries

Dec 29 2020, 10:01 PM
bb added inline comments to D3267: Make projectiles run physical trajectories..
Dec 29 2020, 9:49 PM
bb requested review of D3267: Make projectiles run physical trajectories..
Dec 29 2020, 4:31 PM
bb added a comment to rP24446: Change tower armour tech to a roughly equivalent health one.

The point is bolt and artillery towers can research technologies that don't affect them.

Ah right, but that should be fixed indeed.

Dec 29 2020, 2:40 PM
bb added a comment to rP24446: Change tower armour tech to a roughly equivalent health one.

Did this intentionally. A bigger tower has the upgrades for all towers, makes perfect sense to me. At a sentry one is lesslikely to try out new things and do research than at a bigger tower, which can have more resources. AFAIK we also have some persian tech in the cc affecting wonders, perfectly fine too imo.

Dec 29 2020, 2:21 PM
bb added a comment to rP24458: Increase projectile speed slightly across the board..

Our ranges make perfect sense, in meters.

Our meters are completely arbitrary units, and whether units fire at 80 or 10 meters is entirely dependent on how big our maps, units, buildings are, not on the 'real' range of bows. So I don't see how arrow speed should be 80 just because in real life they travel around 80m/s.

Ofcourse we can rescale everything. And yes buildings are much to big compared to units. But related things, especially values of the same component, should be scaled in the same way. So since we have ranges which can be thought of in meters, we should consider the unit to be meters and work with that.

Our attacktimes make perfect sense, in seconds.

Archers don't fire at 60 hertz. I'm not sure what your point is either.

You can't do like that? Search in some prominent video platform, ppl will perform it. Ofcourse in battles with groups of archers, they would synchronise shoots and thus shoot slower. But our units are mostly individuals, so they would shoot much faster.

In rP24458#46599, @bb wrote:

the speed doesn't matter in this (we know the speed so we can account for it).

This is incorrect, since the speed can change, which is the whole reason why we're in this mess in the first place. Even with D3225 or D3255, it's a somewhat relevant factor.

Thats entirely the point, the speed vector can change. But the length of it is not the relevant factor, the direction is much more relevant.

The opportunity to change course does matter and this is largely determined by turnlength

And that makes it not a great backbone for a fix, since it's ultimately arbitrary.

You mean changing arrowspeed is?

Increasing projectile speed reduces time-to-hit, which of course increases the likelihood of a hit.

I won't oppose that, I merely say its not the correct way to go about it.

Dec 29 2020, 2:17 PM

Dec 28 2020

bb added a comment to rP24458: Increase projectile speed slightly across the board..

Expressed my concerns many times.

Not on the diff, not that it matters much.

Haven't seen any comment on the diff...


In rP24458#46534, @bb wrote:

If you wish to compare with unit speeds, you should rather lower the unit speeds.

I don't understand why you say that. Reducing unit movement speed will completely change the feel of the game, and the units are entirely arbitrary. It's not like our "meters" are any realistic right now? "Realism" above can only refer to ratios of unit walk speed to arrow speed, and the change here indeed makes it more realistic.

Our ranges make perfect sense, in meters. Our attacktimes make perfect sense, in seconds. That are the values one should consider for realism in this case, not another concept as motion. Secondly iirc you have said multiple times you found the game to fast, you just missed an opportunity...

The claim dancing is fixed by this is false, since dancing had been made impossible prior.

I factually demonstrated that faster arrows help with dancing (see ticket), and now you're just asserting that dancing is impossible when actual players have raised concerns on the turning diff. I don't think we can actually ignore other factors.

Players have reason concerns about issues already present in the game, just highlighted by the turning. That is not turning fault, is the fault of other bugs (and yes we should fix those).

Ratio with unit speed is not the interesting value. Turnlength much more relevant for the problem at hand, if there is any problem left.

Except it's not ? Turn lengths could be 10ms, and fast units with slow projectiles would lead to dancing.

UnitSpeed should be compared to spread: both determine a distance by which we will/can miss. The arrrowSpeed largely determines the time till hit, by which predict the estimated target, the speed doesn't matter in this (we know the speed so we can account for it). The opportunity to change course does matter and this is largely determined by turnlength. Do note that the shorter the turn, the worse it gets.

Dec 28 2020, 2:33 PM

Dec 27 2020

bb added a comment to rP24458: Increase projectile speed slightly across the board..

Expressed my concerns many times. Assuming m/s unit this makes arrows fly 360km/h. According to some quick search arrows had speeds between 150-200mph when leaving the bow. This will yield 66-83m/s. Considering some friction, to first order, you should lower these speeds further. Also consider that this is the horizontal speed so there is a factor cos(pi/4) in the equation too. So the original values made much more sense to me. If you wish to compare with unit speeds, you should rather lower the unit speeds.

Dec 27 2020, 1:05 PM
bb added inline comments to D3249: Move parabolic range computation to rangemanager.
Dec 27 2020, 12:57 PM
bb resigned from D3241: Don't turn and turn when attacked while fleeing..

agreeing with the code, but unelectable as reviewer.

Dec 27 2020, 12:16 AM

Dec 26 2020

bb added a comment to D3255: Better estimate a moving target position in UnitMotion.

There are two things:

  1. If one uses the unitMotion overlay one can observe that the computed position are "catching up" with the target every turn. So we only look in the future, if you want to call it like that, because our pathfinder is running async (which we should do ofc) and thus the new target will only be used for actual walking the next turn, when the target has made its move. So effectively we are moving without any knowledge of the future. IRL the pathfinding would happen instantly (no need to look on a map where the target is, if you see it...)
Dec 26 2020, 11:49 PM
bb added a comment to D3255: Better estimate a moving target position in UnitMotion.

You haven't even read the whole post. Read the first sentence again, and you see it is total nonsense you write now.

Dec 26 2020, 4:50 PM
bb added a comment to D3255: Better estimate a moving target position in UnitMotion.

Don't see how this is cheating: if you see someone walk, you can tell if he is going to take a turn before he actually makes a turn. Also you know someone is gonna stop if he is going to bumb into something. Notice we do not read of next orders given to the entity (that is arguably looking into the future), just use the path the entity already has.

Dec 26 2020, 4:44 PM
bb accepted D3224: Switch to the running animation only above a certain ratio of the walk speed..
Dec 26 2020, 4:39 PM
bb accepted D2425: Show number of builders besides (not in space) build time..

fix the indents

Dec 26 2020, 12:29 PM

Dec 25 2020

bb requested review of D3255: Better estimate a moving target position in UnitMotion.
Dec 25 2020, 11:38 PM
bb planned changes to D3247: Use rotation times on all unitMotion driven rotations..

IsPotentiallyMoving will give some more love, need excerpts from D3225 before

Dec 25 2020, 6:40 PM
bb updated the diff for D3247: Use rotation times on all unitMotion driven rotations..

don't early return in moveTo

Dec 25 2020, 6:39 PM
bb committed rP24447: var => let and some periods in fogging.
var => let and some periods in fogging
Dec 25 2020, 6:03 PM
bb added a comment to D3200: Stop dodging arrows by spamclicking or patrol: Combine rotations with acceleration..

Acceleration helps because the unit will stop at each waypoint and goes much slower on small segments and thus is much more likely to get hit.

Dec 25 2020, 5:59 PM
bb added a comment to D3247: Use rotation times on all unitMotion driven rotations..

k, got another option, havent tested it: we change the two instance of cmpControllerMotion->IsMoveRequested() to cmpControllerMotion->IsPossiblyAtDestination().

Dec 25 2020, 5:46 PM
bb added a comment to D3247: Use rotation times on all unitMotion driven rotations..

The isMoveRequested function changed is only called from unitMotion. Why the change is required is that otherwise no movesucceeded and moveFailed messages are send to members when a formation is in rotation state, even when its not rotating anymore. This is not the unitAI fault, its unitMotion not sending messages it should send. Also the other usages of the function, actually don't want to know if the moverequest is not NONE, but whether we are potentially moving, other moverequest which for which there is a clear destination, can always be added to the new function.

Dec 25 2020, 5:41 PM
bb accepted D3252: Fix upgrades not being sorted by phase in structuretree.

seems correct
no other instances of phaseSort found

Dec 25 2020, 4:10 PM
bb updated the summary of D1264: Tabs hotkey tooltips.
Dec 25 2020, 4:06 PM
bb updated the diff for D1264: Tabs hotkey tooltips.

Rebase, rethink, redo

Dec 25 2020, 4:04 PM
bb commandeered D1264: Tabs hotkey tooltips.
Dec 25 2020, 4:02 PM
bb updated the diff for D3022: Allow cText to be non-wrapping.

rebase

Dec 25 2020, 3:21 PM
bb added inline comments to D3251: Allow garrisoned entities to upgrade..
Dec 25 2020, 2:59 PM
bb added a comment to D2937: [gameplay] tower_armour → tower_health.

Please close the revision, bots are not liking me apparently

Dec 25 2020, 2:38 PM
bb added inline comments to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Dec 25 2020, 2:37 PM
bb added a comment to D2951: [gameplay] merge wonder population auras.

Not exactly what I mean: +5% +15% will yield +20.75% if I am not mistaking

Dec 25 2020, 2:29 PM
bb added a comment to D3241: Don't turn and turn when attacked while fleeing..

Feel free to try the attacked handler I posted above. That allows the turning back, reduces new orders being send and fixes the most prominent case of the re-turning (might not work perfectly in case of many attackers)

Dec 25 2020, 2:28 PM
bb accepted D3099: Play sound of entity that is actually able to perform command..

reads correct and complete
front doesn't fall

Dec 25 2020, 2:23 PM
bb added a comment to rP24415: Let units take time actual time for turning while moving. This limits the….

Also for the shift laggyness, there is D3230, ought to be committed soonish

Dec 25 2020, 2:15 PM
bb added a comment to D2661: Get attack effects from JSON..

Looks good, didn't test

Dec 25 2020, 2:12 PM
bb added inline comments to D3249: Move parabolic range computation to rangemanager.
Dec 25 2020, 2:07 PM
bb updated the diff for D3249: Move parabolic range computation to rangemanager.

remove position from buildingAI

Dec 25 2020, 2:07 PM
bb added a comment to rP24415: Let units take time actual time for turning while moving. This limits the….

Yeah formations are failing on member death. This patch only highlights the issue, see D3236. We should fix that.

Dec 25 2020, 2:00 PM
bb added a comment to D3200: Stop dodging arrows by spamclicking or patrol: Combine rotations with acceleration..

We can buff the accelerations a bit maybe. Only doing the cutoff is a no go considering dancing, since one can try "rectangle dancing" then

Dec 25 2020, 1:56 PM

Dec 24 2020

bb accepted D2852: [gameplay] Tweak maurya worker elephant stats.

elephant archer has 4/3 armour. Can agree on the 2/2 propoed by borg also health ==200 seems good.

Dec 24 2020, 6:41 PM
bb added a comment to D2951: [gameplay] merge wonder population auras.

Certainly agree on making it a % instead of a flat value. Not sure If I like the nuking of the pop bonus on plain wonder. Yes they have other advantages too, but the main reason to build it is the pop bonus, so I did keep some bonus for plain wonders too. Maybe 5% on plain wonder, 15% on tech?

Dec 24 2020, 6:32 PM
bb updated the test plan for D2975: damage resistance from nonNegativeDecimal to decimal.
Dec 24 2020, 6:11 PM
bb updated the diff for D2975: damage resistance from nonNegativeDecimal to decimal.

negative decimal example

Dec 24 2020, 6:11 PM
bb added a comment to rP24446: Change tower armour tech to a roughly equivalent health one.

Reviewed By: borg too

Dec 24 2020, 6:06 PM
bb committed rP24446: Change tower armour tech to a roughly equivalent health one.
Change tower armour tech to a roughly equivalent health one
Dec 24 2020, 6:02 PM
bb accepted D2937: [gameplay] tower_armour → tower_health.

Templates need some update

Dec 24 2020, 5:59 PM
bb updated the diff for D2975: damage resistance from nonNegativeDecimal to decimal.

Allow negative resistance

Dec 24 2020, 5:41 PM
bb commandeered D2975: damage resistance from nonNegativeDecimal to decimal.
Dec 24 2020, 5:39 PM
bb closed D3134: fix some typos.
Dec 24 2020, 5:31 PM
bb committed rP24445: Fix some translatable strings.
Fix some translatable strings
Dec 24 2020, 5:26 PM
bb accepted D3134: fix some typos.
Dec 24 2020, 5:24 PM
bb added a comment to D3211: Add a script to download compile and install wxwidgets.

This is meant for ppl not having wx installed, but do know how this script is ran. Or is it run automatically somewhere? Can't ppl just use the wx provided installer?
What happens for newer versions of wx?

Dec 24 2020, 5:00 PM
bb added inline comments to D3224: Switch to the running animation only above a certain ratio of the walk speed..
Dec 24 2020, 4:49 PM
bb updated the diff for D3247: Use rotation times on all unitMotion driven rotations..

Rename

Dec 24 2020, 4:40 PM
bb abandoned D690: When an alertRaiser is captured, its units under alert should not be controllable by the enemy.

Superseeded by D681

Dec 24 2020, 4:25 PM
bb requested review of D3249: Move parabolic range computation to rangemanager.
Dec 24 2020, 4:25 PM
bb added inline comments to D690: When an alertRaiser is captured, its units under alert should not be controllable by the enemy.
Dec 24 2020, 4:20 PM
bb added inline comments to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Dec 24 2020, 3:11 PM

Dec 23 2020

bb abandoned D375: Progress more quickly next item in queue & remove duplicate call.

I don't reproduce the issue anymore. I don't see any time gap between two consecutive batches, nor on the first batch. Maybe it got fixed in the mean time. For now I will abandon the patch, please reopen if the issue persists.

Dec 23 2020, 10:57 PM
bb updated the diff for D285: Lobby player search input.
Dec 23 2020, 6:51 PM
bb committed rP24441: Also do transform.
Also do transform
Dec 23 2020, 6:48 PM
bb added inline comments to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Dec 23 2020, 6:45 PM
bb updated the diff for D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.

rebase
Remove some unneeded health code

Dec 23 2020, 6:44 PM
bb committed rP24440: cp => CapturePoints.
cp => CapturePoints
Dec 23 2020, 6:27 PM
bb closed D3248: cp => capturePoints.
Dec 23 2020, 6:26 PM
bb updated the diff for D3247: Use rotation times on all unitMotion driven rotations..

Let units hang in ROTATE (renamed to ROTATEPOINT). This should make D2870 relative simple by adding a ROTATEENTITY.
This does mean we need to adapt the IsMoveRequested function. Maybe it needs a rename...

Dec 23 2020, 6:05 PM
bb updated the diff for D3248: cp => capturePoints.
Dec 23 2020, 5:59 PM
bb added a comment to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.

I'm mostly questioning this because I don't really understand why unitAI has to proxy these arguments. It seems to me unitAI could work with explicit attack names?

unit_actions.js/input.js give the order in gui, however it does it for the whole selection at the same time (as it should btw). So we arrive in commands.js with 1 order for many units. There is no guarantee the all will do the same (they are different units). Commands.js just pipes it through to unitAI (one could handle it there, but commands.js is not made for doing anything behavuour related). So one gets in the unitAI and thus propagates the variables. Also notice the attack commands send by the gather state that must not capture (we want to kill the animal), so we should handle it in the UnitAI.

Dec 23 2020, 5:26 PM
bb added a comment to D3247: Use rotation times on all unitMotion driven rotations..

So then you are equating the ROTATE state with NONE in some cases and and not in other cases... You will loose the NONE <-> not doing anything which is assumed all over unitMotion

Dec 23 2020, 5:00 PM
bb added a comment to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.

I'd like some more details on the projectile / no projectile split.

An attack type can have a projectile or not. When it has it will use the code which currently falls under "ranged", if it doesn't it attacks more like any other type.

Dec 23 2020, 4:57 PM
bb requested review of D3248: cp => capturePoints.
Dec 23 2020, 4:45 PM
bb added inline comments to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Dec 23 2020, 4:35 PM
bb added inline comments to D368: Gameplay Scripting: Entity and Actor coding for Secondary Attacks.
Dec 23 2020, 4:34 PM
bb accepted D3245: Show a default value in playersFilter input to show user what it is for [v2].

Front doesn't fall, change is for the better

Dec 23 2020, 3:56 PM
bb added a comment to rP24415: Let units take time actual time for turning while moving. This limits the….

hmm ok, see the issue: clickspam around a unit to another side of an obstruction. The problem here is that we don't know the actual path yet when we start to move. For the first turn we just try to move in the correct direcion, which can be wrong. Hence we try turning there too, which wastes some time, and thus we move slower/not at all.

Dec 23 2020, 3:54 PM