- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
Yesterday
Did you check the images by the way
@phosit this diff has all the P values removed so that the only change is the roughSort function. It is basically the same for me compared to the patch as written and vanilla. If it is a lot better for you maybe we have a lead.
Alternatively, you could also just revert the line that calls compareLengthRough() (L272 in CCmpRangeManager.cpp) and see if performance is still bad.
How’s this?
In D5282#226907, @phosit wrote:No, sorry it's worse with the patch
Ok, I profiled with AI (just my opponent was AI) and the improvement was less substantial (about 1/3 the improvement for me at least)
Yes. There needs to be a linebreak character at the end of the last line.
No, sorry it's worse with the patch
In D5282#226873, @phosit wrote:
Build failure - The Moirai have given mortals hearts that can endure.
Successful build - Chance fights ever on the side of the prudent.
Finds remaining instances of this in the techs
Just re update the diff and instead of the no newline at the end of file just press return?
Yep. Just make sure to add a newline to the end of all the files.
This should do it I think??
I was wondering about that, this might allow me to commandeer this.
You first need at the bottom to add action 'commandeer patch'
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
In D5313#226790, @Stan wrote:
Adds component change
Thanks @Stan
@ShadowOfHassen you have the necessary permissions. Just click the "Update Diff" button in the top right of the page.
I'll see if I can help with D1730 as well. Maybe we can finish both now.
Build failure - The Moirai have given mortals hearts that can endure.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
I think the comparison is somehow wrong now: The AI always attacks units at the "North"
Successful build - Chance fights ever on the side of the prudent.
Back to the original diff again.
Successful build - Chance fights ever on the side of the prudent.
Removed changes to LOGMESSAGERENDER.
In D5314#226863, @Itms wrote:LOGMESSAGERENDER is, contrary to LOGMESSAGE, supposed to be displayed to the user, not only in the logs. So it would probably make sense to keep translating them.
LOGMESSAGERENDER is, contrary to LOGMESSAGE, supposed to be displayed to the user, not only in the logs. So it would probably make sense to keep translating them.
Successful build - Chance fights ever on the side of the prudent.
In D5313#226823, @wowgetoffyourcellphone wrote:Is this an oversight or intentional? Looks like an oversight.
Suggested changes:
Thu, Jul 25
@Vantha @ShadowHassen you might help here by taking over the patch :)
It still good to offer the option of those strings to be translated, and the more useful comments to translators the better. LGTM.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Update the text used as context.
Both are technically grammatically correct, but I think @Stan 's suggestion gets the point across better.
Maybe:
Meant to be the closest name in the ancient native language of the civilization. Most translations don't need to modify this string.
If this get changed this page should be updated https://trac.wildfiregames.com/wiki/TechModifications
It looks like an oversight at least.
In D5313#226790, @Stan wrote:
Wed, Jul 24
In D5309#226820, @Itms wrote:Yes it should have no impact on the actual translation, but I would like to make sure tinygettext doesn't choke on strange unicode delimiters when parsing pot files.
In D5309#226814, @Dunedan wrote:tinygettext is used for the actual translation, isn't it? In that case I'd expect it isn't affected at all, because the reference isn't necessary to do translations. It's merely an information to allow human translators to look up the string in the source code.
In D5309#226798, @Itms wrote:Does tinygettext properly handle the unicode whitespace delimiters or should we patch it as well?
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Rebase against current trunk and skipping of the "debug" translation as well.
Successful build - Chance fights ever on the side of the prudent.
In D5308#226795, @Itms wrote:Did the empty strings actually appear in Transifex?
Simplify regex
I don't have enough knowledge about the extractors script to understand the changes performed, but the proposal of harmonizing our format with gettext sounds logical. Does tinygettext properly handle the unicode whitespace delimiters or should we patch it as well?
This looks obviously sane. Did the empty strings actually appear in Transifex? I don't remember encountering them. How many empty strings are deleted from PO files after that fix?
This looks good to me, with the caveat of ignoring the debug translation as well.
In D5282#226669, @real_tabasco_sauce wrote:@phosit could you profile that replay I shared above? This will tell us if the difference between your profile and mine is due to replay differences or computer differences. Maybe other differences? like petra? in my replay, I just attack moved groups of 200 units.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
In D5262#226386, @phosit wrote:Maybe the new function getPlayerIDs can be used in more places, which did their own stuff or used sortAllPlayers but the sorting isn't necesarry.
Normally there are two teams with the same number of players. Using river each team gets grouped in a line.
So river might be confused with groupedLines.Not really related to this diff: Some names are technical (circle, groupedLines, randomGroup) while others are vivid (river, stronghold)
use getPlayerIDs where sortAllPlayers() is used to get an array of IDs.
ok the accuracy part definitely works in a26 vanilla XD.
In D5313#226778, @Stan wrote:According to this though the previous code was valid https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/simulation/components#L677 (Because the code isn't)
Where did you see the spread was wrong?
According to this though the previous code was valid https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/simulation/components#L677 (Because the code isn't)
The last change on that file was three years ago. https://github.com/0ad/0ad/commits/master/binaries/data/mods/public/simulation/data/technologies/unit_elite.json
Tue, Jul 23
Is that error currently in a26 (and earlier alphas)?
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
good catch. I didn't test it but it looks correct.
In D5282#226253, @real_tabasco_sauce wrote:well I think it could be nice if performance was at least roughly equal to the current. @phosit are you sure that profile was from the more recent patch (the one that doesn't use isqrt).
Also, maybe try the same replay i've been using?
commands.txt21 KBDownload
metadata.json14 KBDownload
I'm be pretty surprised by this large difference. if it's still such a big difference with this replay, maybe mine is just better at division XD.