Page MenuHomeWildfire Games
Feed All Stories

Today

Stan requested changes to D1692: Reset selection in findIdleUnits even if no units are idle.

Then it's decided. To fix this issue it's better to play a sound :)

Tue, Dec 11, 8:44 AM
vladislavbelov added a comment to D1692: Reset selection in findIdleUnits even if no units are idle.
In D1692#67009, @smiley wrote:

To be honest, I find this behavior to be more unintuitive. Currently I won't lose my selection if I just wanted to check if there are any idle units (usually, if there are none I would do something with the current selection). But now, I would have to add the units to the selection after.
Maybe it's just me, but I think it would be best to remove that todo. Engine.PlayUISound(filename, looping); if interested.

I have similar thoughts, but I posted them in the ticket: https://trac.wildfiregames.com/ticket/5360 :)

Tue, Dec 11, 8:43 AM
smiley added inline comments to rP17674: Update the idle-worker-button onSimulationUpdate. Patch by svott, fixes #3736..
Tue, Dec 11, 7:23 AM
smiley added a comment to D1692: Reset selection in findIdleUnits even if no units are idle.

To be honest, I find this behavior to be more unintuitive. Currently I won't lose my selection if I just wanted to check if there are any idle units (usually, if there are none I would do something with the current selection. But now, I would have to add the units to the selection after.
Maybe it's just me, but I think it would be best to remove that todo. Engine.PlayUISound(filename, looping); if interested.

Tue, Dec 11, 7:03 AM

Yesterday

Stan added reviewers for D1692: Reset selection in findIdleUnits even if no units are idle: bb, elexis, smiley.
Mon, Dec 10, 10:54 PM
Itms added a member for Contributors: cpc.
Mon, Dec 10, 10:09 PM
cpc created D1692: Reset selection in findIdleUnits even if no units are idle.
Mon, Dec 10, 9:27 PM

Sun, Dec 9

fabio accepted D1691: Remove boost "system" from build-osx-libs.sh.
Sun, Dec 9, 4:58 PM
Vulcan added a comment to D1691: Remove boost "system" from build-osx-libs.sh.

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

Sun, Dec 9, 3:25 PM
Stan created D1691: Remove boost "system" from build-osx-libs.sh.
Sun, Dec 9, 3:21 PM

Sat, Dec 8

Itms committed rP21946: [i18n] Last manual update of the translations and associated credits..
[i18n] Last manual update of the translations and associated credits.
Sat, Dec 8, 11:04 PM
Itms committed rP21945: Correctly choose DarwinSSL TLS backend on macOS for libcurl..
Correctly choose DarwinSSL TLS backend on macOS for libcurl.
Sat, Dec 8, 10:09 PM
Itms closed D1687: Fix build on OSX 10.9.5 Mavericks.
Sat, Dec 8, 10:09 PM
Itms committed rP21944: New mod signing key for A23b..
New mod signing key for A23b.
Sat, Dec 8, 9:52 PM
Itms closed D1686: New mod signing key for A23b.
Sat, Dec 8, 9:52 PM
trompetin17 accepted D1687: Fix build on OSX 10.9.5 Mavericks.

I rebuild libcurl and game, I was able to join in lobby, open mod.io

Sat, Dec 8, 6:59 PM
Vulcan added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

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

Sat, Dec 8, 6:31 PM
Stan updated the diff for D1687: Fix build on OSX 10.9.5 Mavericks.

Upload the correct patch.

Sat, Dec 8, 5:58 PM
Stan added a comment to D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.

For the textures.xml i'm not sure whether it's not better to have it in the public mod and not in the mod mod. Sounds sane that xml validation be part of the engine, but textures.xml are directly relevant to the textures files one put in his mod. So I don't think it should be part of the engine.

Sat, Dec 8, 5:51 PM
elexis added a comment to D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.

It's the same situation with mod/art/textures/ui/textures.xml it's only present in the "mod" mod, but the directory (without the xml file) also exists in "public".
And these rngs/rncs only exist in the public mod.
./mod/art/textures/texture.rng
./mod/audio/sound_group.rng
./mod/shaders/program.rng
./mod/gui/gui.rng
./mod/gui/gui_page.rng

Sat, Dec 8, 5:48 PM
Stan added a comment to D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.

I package without it all the time :)

Sat, Dec 8, 5:38 PM
elexis added a comment to D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.

Whut? It's impossible to package without the modmod currently.

Sat, Dec 8, 5:37 PM
Stan added a comment to D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.

One has to be careful to add a dependency to modmod when packaging the mods. Otherwise you will get bad textures if you remove textures.xml. Those files decide what compression will be used on a png file.

Sat, Dec 8, 4:02 PM
Harbormaster failed remote builds in B6498: Diff 7036 for D1687: Fix build on OSX 10.9.5 Mavericks!
Sat, Dec 8, 3:54 PM
Vulcan added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

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

Sat, Dec 8, 3:53 PM
Stan updated the diff for D1687: Fix build on OSX 10.9.5 Mavericks.

Disable all TLS stuff.

Sat, Dec 8, 3:53 PM
Vulcan added a comment to D1690: Fix Danubius ownershipchange subscription following rP21445.

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

Sat, Dec 8, 3:44 PM
elexis created D1690: Fix Danubius ownershipchange subscription following rP21445.
Sat, Dec 8, 3:43 PM
elexis added inline comments to rP21445: Refactor and move random template composition triggerscript code used for gaiaā€¦.
Sat, Dec 8, 3:39 PM
Vulcan added a comment to D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.

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

Sat, Dec 8, 1:49 PM
elexis created D1689: Delete duplicate art/textures/texture rng/rnc/xml files following rP15678.
Sat, Dec 8, 1:45 PM
elexis added inline comments to rP15678: Make the modmod standalone..
Sat, Dec 8, 1:35 PM
Itms added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.
In D1687#66940, @elexis wrote:

Not few flags, libCURLs ./configure --help | grep without yields

Sat, Dec 8, 1:26 PM
elexis added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.
In D1687#66939, @Stan wrote:

It would be nice to disable all other librairies if possible.

Sat, Dec 8, 12:56 PM

Fri, Dec 7

Stan added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

Ah autocorrect try Itms fix ;) I meant to write--without-brotli.
It would be nice to disable all other librairies if possible.

Fri, Dec 7, 9:03 PM
Itms added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

@trompetin17 It looks like you have yet another system lib which tries to sneak into the build šŸ˜  Can you try --without-brotli? Just like we did with nghttp2.

Fri, Dec 7, 9:00 PM
Stan added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

Can you pass --without-ssl ?

Fri, Dec 7, 8:22 PM
trompetin17 added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

I tried today and when i tried to build the game It gave me a error:

Fri, Dec 7, 7:47 PM
Itms added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

Clarifying a small thing in Stan's answer (which is correct): when D1687 is committed (tonight probably, as trompetin is testing it as we speak), mod.io will work for everyone, regardless of who built the game.

Fri, Dec 7, 5:57 PM
elexis added inline comments to rP21726: Add a mod installer, fixes #4027..
Fri, Dec 7, 5:56 PM
Stan added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

It doesn't crash on any of those platforms if I build the game.

Fri, Dec 7, 5:31 PM
elexis added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

If it crashes for everyone on 10.9, 10.10, 10.11, we can disable TLS in the config and remove that one TLS sentence for OSX.

Fri, Dec 7, 5:15 PM
vladislavbelov added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.
In rP21943#31690, @Itms wrote:

The consensus in that topic is the reason why I asked user1 to commit this, but if you want I can formally accept this revision.

The commit contains only few style mistakes. So the accept isn't required. My point that the commit doesn't have any linked diff/ticket or link to its conversation. My first thought was are these bots and rooms already exist.

Fri, Dec 7, 3:38 PM
elexis added a comment to rP21726: Add a mod installer, fixes #4027..

Perhaps we could use a bugreport on the a24 milestone for the issue reported in previous posts, as users seem to run frequently into that.

Fri, Dec 7, 3:16 PM
Stan added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

Ah right.

Fri, Dec 7, 2:58 PM
Itms added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

@elexis Yeah, it's the clock_gettime thing...

Fri, Dec 7, 2:55 PM
Itms added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

@vladislavbelov In the staff discussions, it seemed that we had reached a consensus on creating this new room, but leaving the other version numbers intact (in order to push people into upgrading, without forcing them). On top of what elexis said, we are legally obliged to push the lobby users into using A23b, so that they can accept the new terms.
The consensus in that topic is the reason why I asked user1 to commit this, but if you want I can formally accept this revision.

Fri, Dec 7, 2:47 PM
Stan added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

If I compile on 10.9.5 I can access the lobby with tls without issues.

Fri, Dec 7, 2:34 PM
Stan added a comment to rP21942: Target 10.9 as minimal OSX version in all scripts, in order to match theā€¦.

Macos 10.8 was released in 2012. Considering how aggressive Mac is when it comes to upgrade and the fact people don't really know our game works on Mac I do not find it so hard to believe.

Fri, Dec 7, 2:30 PM
elexis added a comment to rP21940: Build gloox with GnuTLS on macOS, refs #4705..

On versions of OSX/macOS up to 10.11, TLS handshakes can still fail and crash?

Fri, Dec 7, 2:10 PM
elexis awarded rP21941: Import part of commit https://github.com/premake/premakeā€¦ a Like token.
Fri, Dec 7, 2:09 PM
elexis added a comment to rP21942: Target 10.9 as minimal OSX version in all scripts, in order to match theā€¦.

(I find it hard to beleve that since Nov 2016, Alpha 21 (SM38 / #3708), noone has tried running a release bundle on macOS 10.8 and reported it as defunct, on the other side I only recall people using recent macOS versions.)

Fri, Dec 7, 2:09 PM
elexis added a comment to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
  • There is a ticket for removing the instances of the 3 border
  • The map should be fixed, the commit should be dug out.
  • I recall Petra complains too about stuff outside of the map area.
  • I wonder if there shouldn't be a warning or error message about entities placed outside of the map area (in the border or beyond) when parsing the finished mapgeneration. There is a ticket for warnings about gatherable entities that are on a too slopy position to be gatherable). CCmpPosition has the OutsideOfWorld boolean to represent units that are outside of the map area. There might be edge cases where one could argue that entities outside of the map area would be justified (for example there is a skirmish map that has a wonder where 50% of the area is inside the map and 50% in the shroud of darkness). But perhaps these edge cases can all be satisfied with the given restrictions (the center position may not be on a slope and must be inside the map). Otherwise if these edge cases are really relevant, one could add a boolean flag to the map that allows or complains (and possibly removes) entities at invalid positions. Thus adding an automated way of informing map authors when they broke their map. If the engine only loads valid maps, or if the PositionComponent prevents setting such an out-of-world position without setting out-of-world to true, it wouldn't have to add these border checks to every place in the simulation (including here).
Fri, Dec 7, 1:39 PM
elexis added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

Getting an OOS error at a later time in a match versus getting an OOS error at the beginning of a match is not a qualification to change the room in the re-release.
That WFG logs who accepted the new GDPR terms and that players can play without the a23 OOS errors are nice benefits, but not the reason to add this new room.
Most certainly multiple players in a match with 6-8 players getting disconnected at the gamestart and every rejoin attempt on every map due to the petra AI teambonus initialization freezing the non-threaded NetClient for 10+ seconds up to the point where it counts that as a disconnect is.
The only reason many 4v4s currently work is because those people use svn, that includes a petra AI skip and the NetServer and NetClient waiting for up to 60+ seconds on init before disconnect (relevant in case someone did enable AIs or any other code being that slow. The actual patch to use threading in the NetClient is unpublished).
There are a number of other committed C++ fixes, why spend additional effort to provide a partial release?
Usually the lobby becomes empty after the first day of a new release due to the lobby subject and the absence of players and games. The intention is that players can play the game without crashing in several ways and to push the players into actually installing the update, rather than continuing to get N reports about the bugs fixed this summer every day (including the macOS thing and some other OOS errors).
The mod version is not changed, so that people can still replay their old replays, continue their savegames, can use the same mods (which should all be fully compatible except fgod which is currently incompatible with our terms in two ways, so fpre rebasing that means he would fix that.).

Fri, Dec 7, 1:22 PM
Stan added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

Not to mention ~1GB for an upgrade which literally added nothing visible. Not really an issue for most though.

Fri, Dec 7, 9:10 AM
smiley added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

Not to mention ~1GB for an upgrade which literally added nothing visible. Not really an issue for most though.

Fri, Dec 7, 7:11 AM

Thu, Dec 6

vladislavbelov added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.
In rP21943#31673, @Stan wrote:

To me people should upgrade.

Only if needed.

Thu, Dec 6, 9:25 PM
nani added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

In current alpha 23 square maps are not rejoinable (OOS), aren't they? That would make them sufficiently incompatible.

Thu, Dec 6, 8:33 PM
Stan added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

To me people should upgrade. If we were commercial software, it would be different. But here you literally have no reason not to upgrade.

Thu, Dec 6, 8:16 PM
vladislavbelov updated subscribers of rP21943: Update client\'s default.cfg for the new muc room `arena23b`.
Thu, Dec 6, 7:32 PM
vladislavbelov updated subscribers of rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

Do really need it? I thought we have pretty compatible versions. Also these *b versions aren't running on serverside, no?

Thu, Dec 6, 7:31 PM
smiley added a comment to rP21943: Update client\'s default.cfg for the new muc room `arena23b`.

Not sure whether intentional, but wont this prevent 23 playing with 23b. I thought that was a requirement judging from all the hassle about compatibility.

Thu, Dec 6, 4:49 PM
user1 committed rP21943: Update client\'s default.cfg for the new muc room `arena23b`.
Update client\'s default.cfg for the new muc room `arena23b`
Thu, Dec 6, 2:45 PM

Wed, Dec 5

smiley added inline comments to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Wed, Dec 5, 8:19 AM

Tue, Dec 4

smiley added inline comments to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Tue, Dec 4, 10:23 PM
Stan added inline comments to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Tue, Dec 4, 10:17 PM
smiley added inline comments to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Tue, Dec 4, 9:47 PM
Stan added inline comments to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Tue, Dec 4, 9:38 PM
smiley added inline comments to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Tue, Dec 4, 9:03 PM
Vulcan added a comment to D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.

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

Tue, Dec 4, 8:59 PM
smiley created D1688: Ignore entities out of the passable map area in GetLandSpawnPoints.
Tue, Dec 4, 8:57 PM
Vulcan added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

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

Tue, Dec 4, 9:06 AM
Stan updated the diff for D1687: Fix build on OSX 10.9.5 Mavericks.

Fix path

Tue, Dec 4, 8:34 AM
smiley added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: 0ad/libraries/osx/build-osx-libs.sh
|===================================================================
|--- 0ad/libraries/osx/build-osx-libs.sh
|+++ 0ad/libraries/osx/build-osx-libs.sh
--------------------------
File to patch: 
Skip this patch? [y] 
Skipping patch.
1 out of 1 hunk ignored

Path of the file seems off.

Tue, Dec 4, 6:54 AM

Mon, Dec 3

Harbormaster failed remote builds in B6492: Diff 7029 for D1687: Fix build on OSX 10.9.5 Mavericks!
Mon, Dec 3, 1:56 PM
Vulcan added a comment to D1687: Fix build on OSX 10.9.5 Mavericks.

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

Mon, Dec 3, 1:56 PM
Stan created D1687: Fix build on OSX 10.9.5 Mavericks.
Mon, Dec 3, 1:55 PM
Itms committed rP21942: Target 10.9 as minimal OSX version in all scripts, in order to match theā€¦.
Target 10.9 as minimal OSX version in all scripts, in order to match theā€¦
Mon, Dec 3, 12:08 PM
Itms closed D1685: Target 10.9 as minimal OSX version.
Mon, Dec 3, 12:08 PM
Itms requested changes to D1482: Target build version explicitly for Xcode.

The patch is currently useless, because xcodebuildsettings was added in premake5 alpha12 (we have alpha10): see https://github.com/premake/premake-core/wiki/xcodebuildsettings.

Mon, Dec 3, 11:56 AM

Sun, Dec 2

Vulcan added a comment to D1482: Target build version explicitly for Xcode.

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

Sun, Dec 2, 11:22 PM
Stan updated the diff for D1482: Target build version explicitly for Xcode.

Use the correct option, check if it is set before using it.

Sun, Dec 2, 10:40 PM
Itms committed rP21941: Import part of commit https://github.com/premake/premakeā€¦.
Import part of commit https://github.com/premake/premakeā€¦
Sun, Dec 2, 9:58 PM
Itms closed D1669: Remove hardcoded minimum OSX version in premake5.
Sun, Dec 2, 9:58 PM
Itms committed rP21940: Build gloox with GnuTLS on macOS, refs #4705..
Build gloox with GnuTLS on macOS, refs #4705.
Sun, Dec 2, 9:53 PM
Itms closed D1654: Build gloox with GnuTLS on macOS.
Sun, Dec 2, 9:52 PM
Itms committed rP21939: Minor change to the libcurl macOS compilation..
Minor change to the libcurl macOS compilation.
Sun, Dec 2, 9:42 PM
Itms closed D1487: curl OSX build script fix.
Sun, Dec 2, 9:42 PM
Stan planned changes to D1482: Target build version explicitly for Xcode.

I assumed we should use premake variable because options might be undefined.

Sun, Dec 2, 9:25 PM
Itms requested changes to D1482: Target build version explicitly for Xcode.

I agree, but I think you didn't test this? The option must be accessed with _OPTIONS (see the other use of it in the file for an example) and I suggest running the whole premake script with and without the parameter passed.

Sun, Dec 2, 9:11 PM
Vulcan added a comment to D1482: Target build version explicitly for Xcode.

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

Sun, Dec 2, 8:48 PM
Stan retitled D1482: Target build version explicitly for Xcode from Target 10.8 explicitly for Xcode to Target build version explicitly for Xcode.
Sun, Dec 2, 8:46 PM
Stan added a comment to D1669: Remove hardcoded minimum OSX version in premake5.

Sounds fair then. Thanks for taking time to elaborate :)

Sun, Dec 2, 8:45 PM
Stan updated the diff for D1482: Target build version explicitly for Xcode.

Getting this right doesn't seem like it would hurt the A23 re release was it to be included, right @Itms ?

Sun, Dec 2, 8:44 PM
Stan commandeered D1482: Target build version explicitly for Xcode.
Sun, Dec 2, 8:43 PM
Itms added a comment to D1669: Remove hardcoded minimum OSX version in premake5.
In D1669#66853, @Stan wrote:

I see. Won't be hard to keep track of all the patches we apply ? For now we only have one but we might have more in the future, no ?

Sun, Dec 2, 8:40 PM
Stan added a comment to D1669: Remove hardcoded minimum OSX version in premake5.

I see. Won't be hard to keep track of all the patches we apply ? For now we only have one but we might have more in the future, no ?

Sun, Dec 2, 8:22 PM
Itms added a comment to D1669: Remove hardcoded minimum OSX version in premake5.
In D1669#66846, @Stan wrote:

Might I suggest to save this as a patch and apply it on premake when updating update workspaces on OsX ?

Sun, Dec 2, 8:04 PM
Itms added inline comments to D1685: Target 10.9 as minimal OSX version.
Sun, Dec 2, 8:03 PM
Stan added inline comments to D1685: Target 10.9 as minimal OSX version.
Sun, Dec 2, 7:44 PM