Following 847f3a9995,
Units in formation can get very small movement offsets, that nonetheless
require large rotations, and thus at least 2 turns to accomplish.
However, following 847f3a9995, PossiblyAtDestination fires() only after
the first rotation, so the unit ends up 'waltzing' in place.
Before that diff, the unit never even moved since PossiblyAtDestination
fired straight away.
This is also noticeable since IDLE formation re-order their members
since 71a61d5f50.
The fix here is to ignore rotation time for very small offsets, which
lets units accomplish the movement in one turn and fixes the issue.
Reported by: wowgetoffyourcellphone
Reviewed By: Freagarach
Tested By: langbart
Differential Revision: https://code.wildfiregames.com/D3518
This was SVN commit r24831.
When hovering over the background, the scrolling was suddenly reversed
and could loop around.
Tested By: Langbart
Fixes#5993
Differential Revision: https://code.wildfiregames.com/D3514
This was SVN commit r24824.
Check for existence explicitly in the lobby GUI.
It would probably be better to not trigger errors in the cache
laoder/JSON code but instead print at the caller, depending, but that
requires changing a lot more code.
Reported by: Asger
Fixes#5988
Differential Revision: https://code.wildfiregames.com/D3506
This was SVN commit r24821.
Partial revert of 8df9d8dcc3. Following some testing, this build time
increase made early cav rushes too difficult.
Accepted by: borg-, FeldFeld, Valirhant
Reviewed By: Nescio
Differential Revision: https://code.wildfiregames.com/D3508
This was SVN commit r24820.
Issue described in #5945.
Unit finishing the order such as walking, will reach destination and if
attacked, imediately reacts to the attacker.
Hovewer, more desireble is for unit to look around since entering idle
state and pick the target if any using preference and then react to
attacker.
This issue rised up after finding of new targets have been moved from
enter to timer to avoid infinite loops after alwaysenterstate logic
removal.
Only downside here is unit will receive few hits before reacting as we
are waiting to the timer first. This happens only if unit goes idle.
Differential revision: D3504
Reviewed by: Freagarach
Comments by: wraitii
Fixes: #5945
This was SVN commit r24818.
I'm hoping this will give us more information on what's going wrong.
Also remove comments which were outdated since 7460d0e56e
Refs #5987
Differential Revision: https://code.wildfiregames.com/D3501
This was SVN commit r24811.
D3230 / 847f3a9995 introduced range checking at turn start, and removed
a hack that made units predict the position of their target too far
ahead. This worked fine when in "straight movement" mode, unfortunately
I failed to recognise that ranged units would never use that mode. This
meant that ranged-unit chasing was broken.
There is a straightforward fix however, since we can simply change
TryGoingStraightToTarget to be used by ranged units. It fixes the issue
efficiently and improves movement for ranged units in general, so it
probably should have been done from the start.
Refs #5936
Differential Revision: https://code.wildfiregames.com/D3489
This was SVN commit r24803.
Nerf cavalry movement speed somewhat, by reducing walk speed and their
run multiplier.
Further, following 6a66fb8205, units have a chance of going through
their target when chasing them. This diff adjusts melee cavalry ranges
from 4 to 6 to reduce the probability of that happening. The speed
reduction also helps with this.
Refs #5936
Differential Revision: https://code.wildfiregames.com/D3483
This was SVN commit r24802.
- Because units slow down when turning, and JPS paths often begin with a
J-shape, chasers can fail to catch up to slower chasee, because the
latter don't recompute paths as often. To fix this, ignore the first
waypoint if it's close by and the next is accessible.
- Don't interpolate the target position when interpolation isn't
necessary (i.e. when not processing the MT_Update_Motion* message), as
that resulted in the "follow known bad path" hack to active
un-necessarily.
- Tweak PathingUpdateNeeded, it will return true when it has no path to
follow
- Remove the direct-range consideration in the "distance uncertainty"
calculation.
Refs #5936
Differential Revision: https://code.wildfiregames.com/D3485
This was SVN commit r24800.
Slight debuff for cavalry: increase their build time but slightly above
10%, and increase the cost of the +10% movement speed technology.
Accepted By: FeldFeld, borg-, Nescio
Differential Revision: https://code.wildfiregames.com/D3476
This was SVN commit r24799.
Units movement is currently "all or nothing". This means that a chasing
entity that moves fast enough is likely to collide with its target, if
the latter is moving also. This means that it might fail to get in range
if the max range is smaller than the movement speed over a turn.
This happens to be very much the case in MP, as cavalry range is 4,
melee cav speed is ~20 and turns are 500ms.
This problem depends on which unit moves first (i.e. which unit is
lowest-ID).
To fix this, ignore the obstruction of the target, if it is moving, when
moving. This however means sometimes chasers will 'overshoot' and block
their target pathing, making the chase easier than it probably should
be.
Fleeing units don't suffer from this problem since they also ignore
their target (and their code handles it).
This new problem introduced in this diff is heavily dependent on the
exact speeds and ranges at play, and a further diff will improve the
situation to acceptable levels.
Reported by: FeldFeld
Refs #5936
Differential Revision: https://code.wildfiregames.com/D3482
This was SVN commit r24798.
Unit Motion currently checks if the unit is at destination during the
MT_Update_Motion* step, which happens late in the turn (notably, after
Timer.js) and moreover happens while entities are being moved (e.g.
entities with lower IDs have moved already, entities with higher IDs
have yet to do so).
This changes UnitMotion to instead check at turn start, which:
- benefits from in-turn path computations for more fluid movement
- ensure that distance checks aren't done against an entity that has
already moved for the turn.
The latter issue led to units failing to get in range of their target
when chasing them, in some situations.
As a side effect, this means that UnitAI move requests always take one
turn to succeed, so orders should be updated to check for range (or
they'll waste a turn). This is done for garrisoning, other orders were
already doing so.
Also includes a small tweak to avoid units rotating randomly when they
have no movement to accomplish.
Patch by: bb
Reviewed By: wraitii
Refs #5936
Differential Revision: https://code.wildfiregames.com/D3230
This was SVN commit r24797.
Display locked icon for matches with password, unlocked otherwise.
This should help players to avoid clicking to the locked matches, when
they do not know password.
Differential revision: D3480
Fixes: #5949
Comments by: Stan, Freagarach, wraitii, borg
This was SVN commit r24795.
As suggested by elexis, 1a8de6d2b8 should get some protection against
brute force attacks on password.
This is supposed to prevent attackers from getting connection data by
guessing the password.
Each failed attempt increases the counter.
XmppClient on the server side checks for the users with certain number
of failed attempts, determined in CNetServer, and refuses to check the
password, answering with banned message.
So they cant guess again in given match. Effect of this block will
dissapear after new match is created.
Differential revision: D3467
Comments by: wraitii, Stan
Tested by: Stan, Freagarach
Ref: #5913
This was SVN commit r24794.
The hotkey editor could modify hotkeys despite the changes being
cancelled.
Refs #2604, Fixes#5982
Differential Revision: https://code.wildfiregames.com/D3481
This was SVN commit r24793.
- Mercenaries should be green.
- Cart super dock icon used an old background
- Due to the reduced panel icon size it was easy to confuse the stables
with the barracks
- Due to the reduced panel icon size it was easy to confuse the corral
with the farmstead.png
Reported by: @wraitii @borg-
This was SVN commit r24792.
Units no longer stop when ordered to stand ground. Use the Stop
command/hotkey instead.
Reviewed By: Freagarach
Fixes#5975
Differential Revision: https://code.wildfiregames.com/D3463
This was SVN commit r24791.
Gather rates are not rounded, so after some modifiers are applied, they
appear as ugly decimal numbers.
Limiting them into 2 decimal places for readability and it looks nicer.
Differential revision: D3460
Reviewed by: @wraitii
This was SVN commit r24782.
Outposts have a vision range of 4. This however does not always reveal
FoW around them, which looks rather odd (see D3054).
Give them 10 vision so that it's obvious they are working, and clarify
the tooltip that garrisoning is needed to make them helpeful.
Fixes#5974
Differential Revision: https://code.wildfiregames.com/D3464
This was SVN commit r24779.
f2b3c4d8ec broke deserializing because it did not reset the mapsize on
Deserialize(), and thus the water renderer would not regenerate data.
Differential Revision: https://code.wildfiregames.com/D3461
This was SVN commit r24778.
Units sometimes ignored targets that entered their LoS. The cause is
d0fc8ff67d: range queries returned units farther away, and those units
might actually be out of range if distance is computed center-to-center,
which both UnitAI and LOS do. This meant that code relying on range
query updates was possibly broken, and indeed units missed things (see
ticket).
This introduces a boolean to switch between pre-d0fc8ff67d behaviour
(entity-as-point, center-to-center range queries) and post-d0fc8ff67d
(entities-as-circumscribing-circle, edge-to-edge range queries).
The former is used for UnitAI (where the new behaviour bugged), auras
(where varying structure sizes made it awkward) and build
restrictions(which simply did not really need it).
Reverts 7f1ee23d88, 050c5401b1 (with the exception of the iber monument
footprint), and the template changes in d0fc8ff67d itself.
It also reduces alertRaiser ranges slightly, this was missed in the
original diff.
#3381 is not reopened as BuildingAI still uses the new range queries.
Reported by: Freagarach
Comments By: Angen
Fixes#5968
Differential Revision: https://code.wildfiregames.com/D3456
This was SVN commit r24776.
Follows 1a8de6d2b8.
Validate the password when a client joins a game, so even a player that
knows the connection data cannot join.
Refs #3556, Refs #5913
Differential Revision: https://code.wildfiregames.com/D3438
This was SVN commit r24775.
Introduced in e543b01077.
Units entering cheering from idle state, may not check their surrounding
for pottential targets yet, so they will react incorrectly when
attacked.
Pointed out by @Freagarach in
https://code.wildfiregames.com/D1977?id=10404#inline-52415 and turned
out to be issue.
Differential revision: D3455
Fixes: #5966
Reviewed by: @wraitii
This was SVN commit r24774.
Make sure that any pending cheering order is deleted when leaving the
Cheering state, otherwise other unitAI states can behave weirdly.
This fixes issues with units cheering at incorrect time, then not
correctly picking their next target in a fight.
Reported by: snelius
Reviewed By: Angen
Refs #5966
Differential Revision: https://code.wildfiregames.com/D3452
This was SVN commit r24773.
Since 59d0885d68, there is a "LeaveFormation" order to support
queued-disbanding. However, I misread the code paths and FinishOrder()
isn't always called.
This fixes that oversight.
Reported by: Freagarach
Differential Revision: https://code.wildfiregames.com/D3450
This was SVN commit r24771.
When Petra encounters free technology or technology with no
researchtime, she will not start it and blocks the queue.
Also fixing seleucids.
Differential revision: D3388
Reviewed by: @wraitii
Comments by: @Freagarach, @Stan
This was SVN commit r24769.
