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.

[Julian Dreykorn]

Hi, I agree with you, I'm also very happy when I hear that people use
Braille. I'm working for a company in the accessibility area, so we do
have contact with many blind people from different backgrounds, and for
me it's kind of shocking that at this time about 15% of blind people can
read Braille, the rest doesn't.

One thing foremost: Do not say it's impossible, simply put: Technically
everything's possible, or as our trainer at the beginning of the
aprenticeship always emphasized: You're god over the computer, do what
you want. Everything you named sounds like good ideas. So if I would
think this in the smallest possible iterations, first step could be a
shortcut, that shows a readonly text control with every message reported
so far, making it posible to scroll with arrow keys as you wrote. And
that's not at all hard to do: Even if you can't do it from Pygame
window, nothing keeps us from just creating a second one and focusing
that, user can read whatever they want, and press esc or alt+f4 to get
back to main. Yes I wrote that I don't know if Pygame could be used or
subclassed for that, but if it can't then we don't use it and create
another window. So far so good, and then we can extend that further and
further, with more text boxes like the map, and then even menus, like
e.g. a tree, or a table, making it possible to select each square via
native menu. That could go from a single descriptive textbox, possibly
until the point where we decide to hide the pygame window itself as
everything's now done using WX. You see, nowhere imposible, more the
question if and what we want to go for exactly.

Maybe we'd track that in a GitHub issue? Emails can get lost quickly,
but there it could be saved until someone of us decides to pick it up,
or another contributor shows up. What do you think?

Best, Julian

[修君]

ok, I'll try my best to give it a shot and see if it can be implemented.

[Julian Dreykorn]

Awesome, if you want I can also try to help, but not this month as I'll be having several exams and a project report to write. Also, I have some plans to work on the multiplayer gameplay, regarding server stability and garbage collection - yes, canceled games are not cleaned and therefore I already had games shown to be running for days on my server.

--
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/c043da25-62e3-4032-b1b0-009e9966536an%40googlegroups.com.

[修君]

I tried changing the game to use a wxPython interface, but the results were not particularly ideal.
A lot of content gets interrupted by window controls during screen reader output, such as campaign story text and mission objectives. The screen reader announces the window controls, interrupting important information.

[Gabriele Battaglia]

Hi Julian,

Thank you for your reply, I read it with great pleasure and I apologize
for the delay in getting back to you.

I know that in computer science—and in many areas of life—almost
everything is possible, even when it seems highly improbable. However, I
am afraid this is one of those cases where two software architectures
simply fight each other and refuse to cooperate.

The main issue is focus control. When Pygame has the focus, it takes
full control of the screen, preventing NVDA from interacting with it the
way it does with native Windows controls. If we push Pygame to the
background and give the focus to wxPython, Pygame stops catching
keyboard events, which basically breaks the gameplay loop. Switching
back and forth using Alt+Tab or another shortcut would completely defeat
the purpose: we are aiming for fluid, real-time feedback, not a more
complicated process.

Perhaps—and I stress "perhaps"—one alternative could be shifting input
control to a gamepad. Otherwise, the only truly viable path would be to
ditch Pygame altogether, build a dedicated audio engine from scratch,
and port everything to wxPython. But a refactoring of that scale would
be a massive, monumental task—one that I do not know how to implement
and that I would never ask anyone to shoulder.

Please also extend my thanks to Shaun for taking the time to evaluate
this idea. I apologize if I caused any distraction from the main
development line.

Best,

Gabry

[Julian Dreykorn]

Hi,

thank you for that. Indeed, this leads us to the point where we are now,
I agree on you both that in this case, it wouldn't make sense to go this
way further. Anyway, thank you for trying that.

[Gabriele Battaglia]

Il 24/07/2026 21:51, blind vador ha scritto:
> Hy to all.
>
>
> Am prety sorry catching the messages in the airs and haven't see the
> all conversation.
>
>
> Just to lets you know that in my side am actually working on a new
> audiogame engine which is geting larger and largger each days.

Ciao.

Super interesting, dude!

Tell us some more...

Which language do you use?

Will be this engine freely usable? Or no plan yet in that sense?

Would you mind to query it via API

Does it create sound on its own or does it need to use kind of library
provided by the users?

Could you give us some mp3 examples recorded during your developments?

Gabe.