^

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Slightly less crap version.

Successful build - Chance fights ever on the side of the prudent.

Happy this is not committed yet: there was a segfault due to faulty initialisation. It could be triggerd by pressing the structree hotkey repeatedly. Also the chat hotkeys appeared broken.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Treat new global hotkey and fix naming issue

Successful build - Chance fights ever on the side of the prudent.

Try to please bots

Build failure - The Moirai have given mortals hearts that can endure.

Successful build - Chance fights ever on the side of the prudent.

Build failure - The Moirai have given mortals hearts that can endure.

In D1398#115770, @wraitii wrote:

I am not a huge fan of "Press". Maybe "DownOnce" would be more explicit. But TBH this seems like a rather minor thing, and I would be OK with committing "Press".

Well DownOnce doesn't really work either, since it is also fired when we press longer. Note that renaming this needs more changes than is scoped in this patch, since one needs to consider mousebuttons and other events too, they trigger press too.

Fix comments

Without patch

error(foo) prints a message, but thats not a JS exception, one can raise one using throw new Error("foo").
The serialization test error is unrelated and should be reported in a specific ticket, excluded from here.

Successful build - Chance fights ever on the side of the prudent.

Make the preprocessor change minimal.

Without the patch (Test failure not related) @(rP23677)

When having more than 1000 FPS, the menu panel is not animated anymore (millisecond delta = 0), reported by OptimusShepard on
http://irclogs.wildfiregames.com/2020-05/2020-05-03-QuakeNet-%230ad-dev.log

I hereby review this patch based on the grounds that it is a defect I introduced in the feature of rP23455.

In D2747#116000, @user1 wrote:

I do not want to break all current passwords unless we have a plan in place to address that.

I do not want to break all current passwords unless we have a plan in place to address that.

Successful build - Chance fights ever on the side of the prudent.

Looks good given the current constraints for the password generation logic. 👍

Successful build - Chance fights ever on the side of the prudent.

• Move range check to cmpResourceGatherer.
• Change test.
• Remove most logic from UnitAI-timer.

Successful build - Chance fights ever on the side of the prudent.

Successful build - Chance fights ever on the side of the prudent.

Fix notes

(Black-box testing passes.)

Successful build - Chance fights ever on the side of the prudent.

cc @user1 @Dunedan

Also _> Remember to check why we salt with the username and not the password, that seems wrong at a glance but I'm no expert.

It "breaks" hunting.

WARNING: JavaScript warning: simulation/components/UnitAI.js line 2022 reference to undefined property this.order.data.attackType

Thanks for debugging this and thanks for the patch.

I'm wondering if it isn't confusing to have folders named after sizes.

The reason for that change is maintainability: having dozens of folders with only four images each is less practical than just four folders with dozens of images each.

Other than that it's quite a significant breaking change for mods... As in it breaks every single one of them. If I commit this I will be the one to blame hence the previous question.
Is there any way we can create something to update them?

Only mods that include some template_unit_* files would break; Terra Magna etc. don't and should be fine.

Also it seems it doesn't apply correctly
Can you check?

I just ran arc patch D2503:

OKAY  Successfully applied patch to the working copy.

No errors or warnings. I have no idea why Vulcan complains; I don't understand phabricator, though.

I'm wondering if it isn't confusing to have folders named after sizes. Other than that it's quite a significant breaking change for mods... As in it breaks every single one of them. If I commit this I will be the one to blame hence the previous question.

cc @Itms

Indeed this interests me :)
I do have a hunch that we're not going beyond 32 players, as there must be a performance impact for using any data structure. Perhaps 128 bits primitives will become possible someday.
That being said, with 30 players the engine is already going to lag like a madman, so I don't really see this as a problem.
I'm adding this to my list, though I do have plenty of things I want to look at first (mainly release blockers).

I'd add a duration as well. It would be annoying to have to repair a building for the whole game just because one javelineer got to throw at it.

Adding wraitii as it might interest him.