Fixing issues #282 where players can bypass max username length by
editing their storage. I added a sanitization on the server side to
avoid all kind of cheat on the username as we can't trust clients
Previous patch modified largeModifier to increase it. It boosted
attacker loss but also increased speed a lot (not intentional). We now
declare two different modifier for speed and for attacker loss. Attacker
loss should remain the same.
Speed was brought as before (to slow down a bit huge players). Except
instead of sqrt (exponent 1/2) we do exponent 0.6. So the speed modifier
decreases a bit faster with size (to disadvantage a bit huge players who
are invincible right now)
Co-authored-by: ilan schemoul <ilanschemoul@gmail.com>
Does what the title says. I made sure there were no duplicate entries.
Tested by launching the dev build and confirming the flags are all
present.
While all have present items, a couple (Alaska and West Virginia) do
fail to render. I think this is because the .svg files are too large.
Selecting these flags does not cause any issues upon entering the game,
they're just invisible.
In any event I am working with N0ur on some more flag updates that will
be forthcoming in the next few days, will address these couple then.
Added functions to TerrainMapGenerator to create a bitmap from the
Minimap Terrain array with the colors being identical to those rendered
in game, with the additional change of setting the Alpha of all water to
0.
Calls added to generateTerrainMaps to actually generate the thumbnail
PNGs,
Revision to src\client\utilities\maps.ts to reflect that the images
pulled into the UI should be those ending in 'Thumb.png,'
I've tested by launching the game and starting a few matches.
hile I'd hoped that using the minimaps as the basis for the thumbnails
would speed things up I think the actual bottleneck is the writing to
the file system.
Below is a screenshot showing these thumbnails in the UI.
Finally I will say that while the code additions work, given my novice
status with typescript and asynch calls these changes may benefit more
from review and a little critical feedback before they're ready to
merge.
More costly (start at 1.5M), increase cost cap (4.5M), biggest timeout
(5s->10s), much lower chance to stop hydrogen (70%->10%), triple
construction time (10s->30s) otherwise it's trivial to build a SAM right
before a nuke hits
Slightly decrease flat land advantage (in certain cases it feels almost
instataneous otherwise)
To calculate speed bonus use 4*attackTroops instead of 5 (people keep
complaining than small numbers of troops take crazy amount of lands
veryn quick)
Slightly increase minimum multiplier for attacker loss, to make
snowballing a little bit slower.
I only slightly modified numbers because the meta is fun it's just too
quick on certain cases.
We previously had a system where lobbyLifetime = gameCreationRate * 2
It was to always have one lobby ready.
With dynamic timer (start if enough player or timer's over) we cannot
rely on this system (which used setInterval) so we have one lobby and
check every 100ms if we need to create another lobby.
Might add 100ms+time of creating a lobby ms latency. Which is fine I
guess.
Evan