Page MenuHomeWildfire Games

Recent Activity

Today

bb added a comment to D4155: Remove code for the lobby bots from SVN.
In D4155#182536, @bb wrote:

Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code?

I think this is absurdly unlikely at this point, but even if GitHub deletes the repose unilaterally, git makes it so that we'd very likely have recent-is mirrors on several dev computers & on the lobby server itself. I don't think this should be a concern.

Even if unlikely not impossible. So we will be dependent on a few persons who have the code. Also this doesn't save all comments and discussions.

Why give away the sovereignty we have?

'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/

Phab will keep running as long as we keep it running on our servers. Also I saw there were efforts to fork it.

Also sovereignty is essentially kept per the first point.

The first point doesn't keep our sovereignty at all.

Tue, Sep 28, 12:44 PM
wraitii added a comment to D4155: Remove code for the lobby bots from SVN.
In D4155#182536, @bb wrote:

Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code?

I think this is absurdly unlikely at this point, but even if GitHub deletes the repose unilaterally, git makes it so that we'd very likely have recent-is mirrors on several dev computers & on the lobby server itself. I don't think this should be a concern.

Why give away the sovereignty we have?

'Cause Phabricator is dying, see https://wildfiregames.com/forum/topic/42181-phabricator-is-no-longer-being-maintained-upstream/
Also sovereignty is essentially kept per the first point.

Why let the codebase fall apart, literally?

Other arguments:

  • It's a good way to gain knowledge about GitHub usage, which will help should we decide someday to migrate somewhere else.
  • the person who wants to work on this code wants to work on GitHub because it's easier for them

Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.

It's a quite realistic prospect to change the rating calculation without changing the rating display, and vice-versa.
The actual hard problem is deployment, and since we don't actually deploy the bots synchronously with SVN, we'd already have a lot of trouble if you wanted to implement a new system of rating.

Tue, Sep 28, 9:51 AM
Langbart added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

This image was only to illustrate my point with deselecting units, but the layout looks nice. Having a bunch of units grouped together to see who is part of a team looks appealing.
Hyrule conquest does it but with control groups.

Tue, Sep 28, 8:33 AM
Langbart added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

When I try to deselect some units by holding down the Ctrl key and right-clicking on the icon, it only works for battalions with one unit type.

Tue, Sep 28, 8:22 AM
sera added a comment to D4283: Implement "-help" as a command line option.

Do you need to call parse multiple times? If not why do you need the method?

Tue, Sep 28, 12:48 AM
andy5995 added a comment to D4283: Implement "-help" as a command line option.

I understand you'd rather I use C++ code. I'm not famillar with C++ actually, so I'll probably not do anymore with this diff.

Tue, Sep 28, 12:15 AM

Yesterday

Vulcan added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

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

Mon, Sep 27, 10:42 PM
bb added a comment to D4155: Remove code for the lobby bots from SVN.
In D4155#182309, @Stan wrote:

The idea was to not put more strain on the server as the CI is already bringing it to its knees and instead rely on a third party (here github for the CI)

How is this required to reduce the stress on the CI? Keeping 20-odd files in our svn repo won't hurt that much. If we want the bots to ignore these files, let them (though we have the bots for a reason so we better use them when we need to).
Also what happens if github goes offline/kicks us (maybe not likely, neither impossible), we loose our code? What if gitHub puts restrictions on what we do, do we then abide? Why give away the sovereignty we have? Why let the codebase fall apart, literally?
Now some third party CI might be free, probably many proper things we currently host ourselves are going to be expensive (now the SPI reports says we don't have to worry to much about our finances, I think we can spend our money better)

First reason is that while development of the lobby is linked, it actually lives its own life and evolves at a different pace and to my despair it's not actually completely versioned

Say if I were to implement a new system of ratings, I did need to change the bots (as I need to compute the ratings) as well as some gui (i.e. I need to show the new rating). Having several repo's makes developing such a feature much harder, so is not wanted.
We have files in our repo which haven't been touched in the last 10 years or so and files which are changed every month or so. That is completely fine. So if these files are developed evolve at a different pace: fine. What is the problem? I suppose during CF we shouldn't change the lobby bots either (if there are bugs with them, we need to lift CF for them: fine). Even the more reason to keep them in the same repo.

This is actually a good step towards the engine split.

Splitting the engine doesn't mean having several repo's. In fact we shouldn't have the engine in another repo than the vanilla game or anything else we develop related to 0ad. If we want to split stuff we need to work with directories within the repo: having a separate directory for tools like this within our repo is perfectly fine with me, storing it in source might indeed not be ideal.
Even if we need several repo's, we should host them ourselves.

There is no trac phabricator/instance

If you mean to track tickets/ make comments on pull requests you can do that too on Github.

So we as developers need to look at yet another place for patches, instead of keeping everything in one place.

Unlike all the other tools this one is actually used in production .

So are the translation scripts and probably others too.

Mon, Sep 27, 10:16 PM
bb added a comment to rP25939: Select formations as a whole by default..

You missed the intro.txt (see some ticket I recently created)

Mon, Sep 27, 10:15 PM
vladislavbelov added a comment to D4283: Implement "-help" as a command line option.
In D4283#182533, @sera wrote:

std::cout

Currently std::cout is not a standard way to write to output and logs.

Mon, Sep 27, 10:05 PM
sera added a comment to D4283: Implement "-help" as a command line option.

If so, what should I use instead of debug_printf()?

Mon, Sep 27, 9:10 PM
Stan added a comment to D2432: Add a -help option.

I mean that debian provides or used to provide a man page for 0 A.D. while some other distributions do not :).

Mon, Sep 27, 8:28 PM
andy5995 added a comment to D2432: Add a -help option.
In D2432#102349, @Stan wrote:

Just for the record, only debian seems to provide a man command.

Mon, Sep 27, 8:04 PM
andy5995 added a comment to D4283: Implement "-help" as a command line option.
In D4283#182511, @Stan wrote:
Mon, Sep 27, 7:52 PM
Vulcan added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

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

Mon, Sep 27, 7:01 PM
Vulcan added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

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

Mon, Sep 27, 6:39 PM
Stan added a comment to D4283: Implement "-help" as a command line option.

I'm not sure debug_printf works at all on Windows. You need to have SysInternals dbgview in order to be able to see such output.

Mon, Sep 27, 6:33 PM
Freagarach updated the diff for D4282: Don't stop gathering after starting by autocontinue when in a formation..

A more involved fix.

Mon, Sep 27, 6:32 PM
sera added a comment to D4283: Implement "-help" as a command line option.

You won't need the readme.txt anymore if you have support for help, worst case just run "pyrogenesis -help > readme.txt" as a postbuild command. So no duplication required.

Mon, Sep 27, 5:58 PM
Freagarach updated the summary of D4282: Don't stop gathering after starting by autocontinue when in a formation..
Mon, Sep 27, 5:04 PM
Stan added a comment to D4283: Implement "-help" as a command line option.

I guess the issue was that we didn't want to duplicate the Readme inside the game's code. D4232 used a rather clever trick for that.

Mon, Sep 27, 4:20 PM
sera added a comment to D4283: Implement "-help" as a command line option.

IMHO the right approach is to change CmdLineArgs from an minimalist class to a proper command line parser where you register available options, does validation and has a help string for each.

Mon, Sep 27, 12:07 PM
autobuild committed rP25944: [i18n] Updated POT and PO files..
[i18n] Updated POT and PO files.
Mon, Sep 27, 9:25 AM
Stan added a comment to D4283: Implement "-help" as a command line option.

Did you see https://code.wildfiregames.com/D2432

Mon, Sep 27, 7:49 AM
andy5995 added a comment to D4283: Implement "-help" as a command line option.

This obviously isn't finished yet. I wanted to get some feedback before I proceeded.

Mon, Sep 27, 7:19 AM
andy5995 requested review of D4283: Implement "-help" as a command line option.
Mon, Sep 27, 7:15 AM
marder added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

Nope, since you effectively give the order to the formation controller, not to any individual member (it has been like that for a long time already).

Mon, Sep 27, 12:50 AM

Sun, Sep 26

Freagarach added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

Nope, since you effectively give the order to the formation controller, not to any individual member (it has been like that for a long time already).

Sun, Sep 26, 9:04 PM
marder added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

But why is there only one gather at this tree?

The idly waiting unit does not understand that they should help their friends to finish chopping their tree as well so that they can quickly go to the siege workshop together.

Sun, Sep 26, 4:35 PM
Langbart added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

But why is there only one gather at this tree?

Sun, Sep 26, 3:59 PM
marder added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

I still have no option to test at the moment but it sounds/looks exactly like the behavior I wanted. Thanks @Freagarach for the quick fix :)
@Langbart I'm a bit confused about the one gatherer in the video. Is the tree too far away for the others to reach it? From your explanation I thought that if the tree is in reach of the whole battalion, it should mean that the max amount of gather per tree try to gather it and the rest of the battalion is waiting for them to finish.
But why is there only one gather at this tree?

Sun, Sep 26, 12:04 AM

Sat, Sep 25

Langbart added a comment to D4282: Don't stop gathering after starting by autocontinue when in a formation..

Yes this solves the problem described earlier in D2175#182343. The woodcutters look for a new tree after they are done with the first one.

Sat, Sep 25, 3:57 PM
Langbart added a comment to D4108: Adds FreeType support to the engine.
In D4108#182476, @Stan wrote:

@s0600204 any idea what we could do for macos and pkg config ?

Rebase to take into account recent changes, then add the below suggested line so that the generated .pc file is in the correct place for our scripts to find it. (There's no need to relocate the header files.)

Sat, Sep 25, 2:15 PM
wowgetoffyourcellphone added a comment to D4273: [gameplay] Briton bonus - faster wood gather rate.

Perhaps look at the availability of technologies as a bonus. So, for instance, for Gauls they could get all of the wood upgrades sooner (bonus name: "Continental Forestry" or something). For Ptolemies, all of the food upgrades sooner (bonus name: "Nile Delta"). Things like this.

Sat, Sep 25, 7:20 AM
wowgetoffyourcellphone added a comment to D4266: Bring Walruss and Muskox back to the arctic biome.

I only wish we could make sure to place the walruses at the shoreline.

Sat, Sep 25, 7:14 AM
wowgetoffyourcellphone accepted D4266: Bring Walruss and Muskox back to the arctic biome.
Sat, Sep 25, 7:12 AM
wowgetoffyourcellphone added a comment to D4266: Bring Walruss and Muskox back to the arctic biome.

Well, originally Alpine and Arctic were going to be combined to save the number of textures, but I have since realized that biomes can just share textures if necessary. That was why muskox and walruses were "removed." But "Alpine" and "Arctic" are separate again, so it makes sense that walruses and muskoxes to be added back to Arctic.

Sat, Sep 25, 7:12 AM
Vulcan added a comment to D3941: Use pkg-config with spidermonkey when not using --with-system-mozjs.

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

Sat, Sep 25, 3:36 AM
Vulcan added a comment to D3941: Use pkg-config with spidermonkey when not using --with-system-mozjs.

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

Sat, Sep 25, 3:14 AM
s0600204 updated the diff for D3941: Use pkg-config with spidermonkey when not using --with-system-mozjs.

Rebase now that parent revision has been committed

Sat, Sep 25, 3:08 AM