historic_bruno

Apologies, I failed to test a recent commit on VS2013 (which we still technically support). But Angen is right, it will be VS2015 only as of alpha 24. Still my bad though. Ticket: #5539

To what, a sign-in page?

I've used it when contributing to a few projects, and it seems pretty good. Our Evil Twin uses it. I wonder if it would duplicate most of what we have on Phabricator though? It seems overkill to have both, unless we only use gitlab as a git server (not sure what the advantage of that is).

Not every project uses GitHub. It's quite common for FOSS to have GitHub read-only mirrors for visibility, but direct users to a self-hosted platform for reporting errors and submitting patches. IMO we should only accept GitHub PRs if we're actively using GitHub. I personally wouldn't want to use GH as a main development hub, since it's controlled by a private company and they could change policies at any time. I like having it as a mirror for reference and for people who are used to GitHub UI, but I like the advantages of having our own main Git repo. The GH mirror is OK until that time comes. Git on the other hand, is something I fully support and have since the topic first arose. In fact, we're supposed to be transitioned to git by now. I don't agree that "SVN is ok", it's a development choke point when we're juggling multiple features and bug fixes at once, that all have to be resolved to SVN. Also, I want a stable branch (where well-tested and reviewed code goes, that always compiles and runs with minimal regressions) and a less stable master branch (might or might not compile and run well at any given time), in addition to feature branches which can be integrated with CI, to make it easier for devs to test eachother's changes and thus, being more efficient to review.

You have access to the following functions in JS (see JSInterface_ConfigDB.cpp): bool Engine.ConfigDB_HasChanges(namespace) bool Engine.ConfigDB_SetChanges(namespace, bool) string Engine.ConfigDB_GetValue(namespace, key) bool Engine.ConfigDB_CreateValue(namespace, key, value) bool Engine.ConfigDB_RemoveValue(namespace, key) bool Engine.ConfigDB_WriteFile(namespace, path) bool Engine.ConfigDB_WriteValueToFile(namespace, key, value, path) bool Engine.ConfigDB_SetFile(namespace, path) bool Engine.ConfigDB_Reload(namespace) For namespace, I guess "mod" is most appropriate. I think you could check if your new hotkey(s) are set yet in mod.cfg (mod namespace) and if not, set the defaults. Also check out the options GUI implementation. Note: this isn't ideal -- each mod should have its own separate config.

If anything I would say garrisoned melee units should add significantly less ranged defense(arrows) compared to garrisoned ranged units, but it's not unreasonable for them to add at least some capability there (even throwing boulders, dumping pitch, etc. a short distance, basically the "murder holes" tech of AoK). But they won't magically become sharp shooters. At least conceptually it makes sense, but it might "feel" differently in games. Conversely, melee units should add more loyalty than ranged units, but even a building held by archers would have some inherent "loyalty", only they aren't as effective at close range. I think you're already making that point, in which case I fully agree :-)

I remember there was a config file that macOS users had and shared among themselves back in the day. You might try reaching out to them, either here, in the lobby, or on IRC #0ad-dev. Same with AZERTY keyboards and probably others. I wouldn't be averse to including several default hotkey configurations for different systems (in fact, it was always my goal to have "hotkey sets", for different keyboard layouts and such which could ideally be switched via in-game menus).

For what it's worth, I'm enrolled in the dev program now. I'm not sure that getting on the App Store is feasible yet, if it ever will be. But I see no problem with signing our bundles.

Addendum: I was reminded that Control is also used for game session hotkeys. So those need to be re-assigned if you use this option. Super key is one recommended alternative. See HotKeys and default.cfg You would want to copy any of the relevant hotkey lines in default.cfg to user.cfg (as described above) and save the file, before starting the game.

Hi, you need to enable "Emulate right-click with Ctrl+Click on Mac mice" in your configuration file. This option isn't exposed in the game options UI (yet). So, you have to edit the config file, I recommend this: Open Terminal (Spotlight > Terminal), run this command: nano ~/Library/Application\ Support/0ad/config/user.cfg At the end of the file, add this on a separate line: macmouse = true Save with Control+O, Return Exit with Control+X The reason for this option is that the behavior isn't desirable for all users (notably those who have a two button mouse). I'll make a note of this, we should have the option in the UI for macOS users. EDIT: ticket for the issue: #5523 You can find out more about settings and config files here.

Maybe you could try connecting over a VPN? Some of them allow port forwarding as well.

Hi, it would still be nice to know about your system. If you can, attach the system_info.txt from the game's log folder. Perhaps this is a bug we can fix.

Indeed! They are planned, along with a few other water improvements: #48

Given those sorts of performances, I'm not sure that we miss much. Maybe some technical skill, but technical skill isn't everything. I don't see WFG members constantly trolling other projects. Am I wrong?

I personally wouldn't want to collect email addresses. We could do something like providing a "recovery code" that you would have to make note of, and then could be used to delete or reset your account.