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.
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.
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.
The Y coordinate at which to fire a projectile is currently assumed to
be the target's current Y, which is incorrect if the target is moving on
a slope.
This fixes that.
Note that this was purely visual, since projectiles still hit the target
regardless, as the height component is totally ignored, even if the
projectile is underground (in fact, the projectile's position is not
known in DelayedDamage::MissileHit, which just assumes it lands where it
said it would when fired).
As noted by bb in f737831167Fixes#5939
Differential Revision: https://code.wildfiregames.com/D3425
This was SVN commit r24766.
cf6aaf37a4fixed#5546, but it seems to cause some rare OOS in visual
replays, as reported in #5909. The culprit is likely that hashes aren't
computed at quite the same moment and onDestroy changes things.
Reverting for now before A24.
Reported by: Angen
Refs #5546.
Fixes#5909
This was SVN commit r24764.
- The MacOs script was not exporting the SVN revision properly.
- Rename the DMG to match the other's conventions.
- Clean up windows installer files ( Fixes#5955 )
Differential Revision: https://code.wildfiregames.com/D3370
This was SVN commit r24763.
Sound items were only deleted after 'last play' when stopped, but they
could also be left in 'paused' or 'initial' states, and were then not
cleared until the game exits (effectively a memory leak). This affected
particularly music & ambient sounds, which also used the most
buffers(/memory).
On MacOS (at least), this resulted in OpenAL errors & sound failures
after a while playing the game, because MacOS has a max "in flight
buffers" of 1024.
Also clean up some control flow in CStreamItem
Reported by: Eszett
Thanks langbart for the consistent repro'.
Fixes#5265
Differential Revision: https://code.wildfiregames.com/D3445
This was SVN commit r24762.
This fixes a rare crash at map generation.
The water renderer could be left in an invalid state when exiting a
game, and would then crash on the next map generation in some cases.
Tested by: Stan
Differential Revision: https://code.wildfiregames.com/D3447
This was SVN commit r24759.
attackmoveUnit is more specific than attackMove, so since d0a42f2f00
won't fire at the same time. However the GUI code expected that,
breaking it.
Instead, properly check for either attackmove or attackmoveUnit.
Also fix an issue with d0a42f2f00 where hotkeys would be release if
switching to a more specific combination of the same hotkey.
Reported by: snelius
Fixes#5944
Differential Revision: https://code.wildfiregames.com/D3436
This was SVN commit r24752.
Victory music doesn't work in A24 SP. That's because the modal pauses
the game, and pausing the game pauses music.
This has been the case since c9a5d5cee5.
Auto-pausing the game (structree, ...) didn't really happen in the past,
but A24 makes it relatively common, and I think pausing the music is a
bit jarring then, so this simply removes that.
Reported by: Langbart
Fixes#5941
Differential Revision: https://code.wildfiregames.com/D3433
This was SVN commit r24744.
std::string_views are created pointing to vector-owned strings, but
those strings can use Short String Optimisation (storing the data
inline, i.e. in vector memory). When the vector is resized, the strings
are moved and those string_views now point to invalid memory.
To fix it, use std::deque which does not invalidate pointers on
push_back.
Fixes 5d2be02f68.
Reviewed By: vladislavbelov
Fixes#5950
Differential Revision: https://code.wildfiregames.com/D3441
This was SVN commit r24742.
Reduces the number of copying and decreases the computational
complexity.
Tested By: Stan
Differential Revision: https://code.wildfiregames.com/D3439
This was SVN commit r24740.
Current issue with the lobby, is that we make ips of hosts public for
anyone to read. This patch consists of 3 parts.
1.) Removing ips and ports from lobby javascript
2.) Removing need of script on the server to attach public ips to game
stanza by asking the host using xmppclient as proxy.
3.) Implementing password protected matches, to deny this information to
not trusted players.
Further description:
Do not send ports and stunip to the bots.
Removed from stanza.
Do not send ip to the lobby.
Removed from mapping gamelist from backend to gui (still on the backend
side, because it is done by script on 0ad server).
Get ip and ports on request when trying to connect.
On the host side, ask stun server what is host's public ip and remember
it.
On the client side, send iq through xmppclient to the hosting player and
ask for ip, port and if Stun is used, then if answer is success,
continue
with connecting, else fail.
Add optional password for matches.
Add password required identifier to the stanza.
Allow host to setup password for the match. Hash it on the host side and
store inside Netserver. If no password is given, matches will behave
as it is not required.
On the client side, if password for the match is required, show
additional window before trying to connect and ask for password, then
hash it
and send with iq request for ip, port and stun.
Server will answer with ip, port and stun only if passwords matches,
else will asnwer with error string.
Some security:
Passwords are hashed before sending, so it is not easy to guess what
users typed. (per wraitii)
Hashes are using different salt as lobby hashing and not using usernames
as salt (as that is not doable), so they are different even typing the
same password as for the lobby account.
Client remembers which user was asked for connection data and iq's id of
request. If answer doesn't match these things, it is ignored. (thnx
user1)
Every request for connection data is logged with hostname of the
requester to the mainlog file (no ips).
If user gets iq to send connection data and is not hosting the match,
will respond with error string "not_server".
If server gets iq::result with connection data, request is ignored.
Differential revision: D3184
Reviewed by: @wraitii
Comments by: @Stan, @bb, @Imarok, @vladislavbelov
Tested in lobby
This was SVN commit r24728.
9fc6c3c897 stopped supporting components with a non-null Serialize() and
a null Deserialize().
Unfortunately, these throw exceptions and it appears we have codepaths
that don't handle these exceptions (possibly all of them). Since this
error is likely, and easily fixable, and doesn't actually _crash_, I'll
issue a LogError for now.
This will possibly help modders update to A24.
Differential Revision: https://code.wildfiregames.com/D3422
This was SVN commit r24720.
This fixes chasing, particularly chasing ranged cavalry.
- Standardise the range of melee cav to 4.
- Decreases the speed of ranged cavalry slightly to make melee cavalry a
better counter & reduce the ability of ranged cavalry to dominate an
area.
- Fix UnitMotion to better chase units, by increasing direct-range
distance and making "from scratch" short paths recompute better paths
(by increasing the search range).
- Gives some free rotation time for slight angles to units. Angles below
30° take no time to rotate towards. Chasing units that recomputed a lot
of paths could be slowed down substantially by minute angle differences.
Fixes#5936
Differential Revision: https://code.wildfiregames.com/D3402
This was SVN commit r24708.
