I agree that it is a little awkward

IMO this is a little awkward. Can we instead define Index as a property on PPos, and likewise a static FromIndex?

The touched cell tracker would potentially be more optimal as a bitfield array of longs, with each member representing 64 cells. This loop could then be made into:

for (var tindex = 0; tindex < maxIndex; ++tindex)
{
    long touchedBits = touched[tindex];
    if (touchedBits == 0)
        continue;

    for (var c = 0; c < 64; ++c)
    {
        if ((touchedBits >> c) & 1 == 0)
            continue;

        var index = (tindex << 5) + c; // Alternatively pack cells 8x8
        ...

But this would require additional logic in setting the touch bits, which may require some of its own optimizations.

Some profiling revealed that Shroud.Tick was a large source of tick time on my system for bigger maps with lots of players. There has been a fairly extensive discussion around optimizing this point in #17383. In short, the Shroud.Tick for each player loops through every cell to check whether or not it has been "touched" this frame.

By replacing the foreach and immediate conversion from PPos to index (which involves dereference and multiplication) with a direct loop on the index, we can make the hottest path of this loop much lighter. In my performance testing with PerfSample, this completely removed Shroud.Tick from the chart, compared to constituting about 10ms prior (in an AI game with 12 players on Europe).

The touched cell tracker would potentially be more optimal as a bitfield array of longs, with each member representing 64 cells. This loop could then be made into:

for (var tindex = 0; tindex < maxIndex; ++tindex)
{
    long touchedBits = touched[tindex];
    if (touchedBits == 0)
        continue;

    for (var c = 0; c < 64; ++c)
    {
        if ((touchedBits >> c) & 1 == 0)
            continue;

        var index = (tindex << 5) + c; // Alternatively pack cells 8x8
        ...

But this would require additional logic in setting the touch bits, which may require some of its own optimizations.

<!-- This is a guideline that shall help you to include all the required information we depend on to investigate and fix game-breaking bugs. Please follow the instructions and replace any placeholders that are written in capital letters. Instructions like this comment will not be visible in your report. -->

System Information

<!-- Information about the operating system, engine version, game mod and package source are mandatory for investigating and fixing crashes. -->

• Operating System: OPERATING SYSTEM
• OpenRA Version: ENGINE VERSION
• OpenRA Mod: GAME MOD
• Source: Official download package OR self-compiled OR third-party package
• For self-compiled or third-party packages: Mono version

Exception log

<!-- Please replace the placeholder below with the content of the exception.log file. The three backticks before and after the placeholder are used for formatting, so don't remove them. If you don't find the log folder consult https://github.com/OpenRA/OpenRA/wiki/FAQ#my-game-just-crashed. -->

PASTE LOG HERE

Replay

<!-- If you have a replay file for the game that crashed, and it crashes again when you play it back, it will be a great help for us to fix the issue. Please compress the replay into a zip file and drag it here to include it in the report. -->

Additional information

<!-- Please tell us below everything that you think is important for us to know about the crash. Specifically, what you were doing in the moment before the crash or ideally steps to reproduce it are very valuable information. -->

The exception strongly suggests that this is either a yaml setup issue or missing sprite file in a third-party mod. Closing as it's very unlikely to be an issue with OpenRA, nor providing any information suggesting otherwise.

dude I think you should push to https://github.com/ABrandau/Shattered-Paradise-SDK

This is the upstream branch which only response for RA/CNC/TS

<!-- This is a guideline that shall help you to include information we need to understand and fix the issue you experienced. Please follow the instructions and replace any placeholders that are written in capital letters. Instructions like this comment will not be visible in your report. -->

<!-- Important: Help us to avoid duplicates and use the search function to find existing reports for your issue. Please do not submit duplicate reports! Try to help others to find your report by using a precise title. -->

Issue Summary

<!-- Please provide a a clear and concise description of what the issue is below. -->

The latest Playtest hangs on launch.

Reproduction

<!-- Please provide information about how the issue can be reproduced below. -->

Launch the OpenRA-playtest-20201213

Expected behavior

<!-- Please explain what you expected to happen below. -->

It should launch

Actual behaviour

It stays on the launch screen indefinitely

System

macOS Big Sur 11.1 iMac Pro 10core 32GB, Vega 64 16GB

…any logs you need?

Ha, perfect, that worked! Thanks so much @anvilvapre and @pchote for helping! I removed the DiscoverNatDevices: True line from ~/Library/Application Support/OpenRA/settings.yaml.

For the record for non-techy people,

1. open TextEdit app
2. Hit CMD+SHIFT+G to open the folder ~/Library/Application Support/OpenRA
3. open settings.yaml
4. remove the line DiscoverNatDevices: True
5. save the file

Ok, thats really helpful: that shows that the game is waiting for the UPnP discovery to return, which apparently is never happening. UPnP is disabled by default because it is unstable, and is known to cause problems exacty like this. I guess that you were able to run previous versions of OpenRA, and at some point turned it on in the Advanced settings?

If you open ~/Library/Application Support/OpenRA/settings.yaml with a text editor and change the DiscoverNatDevices: True line to DiscoverNatDevices: False (or just delete the line, or the entire file) it should solve the problem.

Is Visual Studio for Mac the recommended way of developing/debugging it?

ah, thanks for the info. I originally downloaded it from the website though.

Now I just cloned the repo (bleed branch) and ran it from Visual Studio for Mac (with dotnet I guess). Fyi, this is where it seems to be hanging

Playtest 20201213 requires mono, the switch to .NET 5 happened after it was branched. Was your opening report also built from source, or running the download from the website?

I just figured out it may be using dotnet rather than mono. I cloned the repo and ran it with dotnet 5, then killed the stuck dotnet process. The crash report looks a bit like there may be a recursion, but not sure how to interpret it:

dotnet_2021-01-18-103316_Hanness-iMac-Pro.log

In the logs folder, the only updated log files after running are these:

perf.log nat.log

@anvilvapre I'll look, but keep in mind, the same environment doesn't throw this error for the current release

<!-- This is a guideline that shall help you to include all the required information we depend on to investigate and fix game-breaking bugs. Please follow the instructions and replace any placeholders that are written in capital letters. Instructions like this comment will not be visible in your report. -->

System Information

<!-- Information about the operating system, engine version, game mod and package source are mandatory for investigating and fixing crashes. -->

• Operating System: OPERATING SYSTEM
• OpenRA Version: ENGINE VERSION
• OpenRA Mod: GAME MOD
• Source: Official download package OR self-compiled OR third-party package
• For self-compiled or third-party packages: Mono version

Exception log

<!-- Please replace the placeholder below with the content of the exception.log file. The three backticks before and after the placeholder are used for formatting, so don't remove them. If you don't find the log folder consult https://github.com/OpenRA/OpenRA/wiki/FAQ#my-game-just-crashed. -->

PASTE LOG HERE

Replay

<!-- If you have a replay file for the game that crashed, and it crashes again when you play it back, it will be a great help for us to fix the issue. Please compress the replay into a zip file and drag it here to include it in the report. -->

Additional information

<!-- Please tell us below everything that you think is important for us to know about the crash. Specifically, what you were doing in the moment before the crash or ideally steps to reproduce it are very valuable information. -->

The newst commit for Pathfinder folder:

Changelog

https://github.com/OpenRA/OpenRA/commit/47bfa8bce8e2e7d166be7c351a8bc38a5b054621

Fixes #18935.

The underlying problem here is caused by inconsistent target validation logic in AutoTarget versus AttackFrontal's Attack activity: AutoTarget considers a target valid if any weapon is in range, but Attack only considers it valid if all valid weapons are in range. Attempting to fix that might open a can of worms, and isn't needed for #18935, so I defer that to #19062.

For the upcoming release, it is sufficient to apply TargetType restrictions to the two weapons. This makes the Sarkarkaur attacks a lot more consistent with the original game (but not exact: they will not fire on infantry using the HMG at 2.5-3.5 cell range) and avoids the underlying bug by ensuring that only one weapon is ever valid against a target.

In Dune 2000, I found that Sardaukars do "Attack Move" in strange way. When enemy unit is situated forward, then Sardaukars can stay.

https://forum.openra.net/viewtopic.php?f=82&t=21333&p=312565#p312565

Reported by: Adrian

Potentially a regression from #18549.

LGTM aside from the issue @matjaeck raised above. I agree it makes sense to take the whole thing for prep, so added to milestone and tweaked assignments/closes.

No, you're right. This is redundant, and defenses do use SellSounds: BUILD1.WAV (which is inherited from ^Building).

Fixes #19055.

The first commit implements the nerf suggested by the competitive community. The second and third commits sync the firing animation to the attacks and fixes the jumping animation frames.

I dialed back on my original plans to remove the second Colt armament (which causes the attack sound to be extra loud) and to stagger the burst shots to make tanya feel less robotic. These would have been nice polish, but at this point I just want to get a stable release out without risking blowback or delays over balance implications.

It is and I don't want to be annoying... but can't Sellable not be removed from ^Defense (as it is inheriting ^Building)? Not that it made any difference...

Or take both, it is a really trivial change.

You can cherry pick that into prep.

visc_lrg is a actor belonging to creep that spawned by "SpawnActorOnDeath"