- ca9109be75 moved SwapBuffers inside Render - this makes Atlas call it
twice in a row which might behave oddly (did not seem to though) and
anyways was wasteful.
- ca9109be75 moved IdleTask from the sound manager outside of Render.
This means atlas never called IdleTask, and this broke sounds after a
few seconds.
Reviewed By: Angen
Differential Revision: https://code.wildfiregames.com/D2029
This was SVN commit r22544.
Consistently warn instead of using implicit conversion when not passing
a boolean, for consistency and callers being more cautious with passed
values.
This was SVN commit r22538.
* JSI_GUIColor::construct and JSI_IGUIObject::setProperty hunk are
duplicates of FromJSVal, getProperty of ToJSVal, following 7c2e9027c2.
* The constructor, it's fallback magenta and toString have never been
used by JS.
* A JS color class providing some methods (such as found in color.js,
refs #5387, and the unused toString redundant with rgbToGuiColor, see
also eee8217b45) is more inviting to changes and maintenance if defined
in JS and can still be instantiated in C++, like the Vector2D (see also
65b02395b3).
* PredefinedColors (such as "red" or "green") can be obtained from the
prototype without defining the class in C++.
* Minimize ugliness by removing macrosity, refs 8ceb41212d.
Rename alpha to a in guiToRgbColor from eee8217b45 for consistency with
the C++ conversions (opaqueness had been skipped in the only callers of
this JS function yet).
Delete unused GUISTDTYPE Mouse in header forgotton in 8734efca94.
This was SVN commit r22534.
This fixes a regression introduced by 055c848c1a: when an entity is
ordered to move to a target within short path distance (or direct path
distance), it no longer computed at least one long path, which meant it
could be stuck forever if the target was not actually reachable (such as
behind a wall).
To fix this, compute a long path after 3 failed computations, which
should result in a delay of 1-3 turns. The previous code did this after
1 failed try - the decision to make it 3 is mostly based on the idea
that in most cases, being stuck means we ran into units, not that we
were ordered somewhere close. Should there be complaints, it could be
lowered to 2 or 1.
This fixes a second issue, reported in #4473: units sometimes get stuck,
particularly when trying to garrison a turret from 'inside' the walls.
The issue is that the turret is not accessible via the inside as its
obstruction + garrison range is blocked by the surrounding walls.
However, as introduced by 6e05a00929, TryGoingStraightToTargetEntity
ignores all entities with the obstruction group of the target (the
reason for this being that otherwise it would never succeed, since the
line towards the target would likely go through the target).
For walls and formations, this means ignoring possibly too many
entities, and in the case of #4473, ignoring wall pieces. The unit thus
mistakenly thought it could direct-path to the turret, and got stuck.
To fix this, we can ignore specifically the targeted entity's
obstruction tag. This can be considered a fix to 6e05a00929.
temple accepted an earlier version of this patch (specifically elexis'
version).
Fixes#4473
Based on a patch by: elexis
Differential Revision: https://code.wildfiregames.com/D1424
This was SVN commit r22533.
The constructor is invalid, because one cannot create or obtain and pass
an IGUIObject C++ class instance pointer via JS, only triggering a crash
when doing something with it.
If there was a use case, the GUIObject should be created with a
GUIObject type specific constructor.
Remove obsolete getProperty comments.
From D1699, refs #5369 and wraitiis equivalent:
Differential Revision: https://code.wildfiregames.com/D1933
This was SVN commit r22530.
As reported by #5521, Ordering units to walk to a point in a forest can
lag terribly, as units will end up computing long short paths in the
forest, which can result in `ComputeShortPath` calls that individually
take upwards of 80ms.
This can be alleviated by allowing units to stop a bit earlier. A23
handled this in UnitMotion directly, but it's better to handle this in
UnitAI to avoid surprises and to make it customisable on a per-state
level.
This diff further speeds up using the short pathfinder by starting with
a smaller search range, limiting the max-range more and moving the range
slightly towards the goal.
This also refactors UM sending messages to UnitAI so that we may in the
future push more information (in particular, the entity_id that a unit
was obstructed by could be interesting for COMBAT).
This doesn't fix the possibility of lag, but it reduces its occurrence
to levels that should be similar to A23 and thus acceptable enough.
Tested By: Freagarach
Fixes#5521
Differential Revision: https://code.wildfiregames.com/D2105
This was SVN commit r22526.
Removes a few non-behavioral workarounds for older versions.
Refs #5502, #2891.
Accepted By: asterix
Comments by: vladislavbelov
Differential Revision: https://code.wildfiregames.com/D2076
This was SVN commit r22508.
Units right now try going to their next long waypoint using the
short-range pathfinder. This works, but it tends to leads to units
clumping together when shuttling for example.
By switching to short paths earlier, and by scrapping the long waypoints
when doing so, we can make movement more natural until we have unit
pushing.
Some cleanup in how the short-path domain range gets handled, and
increase the max-range by one tile to improve rare cases.
Differential Revision: https://code.wildfiregames.com/D2095
This was SVN commit r22507.
Port the script to Python 3, fix some bigs in it, and remove whitespace
from the output.
Reviewed By: bb
Differential Revision: https://code.wildfiregames.com/D1810
This was SVN commit r22499.
As reported by @bb in #5512, catapults and other big-range units might
not approach targets correctly when trying to get in range.
To be sure that we will be in range of a square obstruction approximated
as a circle, we need to consider the inscribed circle and not the
circumscribed circle.
Reported by: bb
Fixes#5512
Differential Revision: https://code.wildfiregames.com/D2086
This was SVN commit r22495.
5c642611c4 introduces undefined behaviour: for vertices that are part of
non-AA squares, the value of "quadOutward" is undefined. This fixes that
by again setting it to QUADRANT_ALL by default, as it was pre
5c642611c4. This led to OOS.
Reviewed By: elexis
Fixes#5508
Differential Revision: https://code.wildfiregames.com/D2082
This was SVN commit r22483.
Add two missing error reports.
Move sanity check prior to the first variable use.
Differential Revision: https://code.wildfiregames.com/D1817
Patch By: Angen
This was SVN commit r22476.
Three changes:
- Assume a certain incertain based on distance to the target, to avoid
recompute paths every turn when the target is far way and moving.
- Handle cases where the target is unreachable to the long-range
pathfinder and we would be recomputing every turn.
- If we went straight, assume we don't need to recompute a path.
These together make moving entities recompute paths far less often,
speeding up the game.
Differential Revision: https://code.wildfiregames.com/D2066
This was SVN commit r22474.
Compute the outward quadrants once and for all instead of setting them
dynamically, because there is no reason why we should always arrive from
the same quadrant as the first time we see a vertex.
Don't consider quadrants for the start-vertex, because of the edge
expansion (which can put us in illegal quadrants)
These result in (much) better paths, the tradeoff being that we now look
at some more vertices.
Fixes#5476
Differential Revision: https://code.wildfiregames.com/D1908
This was SVN commit r22473.
Since m_ExpectedPathTicket.m_Type is uninitialised before being used,
serialisation could fail with an out of bouds error. This fixes it by
giving it an (arbitrary) default value.
Reported by: gameboy
Confirmed and debugged by: Angen
Reviewed By: Angen
Differential Revision: https://code.wildfiregames.com/D2074
This was SVN commit r22470.
Contrary to wxWidgets documentation, wxMenuEvent::GetMenu() can return
NULL when the system menu is accessed on wxMSW, see
https://trac.wxwidgets.org/ticket/18443.
This was SVN commit r22467.
This adds back the "domain" edges to the short/vertex pathfinder.
Without these edges, units could use points far away from the path
search that they inaccurately thought were reachable, leading to some
pathing oddities in rare cases.
Reviewed By: temple
Differential Revision: https://code.wildfiregames.com/D443
This was SVN commit r22465.
Reorder code flow, handle long paths and short paths in a more explicit
manner, and only fail after a certain number of failed path computations
to avoid going idle too easily.
Make sure WALKING orders in UnitAI stop when the move fails to avoid
units being stuck.
Differential Revision: https://code.wildfiregames.com/D1907
This was SVN commit r22464.
As reported by @Freagarach on #5496, there can be broken behaviour as
UnitMotion::PathResult may call RequestLongPath with an uninitialised
path goal when ComputeGoal fails.
To fix this, check the return value everywhere and react accordingly in
case of failure.
Fixes#5496
Differential Revision: https://code.wildfiregames.com/D2063
This was SVN commit r22458.
m_PathState kept 3 pieces of information that can be deduced using other
variables:
- whether the entity was following a path. This can be better deduced
by checking if the entity has short/long waypoints.
- whether a path is currently being requested. This can be better
deduced by checking the value of m_ExpectedPathTicket
- whether the requested path is long or short. This can be stored
directly alonside the path request ticket number, making it more obvious
why it exists.
With these changes, m_PathState can be removed.
Differential Revision: https://code.wildfiregames.com/D1903
This was SVN commit r22456.
It is generally better to use the movement request data as that is our
actual target and goals are just a representation of that at any given
time. Where a PathGoal is required, compute this lazily.
This allow failing easily in MoveToX() functions if the goal cannot be
computed.
Differential Revision: https://code.wildfiregames.com/D1902
This was SVN commit r22452.
Introduced by 70e22e2923. PositionChanged messages sent between
MT_Destroy handling in CmpObstruction and the actual destruction of the
component could re-recreate an obstruction, which would then live
forever in the obstruction manager.
This prevents that by de-activating the obstruction when it is
destroyed, so that further PositionChanged messages do nothing.
Differential Revision: https://code.wildfiregames.com/D2060
This was SVN commit r22451.
MoveToPoint and MoveToTarget both compute a goal from a move request.
They can be combined to reduce duplication and streamline the code.
Differential Revision: https://code.wildfiregames.com/D1984
This was SVN commit r22450.
HandleObstructedMove contains logic to drop long waypoints, should they
be occupied by units (because that can get the pathfinder stuck, since
the long-range pathfinder can find a path, but not the vertex one).
However PathResult already drops waypoints this way, so this code can be
removed for simplification.
Differential Revision: https://code.wildfiregames.com/D1981
This was SVN commit r22448.
This fixes a number of issues with formations:
- Gives the controller an obstruction. This fixes the bug where units in
formations can't gather from a tree.
- Stop special-casing formation members in PathResult. This fixes
formation members being stuck in-place when they run in an obstruction.
- Makes sure units stay in Formation.IDle when they are idle so that
D1337/D1901 can work correctly in the IDLE state.
- Warn if animals enter this state.
- Make sure that formation members that end up in INDIVIDUAL.IDLE go
back to FORMATION.IDLE for sanity and for better housekeeping (refs
#3144 - fixed completely upstream).
Differential Revision: https://code.wildfiregames.com/D2048
This was SVN commit r22447.
wraitii