## Description:
This PR fixes a critical race condition bug where players could
unintentionally receive the traitor debuff when alliance requests were
accepted mid-attack.
Critical Bug Fixes#1866
**Root Cause:**
Players could bypass UI alliance checks ( isFriendly() ) by accepting
alliances and immediately attacking after that, causing the server to
treat the attack as betrayal
Solution: Added server-side alliance validation in
AttackExecution.init()
This ensures attacks on allies are blocked at the server level.
- Once Bots and Nations decide to attack, they breaks the alliance. I
added maybeConsiderBetrayal(), which currently always returns true. I’ll
add proper logic for alliance-breaking soon on another PR; this didn’t
exist in the code before.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
## Please put your Discord username so you can be contacted if a bug or
regression is found:
abodcraft1
---------
Co-authored-by: evanpelle <evanpelle@gmail.com>
## Description:
**--Fix oversight in v24--**
In v24, alliance renewal was introduced. But a Bot or Nation never
answers to it. So the Event Panel expiration message + clicking to Renew
and waiting, is all in vain if the other player is not a human. Like in
Single player in all cases. The message after ~30 seconds is always
"Alliance with xxx expired". This feels illogical and there's no purpose
for showing a Request to Renew button if it then always expires.
Also reported by players like here:
https://discord.com/channels/1284581928254701718/1284581928833388619/1398249123093676094
This PR fixes it by having the non-human reciever of the request, say
yes to depending on attiude towards the human and chance. This feels
more realistic.
The requestor is always the human player because they click a button in
EventsDisplay. So there is always already an extension request which the
bot can react to with another extension request to have the alliance be
extended.
**--Add tests--**
It adds tests for extending alliance between human and non-human player.
One for AllianceExtensionExecution simply testing if alliance between
human and non-human can be extended. And one in BotBehavior, testing if
it correctly handles an extension request by adding a new
AllianceExtensionExecution.
**--Fix silent bug in existing test--**
Adding the new test for human and non-human for
AllianceExtensionExecution, i ran into a bug in the existing test for
extending alliance between humans. Which made the test always pass
because expirationAt wasn't fetched correctly. Had to fix that too,
without intending that for this PR beforehand. And then had to include
the bugfix from PR #1582 (v25) in it too to have the alliance actually
extended. More details below:
(-- The existing test would always return 'all passed' because it did
not get the expiresAt() but got the createdAt +
config.AllianceDuration() for both expirationBefore and expirationAfter.
createdAt is immutable so before and after would be the same. And then
it did not test for toBeGreaterThan, which would have failed. But it
tested wrongfully for toBeGreaterThanOrEqual which was a pass even when
the expirationBefore and expirationAfter would be the same and no
extension had taken place.
-- The bugfix from PR 1582 needed to be included now too. Because only
with those changes, the existing test has its alliance truly extended
and only with that the expirationAt actually changed. Actually, checking
if extend() was called isn't needed anymore, since we now check the
expirationAt correctly which on its own tells us if extend() was
succesful. But left this addition from PR 1582 in since it can't do any
harm.)
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [ ] I have read and accepted the CLA agreement (only required once).
## Please put your Discord username so you can be contacted if a bug or
regression is found:
tryout33
---------
Co-authored-by: evanpelle <openfrontio@gmail.com>
Co-authored-by: Drills Kibo <59177241+drillskibo@users.noreply.github.com>
## Description:
The troop/worker ratio bar is almost never changed. so remove it and the
entire concept of workers. Now there is just troops.
Now players get a consistent 1k/s gold.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I have read and accepted the CLA agreement (only required once).
## Please put your Discord username so you can be contacted if a bug or
regression is found:
evan
## Description:
- Create a new expand ratio that allows AI players to expand with a much
lower reserve ratio than the normal attack reserve ratio.
- Unify the implementation of the first attack between bots and nations.
- Bugfix: Multiple attacks per tick could cause nations to full-send.
- Improve the chance of finding a place to boat to by allowing nations
to target non-shore land tiles.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Description:
- Use `<argument> is <type>` return type declarations in favor of `as`.
- Use `satisfies` instead of `as`.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
---------
Co-authored-by: Scott Anderson <662325+scottanderson@users.noreply.github.com>
## Description:
Some optimizations for bot & fakehuman execution. Better performance
measured using profiling, at the start of a game or in singple player,
but since the circumstances differ it is not a very reliable comparison.
--- In BotExecution:
Added getNeighborTraitorToAttack in Botbehavior to use in maybeAttack.
No caching for playerNeighbors array, because although it could be
re-used up to two times in selectRandomEnemy, maybeAttack runs every
tick and selectEnemy only every 10 seconds so the cache overhead would
not be worth it.
--- In Botbehavior:
Put repeated code in dedicated functions for readability, maintainance
ease, and reduce the chances of forgetting to update the timestamp for
enemyUpdated. Can be seen as a follow-up to PRs #434 and #946.
-- In both selectEnemy and selectRandomEnemy:
Put the first if this.enemy === null statement parenthesis, around the
two checks below. Because if there's already an enemy (if forgetEnemies
hasn't nullified it, enemy === null is false at the first if statement),
then enemy === null will still be false for the two checks below the
first. No need to check it thrice then. Once inside the first if
statement (when enemy === null is true), then we need to check it two
times more in case the code inside already set an enemy.
-- In selectEnemy under 'Prefer neighboring bots':
Removed unneccessary check for enemy === null.
Replaced sort with more performant for loop.
-- In selectRandomEnemy:
Under 'Select a traitor as an enemy', if a traitor is a friendly player,
they got less odds to be chosen as enemy over an unfriendly player, but
they weren't ruled out. While below in the Sanity Check, we specifically
rule out friendly players as enemy and set enemy=null. So excluded
friendly players under 'Select a traitor as an enemy' instead of only
giving them lower odds.
Use the new shared method getNeighborTraitorToAttack.
-- In checkIncomingAttacks, since we're only interested in the max
value, replaced sort with loop that makes a single pass through the
attacks to find the largest one.
-- For shouldAcceptAllianceRequest, #1049 added tests and improved
readability of Alliance requests.
It may have also deoptimized it a bit. Const notTooManyAlliances would,
in the past, not be computed if requestorIsMuchLarger was already found
to be true. Since the readability changes, tooManyAlliances was always
computed regardless of the value of requestorIsMuchLarger.
This PR attempts to address this too, while still keeping it as readable
hopefully.
Also choose for early returns to optimize a bit more. So if isTraitor is
true, don't compute any further and just return false immediately etc.
Switched the order of testing for noMalice and isTraitor. Traitor status
used to be throughout the game, now it's only 30 seconds or will be
maybe 45 seconds to 1 minute. So the chances of someone asking for
alliance and being a traitor at the same time have decreased. isMalice
chances could be bigger.
Removed the named constants and choose to put them in comments, so
readability should be about the same as #1049 intended. Kept the braces
for the if statements because otherwise Prettier would misalign the
comments.)
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
tryout33
## Description:
Answering issue: #1017
[Cleanup] Pass Player into the execution constructor instead of PlayerID
I have tested the changes running and playing a full game. I do not know
other way to test the changes, please inform me ❤️
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
Lele
---------
Co-authored-by: lva <lva@rovsing.dk>
## Description:
The method deciding whether bots should accept an alliance used to use
multiple variables with negated names (notTraitor, notMalice,
notTooManyAlliances). For readability, I have negated their value in
order to given them a positive name (isTraitor, hasMalice,
tooManyAlliances).
I have also added tests for the alliances acceptation/rejection behavior
of bots.
- [x] I have added screenshots for all UI updates
- [X] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [X] I have added relevant tests to the test directory
- [X] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [X] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
Discord: nephty
## Description:
Simplify bots retaliation logic. Do not counter-attack before reaching
the trigger ratio.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
Co-authored-by: Scott Anderson <662325+scottanderson@users.noreply.github.com>
## Description:
Improve type safety and runtime correctness by:
1. Enabling TypeScript's
[strictNullChecks](https://www.typescriptlang.org/tsconfig/#strictNullChecks)
compiler option.
2. Replacing all loose equality operators (`==` and `!=`) with strict
equality operators (`===` and `!==`).
3. Cleaning up of type declarations, null handling logic, and equality
expressions throughout the project.
Currently, the code allows implicit assumptions that `null` and
`undefined` are interchangeable, and relies on type-coercing equality
checks that can introduce subtle bugs. These practices make it difficult
to reason about when values may be absent and hinder the effectiveness
of static analysis.
Migrating to strict null checks and enforcing strict equality
comparisons will clarify intent, reduce bugs, and make the codebase
safer and easier to maintain.
Fixes#466
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
---------
Co-authored-by: Scott Anderson <662325+scottanderson@users.noreply.github.com>
Co-authored-by: evanpelle <openfrontio@gmail.com>
## Description:
For the first attack, just send 1/5 troops and don't wait until the bot
has sufficient reserves.
It looked weird because none of the bots moved at all for the first 5
seconds of the game.
## Please complete the following:
- [ ] I have added screenshots for all UI updates
- [ ] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [ ] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
<DISCORD USERNAME>
Co-authored-by: evan <openfrontio@gmail.com>
## Description:
This should fix the exploit that allows players to send custom text as
an "emoji". It does this by introducing a emoji ID (index into the emoji
table) instead of sending the raw emoji as a string.
## Please complete the following:
- [ ] I have added screenshots for all UI updates
- [X] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [X] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
PilkeySEK
## Description:
Refactor AI troop management and strategic behavior based around two key
values: a trigger ratio and a reserve ratio.
- Reserve ratio: This determines the portion of the population the AI
will keep in reserve and will not send on attacks.
- Trigger ratio: This is the threshold at which the bot will initiate an
attack.
Additionally, when an incoming attack is detected, bots will now
prioritize retaliating by switching targets to the largest incoming
attacker.
Fixes#470
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
fake.neo
---------
Co-authored-by: Scott Anderson <662325+scottanderson@users.noreply.github.com>
This is the first move in the effort to combine the redundant logic that
exists between BotExecution and FakeHumonExecution.
This commit:
1. Combines the alliance request handler, moving bots to use the same
logic as nations for acceptance.
2. Combines the sendAttack() functions, which may later be reworked.
3. Introduces selectEnemy() function to wrap enemy selection logic that
nations use.
4. Blocks nations from nuking bots.
5. Alters enemy selection to prefer neighboring bots if there are any.
## Description:
Fixes#467
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
fake.neo
---------
Co-authored-by: Scott Anderson <662325+scottanderson@users.noreply.github.com>
Abdallah Bahrawi