The 'controller' of an MP game (the host in general, though dedicated
servers would change that) is currently whoever first tells the server
that it is. This can be abused since it relies on trusting the clients.
This changes that logic: the server defines a 'controller secret', and
the first client to sent the correct controller secret is the
controller. This is safe assuming the secret is unknowable enough (the
current solution wouldn't pass strict cryptography tests, but it's
likely good enough).
Reverts 1a3fb29ff3, which introduced the 'trust the clients' mechanic,
as a change over 'the first local IP is controller'.
Necessary step towards dedicated server, if we want to use the regular
gamesetup (Refs #3556)
Differential Revision: https://code.wildfiregames.com/D3075
This was SVN commit r24952.
The spawn code should not assume that obstructions will never be
0-sized.
Reported by: Zack
Fixes#6039
Differential Revision: https://code.wildfiregames.com/D3583
This was SVN commit r24945.
Also incorporate retry improvements by Stan
Reported by: madPilot
Differential Revision: https://code.wildfiregames.com/D3585
This was SVN commit r24944.
Last alpha 24 commit was [[SVN:24937]]. [[SVN:24938]] was because the CI
wasn't turned off.
Comments by: @wraitii, @Freagarach, @Nescio,
Differential Revision: https://code.wildfiregames.com/D3571
This was SVN commit r24939.
ParticleManager uses <list> which has recently become unincluded.
Differential Revision: https://code.wildfiregames.com/D3589
This was SVN commit r24936.
file="" properties were not overriden by other things defined in the
actor, which lead to weird edge cases, such as frequency="0" variants
being loaded because their names="" ended up matching their parent's
name=""
Also remove the name because it doesn't serve a purpose
Accepted by: @wraitii
Differential Revision: https://code.wildfiregames.com/D3572
This was SVN commit r24929.
- Remove not included languages from the installer.
- Add credits for other languages, even if they are not included.
Differential Revision: https://code.wildfiregames.com/D3568
This was SVN commit r24927.
Obstructions can reactivate after being destroyed, which leaves them
dangling forever. This is similar to 54f7a09a54.
This fixes this issue by setting a temporary "is destroyed" variable to
true.@
Reported by: seeh
Tested by: langbart
Reviewed By: Freagarach
Fixes#6016
Differential Revision: https://code.wildfiregames.com/D3558
This was SVN commit r24894.
Also allows to use compressed vertex formats in future.
Tested By: Stan
Differential Revision: https://code.wildfiregames.com/D3553
This was SVN commit r24870.
5d96346ac5 proved unsufficient to fix formation 'waltzing'. This is a
better fix, which makes sure units actually try to reach their
designated offset in the first place.
Further, it removes code that recalculated offsets un-necessarily, which
led to an issue with "sloppy" formations such as open and closed orders.
Fixes#5997
Differential Revision: https://code.wildfiregames.com/D3543
This was SVN commit r24865.
Follow-up to 1a8de6d2b8. This makes it again possible to host without
STUN via the lobby.
The lobby bot will answer the host "Register" command with the external
IP. This is only sent to the host, avoiding IP leakage.
There is a small window in which a client might try to join and the
public IP isn't up, and the request goes through, but that seems rather
unlikely to be a problem in practice.
Refs #5913
Differential Revision: https://code.wildfiregames.com/D3490
This was SVN commit r24858.
Following #5913, mod_ipstamp is no longer required to enable STUN
hosting (it can only be useful to enable non-STUN hosting).
This updates the readme to reflect that, and fixes some markdown issues.
Differential Revision: https://code.wildfiregames.com/D3473
This was SVN commit r24857.
The "public" archive needs to be built with the mod mod active, to load
textures.xml files. This saves a few MBs as a side effect.
Fixes#6000
Differential Revision: https://code.wildfiregames.com/D3534
This was SVN commit r24847.
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.
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.
- 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.
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.
wraitii