This makes it possible to make units heavier, which both push more & get
pushed less by other units.
In particular, the diff does it for siege units & elephants.
This improves movement for these units in crowd situation, since they
will now basically not move when other regular units push into them.
Supported By: asterix, marder
Refs #6127
Differential Revision: https://code.wildfiregames.com/D4452
This was SVN commit r26275.
This is a paradigm change for AI computation.
Historically, the AI was intended to be run in a separate thread from
the simulation. The idea was that slow AI wouldn't stop the renderer
from being smooth.
In that original design, the AI received a copy of the game world and
used that to run its logic. This meant the simulation could safely do
whatever it wanted in the meantime. This copy was done via AIProxy &
AIInterface.
This design ended up having significant flaws:
- The copying impacts the simulation negatively, particularly because
AIProxy subscribes to a lot of messages (sometimes sent exclusively to
it). This time cannot be threaded, and impacts MP games without AIs.
- Copying the data is increasingly difficult. Modifiers are a headache,
LOS is not implemented. Lots of logic is duplicated.
The intended benefits of the design also failed to realise somewhat:
- The AI was never threaded, and in fact, it is probably better to try
and thread Sim + AI from the renderer than just the AI, at which point
threading the AI specifically brings little benefit.
The new design is much simpler and straighforward, but this has some
side-effects:
- The AI can now change the simulation. This can be used for cheating,
or possibly for a tutorial AI.
- The AI runs in the same GC zone as the simulation, which may lead to
more frequent Sim GCs (but overall we might expect a reduction in
temporary objects).
- The AI state was essentially cached, so replacing some functions with
Engine.QueryInterface might be slower. The tradeoff should be balanced
by lower AIProxy computation times.
Future work:
- Threading some specific AI tasks could still be worthwhile, but should
be done in specific worker threads, allowed to run over several turns if
needed.
Technical note: the AI 'global' is in its own Realm, which means name
collisions with the same are not possible.
Other notes:
- The RL Interface uses the AI Interface and thus will gradually lose
some data there. Given that the RL Interface can now request data
however, this should be dine.
Refs #5962, #2370
Differential Revision: https://code.wildfiregames.com/D3769
This was SVN commit r26274.
Users sometimes ended up with bad (wrong version) XMB files in the user
mod. This resulted in A25 loading a black screen.
There is a combination of unfortunate code paths that lead to this. The
core issue is that:
- cdd75deafb changed the XMB loading code that if there is an error in
Init from a cached XMB, it reports an error. This error happens to be
silent, because the GUI expects CXeromyces to do its own error reporting
(a pretty poor decision, all in all, but whatever). This explained why
the black screen showed no errors.
- The code flow attemps to load an 'archive' XMB first, then only a
loose cache. _But_ if the XMB that fails to load is an archive (which
generally never happens except when using incompatible mods, which is
generally less easy in A25 since we added code to stop that), then the
game will try to recreate the XMB as an 'archived' path, not a 'loose
cache' path as it would usually do.
- Because the 'archived' path already exists in the VFS, the game will
attempt to overwrite that. It so happens that in non-dev copies, this
writes to the user mod.
- Because the user-mod is always loaded, this was unexpected for users.
Fixing this is rather simple: the game should never attempt to write
'archive' XMBs in that function. Added explicit barrier, which shouldn't
matter performance-wise but fixes the issue by writing in the proper
place, and also properly recovering in case of read failure.
I will note that the game will still try to load the archived file, and
recreate it every time, but I don't think that's a particularly big
deal, in general having engine-incompatible mods in the future should be
harder because of A25 changes there.
(NB: users that have used both A24 and A25 should perhaps still be
advised to check their user mod folder, otherwise they'll end up
recreating those files forever).
Reported by: dave_k
Fixes#6320
Differential Revision: https://code.wildfiregames.com/D4275
This was SVN commit r26272.
The UnitManager already lists all units, so we do not need to go through
the visual actor of entities to update them. This is faster and
decouples simulation & graphics code slightly.
Further, the simulation does not need to know about texture changes (see
also 410d2e883a), so remove those calls in Atlas.
Differential Revision: https://code.wildfiregames.com/D4455
This was SVN commit r26270.
6581796103 removed the ability for terrain to affect movement speed. The
JPS pathfinder cannot support it, and the approach was poor anyways,
coupling rendering data with simulation data.
This lets us remove the dependency on CTerrainTextureManager everywhere.
Tested by: langbart
Differential Revision: https://code.wildfiregames.com/D4459
This was SVN commit r26269.
The new values in 158cf8ea8d were too high, units would push each other
too much when building. This lower value should fix that, though further
adjustements may be necessary.
Reported by: Freagarach.
Differential Revision: https://code.wildfiregames.com/D4461
This was SVN commit r26261.
There is no need to have BuildAnimation in CModel when everything is
done in CObjectEntry anyways.
This removes a pointer in every CModel object, which is nice.
Accepted By: vladislavbelov
Differential Revision: https://code.wildfiregames.com/D4454
This was SVN commit r26254.
Moves the work done from cmpResearcher to cmpTechnologyManager.
No functional changes.
It allows fancy stuff in the future (#6364).
Differential revision: https://code.wildfiregames.com/D4438
This was SVN commit r26252.
RENDERDATA_UPDATE_COLOR was used to precompute lightEnv-dependent data
on the CPU. This is no longer done following engine upgrades, and in
particular d7d02a4740 which explictly always did this on the GPU.
ModelAbstract had a 'SetDirtyRec' hack for it because of decals, which
can also be removed. The 'dirty' bit of CRenderableObject is renderdata
for the specific item, never its props, so it never actually needs to be
recursive.
CheckLightEnv is also useless as a result, and removed.
Differential Revision: https://code.wildfiregames.com/D4453
This was SVN commit r26249.
The main change is the introduction of a 'pushing pressure' counter on
units. This counter increases when units get pushed around, and
decreases over time. In essence, units under high pressure move slower &
are harder to push around.
The major effect is that units can now get bogged down when very dense
groups start colliding. This makes movement more realistic, makes unit
movement more 'chokepointy', and generally improves the mathematical
soundness of the system (lower values are easier to handle for our 200ms
turns).
Other changes:
- The logic to detect units crossing each other's path has been
reworked. Units that run towards each other should not more obviously
avoid each other.
- New parameters: 'Spread' is a measure of how strong the pushing effect
is based on distance. With the current settings, static-pushing is
rather 'on/off', whereas moving-pushing is more gradual (and thus the
max influence distance was increased when moving).
- Default values have been tweaked for lower overlap.
- Units only looked at other units within their grid region. This led to
overlap near grid-borders. Units now look at neighboring grid elements,
which largely removes this issue. While this may be slower, the
performance of pushing was largely negligible before, so it is unlikely
to become a main cause of lag (and overlap was generally disliked by
players).
- Units no longer orient in the direction of pushing, but instead keep
facing their target. This can look slightly odd under very heavy pushing
forces, but vastly improves behaviour of very slow units such as rams
(since they spend much less time turning around). As a side-effect,
clean up angle code following acc780bcbb .
Engine changes:
- Add a debug rendering mode at compile-time to help understand what is
happening.
- Make it possible to constexpr initialise fractional fixed numbers by
using FromFraction
The 'pressure' change was inspired by alre's suggestion at
https://wildfiregames.com/forum/topic/56436-for-a-better-unit-movement/#comment-461987
Refs #6127
Differential Revision: https://code.wildfiregames.com/D4439
This was SVN commit r26245.
dropsiteSupplies kept a list of resources and did not remove exhausted
resources, leading to possibly buggy resource-management in the AI code
(and needless computations).
Differential Revision: https://code.wildfiregames.com/D4442
This was SVN commit r26244.
One needs UnitAI to be able to use a formation, so include the spec
therein (to keep information close to where it is used).
Modders can change their templates with the following script:
https://code.wildfiregames.com/P261.
Differential revision: https://code.wildfiregames.com/D4443
Comments by: @Stan
Idea accepted by: @wraitii
Fixes: #6399
This was SVN commit r26235.
The ResourceTrickle component has been changed to a global aura instead.
It increases the trickle slightly, but catafalques are unbalanced
anyway.
Patch by: @Grapjas
Differential revision: https://code.wildfiregames.com/D4383
Refs. #6032 by fixing the Macedonian specific case, but not showing the
tooltips, as requested.
This was SVN commit r26234.
wowgetoffyourcellphone