Successful build - Chance fights ever on the side of the prudent.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 11 2022
ZZZ forgot to revert system files.
Successful build - Chance fights ever on the side of the prudent.
In D4428#188938, @wraitii wrote:Did you manage to fix that error? I didn't run into it.
The others I'm aware of, need to fix em.
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
@Silier Moved the mechanism for determining the name of the rank technology down two levels - to make it easier to replace the technology identification system in the future (if required)
added rankTechName() method in Identity.js (Encapsulating the technology name mechanism)
Maybe, but unless its hardcoded path for folder what essentially cannot be avoided, depending on file names following certain scheme looks like bad design
- Reads correct.
- Nice reduction of duplication.
(You'll need to update the copyright years.)
In D4340#188962, @Silier wrote:If technology file does not follow the naming, this will not work.
It would be better if it could be avoided.
Jan 10 2022
Apply the patch and compile the game
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Fix notes
On the second thought.
If technology file does not follow the naming, this will not work.
It would be better if it could be avoided.
Some files are missing from the tarball, see https://bugzilla.mozilla.org/show_bug.cgi?id=1749306
In D4428#188938, @wraitii wrote:Did you manage to fix that error? I didn't run into it.
The others I'm aware of, need to fix em.
In D4428#188935, @nwtour wrote:I have not build this version out of the box (linux/clang-11)
/home/nwtour/ff/0ad/libraries/source/spidermonkey/mozjs-91.5.0/modules/fdlibm/src/math_private.h:34:21: error: typedef redefinition with different types ('__double_t' (aka 'double') vs 'long double')
Did you manage to fix that error? I didn't run into it.
The others I'm aware of, need to fix em.
I have not build this version out of the box (linux/clang-11)
In file included from /home/nwtour/ff/0ad/libraries/source/spidermonkey/mozjs-91.5.0/modules/fdlibm/src/e_acos.cpp:44: /home/nwtour/ff/0ad/libraries/source/spidermonkey/mozjs-91.5.0/modules/fdlibm/src/math_private.h:34:21: error: typedef redefinition with different types ('__double_t' (aka 'double') vs 'long double') typedef __double_t double_t; ^ /usr/include/math.h:156:21: note: previous definition is here typedef long double double_t; ^ 1 error generated. ERROR: SpiderMonkey build failed
Looks good to me. I think this actually breaks more than just the Atlas overlay though, thankfully we don't have too many maps where terrain changes.
Compilation and (de)serialisaton works.
Successful build - Chance fights ever on the side of the prudent.
Good enough.
Successful build - Chance fights ever on the side of the prudent.
Jan 9 2022
@wraitii Please look, this change correct?
Seems to work on Windows/Nvidia with no issue.
Successful build - Chance fights ever on the side of the prudent.
Successful build - Chance fights ever on the side of the prudent.
Improved PlayerColor function info and made lots of changes to summary.
Successful build - Chance fights ever on the side of the prudent.
For another patch we might want to make it an option. E.g. for campaigns.
Successful build - Chance fights ever on the side of the prudent.
will be commiting soon if noone will object
Compile on 10.12/10.14/10.15 and 11 and 12 ideally.
Successful build - Chance fights ever on the side of the prudent.
This one should work on CI
Build failure - The Moirai have given mortals hearts that can endure.
Build failure - The Moirai have given mortals hearts that can endure.
Successful build - Chance fights ever on the side of the prudent.
This won't trigger the assertion for nothing
Build failure - The Moirai have given mortals hearts that can endure.
GCC does need more flags. This is getting verbose but it works.
Open player profile lookup
look for player
error
Build failure - The Moirai have given mortals hearts that can endure.
Fix atlas architecture
Build failure - The Moirai have given mortals hearts that can endure.
Believe this one might work. This version of SM's virtualenv.py does something rather odd with sitecustomize which is changed downstream.
Build failure - The Moirai have given mortals hearts that can endure.
Some tweaks and fixes.
In D4425#188797, @wraitii wrote:Mh, you're skipping over the bit where it won't stuck :P . Either the tasks will be cancelled before they're started, and the the main thread will compute paths, or they'll actually be started, so they won't hang on texture conversion.
Linter.
In D4425#188796, @vladislavbelov wrote:It's written so that it will stuck.
Mh, you're skipping over the bit where it won't stuck :P . Either the tasks will be cancelled before they're started, and the the main thread will compute paths, or they'll actually be started, so they won't hang on texture conversion.
In D4425#188790, @wraitii wrote:I believe the simulation (pathfinder anyways) ends up running computations on the main thread anyways right now, so it wouldn't get stuck.
It's written so that it will stuck.
I applied the patch, compiled and ran a medium Deep Forest with everything low except the model randomisation, that was normal. Zoomed out to have the whole map in one view.
There is no visible difference in performance observed.
Mmmh yours might be better and more complete.
For what it's worth, here's my own patch for this : https://github.com/wraitii/0ad/commit/2f522e8be4ee14a589be8c8e35b24b9991cfc770
In D4425#188788, @vladislavbelov wrote:Also it seems that converting many textures may stuck the game, particularly simulation. If threads are overused by the converter.
Also it seems that converting many textures may stuck the game, particularly simulation. If threads are overused by the converter.
In D4423#188755, @nwtour wrote:So in principle there should be no performance changes
It depends on implementation, it uses glDrawRangeElements with max numbers. In some particular implementation driver might prefetch data for caches according to the range, especially if it sees that the range is continuous.
The function seems to be called "fallback" (_mesa_draw_gallium_fallback ) so maybe you just don't support it?
In Mesa/Linux uses glDrawRangeElements() when called glDrawElements().
So in principle there should be no performance changes