soundrts-1.4.5.2

[修君]

Removed the Civilization V-related gameplay features from the previous update. This update instead focuses on significantly improving game performance, fixing various bugs, and making general improvements. Details are listed below.

1.4.5.2
--------

**Improvement: multi-dimensional auto menace and optional rules overrides**

- Default ``menace`` is no longer raw damage: it scores damage, hit cover, cooldown, wind-up (``*_ready``), HP, armor, dodge, range, and speed for auto-targeting and square threat sums.
- Optional unit fields: ``menace`` / ``menace_vs`` (absolute fixed), ``menace_mult`` / ``menace_mult_vs`` (multiply the auto multi-dim base; still scales with upgrades).
- Tunable in ``def parameters``: ``menace_armor_weight``, ``menace_dodge_weight``, ``menace_range_weight``, ``menace_speed_weight``, ``menace_hp_ref``.
- **Code**: ``worldunit/world_attributes.py``, ``combat/targeting.py``, ``definitions.py``; ``res/rules.txt`` parameters; ``res/ui/rules_doc.txt``.
- **Docs**: ``mod/modding.rst``, ``mod/aimaking.rst``.
- **Tests**: ``test_rules_menace_targeting.py``, ``test_ai_counter_targeting.py``.

**Improvement: continuous cross-square chase (true pursuit)**

- **Before**: In chase mode, when an enemy left the square the AI issued automatic ``go`` orders to hop into adjacent squares and then attack again — still order-driven, and units could stay “attacking” without leaving the square.
- **Now**: ``chase`` keeps a single ``AttackAction`` on the locked enemy and paths through exits across squares; no automatic ``go`` spam.
- **Hold**: Spawn ``position_to_hold`` still blocks leaving the hold area for offensive / guard. Defensive / chase are exempt (chase clears hold when crossing squares). Normal ``go`` / ``attack`` still call ``stop()`` first and clear hold.
- **Code**: ``worldaction.py`` (``AttackAction._chase_toward``), ``worldunit/world_ai_decision.py``, ``worldunit/world_movement.py`` (``_must_hold``).
- **Docs**: ``player/unit-default-behavior.rst``.
- **Tests**: ``test_chase_continuous_pursuit.py``.

**Improvement: attributes screen shows live terrain-adjusted stats**

- Alt+V shows unit ``mdg_on_terrain`` / ``rdg_on_terrain`` / ``mdg_cd_on_terrain`` / ``rdg_cd_on_terrain`` and charge terrain modifiers.
- Current-square terrain ``mdg_vs`` / ``rdg_vs`` / etc. plus ``*_on_terrain`` feed the damage, cooldown, and speed readings on the attributes screen (terrain ``*_vs`` = decimal percent, e.g. ``.25`` = +25%%; unit ``speed_on_terrain`` remains absolute speed).
- **Code**: ``attributes/terrain_effective.py``, ``attributes/combat_attributes.py``, ``attributes/basic_attributes.py``, ``attributes/bonus_handler.py``.
- **Tests**: ``test_terrain_attributes_ui.py``, ``test_terrain_effective_attributes.py``.

**Fix: Tab no longer finds exits on never-scouted squares**

- **Symptom**: On squares never visited (static fog, no scout record), Tab cycling could still announce far-side exits / paths.
- **Cause**: Fog logic remembered opposite-side exits before the square was actually entered.
- **Fix**: If a square is in neither ``scouted_squares`` nor ``scouted_before_squares``, visibility / place summary stay blank; visited-then-left static fog still allows Tab.
- **Code**: ``clientgame/game_unit_control.py``.
- **Tests**: ``test_unknown_square_tab_blank.py``.

**Fix: ``order_impossible`` beep after Backspace-killing a hunt animal**

- **Symptom**: After a default attack killed a huntable animal, ``order_impossible`` played.
- **Cause**: ``AttackOrder`` treated a vanished target as failure.
- **Fix**: Mark the order complete when the target is gone or ``hp <= 0``.
- **Code**: ``worldorders/movement.py``.
- **Tests**: ``test_hunting.py`` (``test_attack_order_completes_when_huntable_target_gone``).

**Fix: neutral default order and hunt damage**

- Plain / default ``go`` on neutrals (non-imperative) only moves — no AttackAction with zero damage.
- Plain ``attack`` on ``is_huntable`` animals (including Backspace default hunt) deals damage; only imperative attack lets AI treat neutrals as auto-engage targets.
- **Code**: ``worldunit/world_ai_decision.py``, ``worldunit/worldcreature.py``.
- **Docs**: ``player/hunting.rst``, ``player/unit-default-behavior.rst``.
- **Tests**: ``test_neutral_no_auto_attack.py``, ``test_neutral_go_and_hunt_attack.py``.

**Fix: Computer player perception update crash (missing ``_buckets``)**

- **Symptom**: Mid-game (especially with ``computer_only`` map AI, allied AI teammates, or after loading a save) could crash in the main-loop perception stage with ``AttributeError: 'Computer' object has no attribute '_buckets'``.
- **Cause**: The player spatial-grid index ``_buckets`` was initialized only in the wrapper ``Player.__init__``; save/load strips that cache field; allied-vision bulk visibility checks (``bulk_visibility_check``) call allies' ``_potential_neighbors``, which raised if a ``Computer`` did not yet hold ``_buckets``.
- **Fix**: Pre-initialize ``_buckets`` in ``BasePlayer.__init__`` with the other perception caches; ``_potential_neighbors`` falls back to an empty dict when missing; ``update_alliance`` clears the ``allied_vision`` instance cache so alliance changes do not keep stale ally lists.
- **Code**: ``worldplayerbase/base.py``, ``worldplayerbase/perception.py``, ``worldplayerbase/__init__.py``.
- **Tests**: ``test_meteors_computer_only.py``, ``test_phase3_parity.py``, ``test_neutral_passive_creep.py``.

Julian Dreykorn’s latest commit has been merged into the codebase. Thank you very much.

code:

https://github.com/tuohai/soundrts-ultimate-version

game:

https://github.com/tuohai/soundrts-ultimate-version/releases/tag/1.4.5.2

[Julian Dreykorn]

Sorry, but there's a misunderstanding: Since I changed the workflow file via PR, it needs a separate approval and is still unable to merge - in fact I also wasn't aware of that pithole either. To merge it, you'll need to go to the PR

https://github.com/tuohai/soundrts-ultimate-version/pull/1

then approve the workflow, then merge and close the PR, That's how it's documented. That's likely why the PR isn't yet merged and still shows 5 commits waiting. Quickly looking at the workflow runs, for me it seems like you can also approve from here, and when it ran merge - but in any case approve the workflow and merging the PR are two different stept:

https://github.com/tuohai/soundrts-ultimate-version/actions/runs/29323573322

https://github.com/tuohai/soundrts-ultimate-version/releases/tag/1.4.5.2 --
You received this message because you are subscribed to the Google Groups "soundRTSChat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to soundrtschat...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/soundrtschat/d1cca6d9-d930-47bf-8993-de9912ee856fn%40googlegroups.com.

[修君]

Okay, I’ve completed it. Please check it.

[Julian Dreykorn]

Thank you, that was it. Now it got merged.

To view this discussion visit https://groups.google.com/d/msgid/soundrtschat/3b567320-9dad-44fc-9f2e-06282c20c1fan%40googlegroups.com.

[Gabriele Battaglia]

Hello guys.


There is an idea around my mind since a couple of weeks. I know that it
envolves lots of work.

Just to express my thought...

I don't know which kind of library are you use for SoundRTS GUI but I
have no feedback from NVDA a part from the game's audio effect.


What about to adding the power of NVDA to it? Beyond its audio, that
remains the core feature, we may have NVDA and Braille which I use a lot.

To reach this goal we must give it a GUI made with wxPython.

I use it with great success in my important project as Tornello,
Terminal_beast, Dadillo... You may see at github too.

An issue we may encounter could be the accelerators from keyboard but
every issue can be fixed in a way or another.

What do you think DEVs?

Gabe.

[Julian Dreykorn]

Hello Gabe,

basically I'm also a fan of wxPython, as native components always have
the best accessibility by design as I'd say. So I'm also using it right
now for the calculator software I'm creating, which when finished will
also have things like a searchable index or exporting to tactile plots.
However, could you maybe say where exactly this would help here in
SoundRTS? I also use Braille, and e.g. when in the office or university
alone without any speech at all, but for SoundRTS I have speech history
on. For that I use the Braille Essentials (in the past Braille Extender)
addon, press space+H to toggle it, and so get all messages that are
spoken onto the display, and can scroll up when I missed something. For
this game, Pygame is used centrally - if or how this could possibly be
subclassed by wx would need to be explored. Is speech history maybe
already solving the problem? If not, maybe you can tell more exact where
it would help.

Best, Julian

[Gabriele Battaglia]

Hello Julian,

Thank you for your reply, I read it with great interest.

I'm really glad to hear that you use Braille too. I often get the
feeling that there are very few Braille display users out there, and
that the vast majority of software developers completely overlook it.

My idea was to have windows with large |TextCtrl| areas where the game's
narration would be printed, allowing the user to scroll through it using
the arrow keys, just like in a read-only text box. Under our fingers,
line by line, we could have descriptions of the game objects with their
main parameters: soldier health, enemy characteristics, and hit points
decreasing in real-time during combat. We could also have text-based
maps of the territory drawn with ASCII characters, along with lists of
options and actions to choose from.

However, I believe all of this becomes impossible when using Pygame.
I've tried it myself and, despite its immense potential, especially in
audio management, I have always discarded it. When initialized, Pygame
renders the screen by activating a sort of graphical mode that NVDA sees
as a completely empty object; it reads the title and nothing else.
Consequently, there is no textual output unless you explicitly send it
to the speech engine via accessible APIs, and the same goes for Braille.
But that is not what I want. Those messages feel "fake", if you know
what I mean. It is not the same as navigating a real screen and
monitoring a text area that updates in real-time. Simply put, it's not
what I'm looking for.

So, there is nothing we can do: my idea is fundamentally incompatible
with Pygame.

Thank you anyway for taking the time to reply and discuss this with me.

Best,

Gabry.