Leaderboard

It might be cool if rams gained speed with garrisoned units. The more people pushing the ram, the faster it should go right? I don't think any of the rams were motorized back then

Always thought this would be nice. Other things I thought about rams: A ram that has 0 garrisoned units cannot move. The ram does not contribute to population. A ram with 0 garrisoned units belongs to Gaia (inactive, does not attack). Whoever garrisons a unit gets the ram.

https://code.wildfiregames.com/D5179 @wowgetoffyourcellphone put it together. We didn't make the rams start slower, but the fully garrisoned ram is still a little slower than melee infantry.

UPDATE: Version 0.3.1 ( Fixed Summary tab ) NOTES: The mod changes some parts in the GUI. Access to Barter and Resources through the button in the top Panel. 8 Resources in the Game. New: Amphoras, Olives, Papyrus, Coins. Description: Base Barter rate at the start of the game: 100 to 82. After the first Barter on the Market, the rate for each resource starts to change dynamically. If 100 units of a resource can be exchanged for a number greater than 82 it means a more favorable rate. And vice versa. Dynamics of Rates: Standard - when prices are updated, the rate can increase or decrease with equal probability, i.e. 50%/50%. Growing - when prices are updated, the rate is more likely to rise than to fall. For example 85% increase, 15% decrease. New Resources are available only in the Civic Center (technology) and Market (technology and barter). The Civic Center generates new resources 2 times faster than the Market. Amphora Available to all factions in CC and Market through technology. standard price standard dynamics Olives standard price standard dynamics Access : Market through technology in all factions CC Production is available to the following factions through technology Athens Iberians Macedonians Ptolemies Rome Sparta Papyrus standard price standard dynamics Access : Market through technology in all factions without bonuses CC Ptolemies first technology is available in Phase 1. The rest of the factions from Phase 2. Coins Price: standard Dynamics: Growing (this resource increases in price during the game) Available to all factions in CC and Market through technology. Version(0.2.0): Added 5th type of resource "Coins" The resource is NOT AVAILABLE for mining on the map, and for traders moving between markets. Ways to get the resource: 1.It is possible to barter for other resources in the Market. 2.The Civic Centers and the Markets generate coins after researching technologies: Technology branch in the Civic Center (Coinage). Technology branch in the Market (Profit from local comerce) Feature of this resource: Has positive price dynamics Coins become more expensive over time. Preview Version(0.2.0) on YOUTUBE: Market in the Mod: After the first Deal, prices become dynamic, in other words they change: 1.If players Barter resources in the Market 2.If players do NOT Barter resources on the Market The exchange rate may gradually decrease or increase over time. In a new game, the exchange rates will be different from the previous game. Each next trade will increase or decrease the price differently. The interval between updates has been increased to 7sec. The market recovers unevenly for each update interval. Infrequent events where there is a significant jump in rates. Installation method: Right-click on the archive Select open with - specify 0 AD. In the Settings menu the Mod should be displayed in Green color. Save and Restart the game Volatile_Market.zip Volatile_Market_0_2_0.zip Volatile_Market_0_3_1.zip

Hi everyone, For a few years now we have pondered whether git would be the right VCS for the development of 0 A.D. One of the main selling points of git is the ability to create numerous branches for parallel development of features and bugfixes. Several popular platforms (Github, Gitlab.com, ...) leverage this to provide a feature-packed development environment, where people can contribute, discuss, review, and test patches. Historically, the development of 0 A.D. has been performed using SVN, which is a bit old... but suits our needs in a number of ways, already discussed elsewhere. We are using Phabricator to supercharge SVN with a review and CI/CD platform, but alas, Phabricator has been abandoned by its developers. In any case, a lot of contributors in the past couple of years have expressed disappointment with the peculiarities of Phabricator. Thus, we have discussed finally moving to git, without any strong urgency or hard opinions on the matter. I have proposed myself to set up a migration path and a new development environment for 0 A.D., and I am proud to present it to you folks today. I have started working on this "for real" more than a year ago, and started dedicating all my "0 A.D. time" (which has been very scarce) on this project at the end of Spring 2023. It is still, unfortunately, very much a work-in-progress, but now is the time to reveal it and receive feedback. Ideally, I would like to collect feedback from the community, finish the CI/CD system, and fix bugs, over the course of the spring, with the aim of performing the actual migration, if the community wishes to perform it, during the summer. As always, delays should be expected. It is worth noting that personal changes in my life/work balance will give me more free time after the summer. Thanks in advance for the feedback you will provide Presentation of the Proof of Concept I am self-hosting the services for the duration of the tests, so that I have full control and do not divert resources from WFG. All URLs are under itms.ovh, which should eventually become wildfiregames.com Email does not work on this Proof of Concept! I have no will to setup email and I certainly don't want to spam anyone with tests. The services are not updated automatically: the full migration takes around 48h and necessitates some human input. The PoC I am presenting was generated from scratch the past two days. I will update stuff from time to time, when I fix bugs or when I'm bored, but don't expect the PoC to follow the actual development of the WFG services. Please test as many things as you want and don't hesitate to try to break things! Now is the time to make sure I didn't forget anything. All the data sent to the PoC will be wiped out whenever I re-migrate the services, and of course whenever the actual migration happens. Please feel free to play around all this. The services (this will be regularly updated) - gitea.itms.ovh The development platform. This is an instance of Gitea, a self-hosted lightweight alternative to Gitlab/Github. If, in the far future, we want to stop self-hosting stuff, Gitea is compatible with Github features to allow for easy migration. The git repository is at wfg/0ad. Commit messages were reformatted, contain the original SVN revision, links to other commits are preserved as much as possible. The HEAD revision is the HEAD of the SVN repo. A currently WIP of the "future" branch of the git repository, adding commits needed for development with git, is at my fork Itms/0ad. All Gitea users were imported from Trac. Since email does not work, if you want to login, shoot me a DM and I'll send you a password. All Trac tickets are imported at wfg/0ad/issues. The Trac wiki is imported at wfg/0ad/wiki. I tried to self-document the PoC as much as possible, so please read the updated pages, especially BuildInstructionsGettingTheCode and BuildAndDeploymentEnvironment. The FAQ is defaced beyond readability because of its formatting peculiarities, work is needed, my apologies to everyone who worked hard on the visuals of the Trac page... - trac.itms.ovh A read-only copy of Trac, upgraded to the latest release. This serves as a reference, and can stay online as long as needed. See below for the redirect tool. - code.itms.ovh A registration-disabled copy of Phabricator, upgraded to the latest version (RIP). All the inactive accounts were deleted, especially the dormant spam accounts. This should stay up as much as possible. We need to keep all the discussions on patches and commits. TODO: I need to find a (possibly ugly) way to disable the upload of new diffs. - svn.itms.ovh The old and new SVN repositories. This holds the current ps repo (which will stop receiving commits after the migration), the audio and art sources (which will keep working as-is), the new libraries repos for precompiled Windows and for bundled libs, and most importantly the new nightly-build repo WIP: This is currently the biggest missing piece, as I am now going to start working on CI/CD, and the generation of the nightly build. Please read NightlyBuild if you want to know how this will work in the (hopefully close) future. - ariadne.itms.ovh Ariadne is a small redirect tool I wrote as a drop-in replacement for Trac or Phabricator when/if we decide to drop them. A lot of links to Trac exist on the Internet. You can follow Trac-like paths on Ariadne to find the relevant content. Each Trac page displays a link to the associated Ariadne path. For instance : A ticket https://ariadne.itms.ovh/ticket/666 A wiki page https://ariadne.itms.ovh/wiki/Manual_Settings A SVN changeset https://ariadne.itms.ovh/changeset/28056 A Phabricator commit page https://ariadne.itms.ovh/rP28056 A file in the Trac browser https://ariadne.itms.ovh/browser/ps/trunk/source/test_setup.cpp Ariadne also provides a nice page for knowing commit correspondence, just use `rXXXX` as path: https://ariadne.itms.ovh/r28056 https://ariadne.itms.ovh/r28000 Enjoy! And see you soon for regular updates

Firstly, thanks for working on this. If we're excluding Windows-only binary files from the gitea repo, would the contents of ./build/bin be considered candidates for removal? And ./build/premake/premake5/bin/release/premake.exe? For Linux and macOS, the premake binary is (re)built as part of update-workspaces.sh, and I don't immediately see why we couldn't (eventually) do the same on Windows; The cxxtestgen executable only seems to exist to get around the need to install python, (which we require on *nix to also build spidermonkey - for Windows, python is bundled inside mozbuild, a required prerequisite on Windows-systems only); The svnversion executable looks to only be used during the creation of a release (and so would only need to be installed on whatever machine was assembling a Windows release), and likely wouldn't work if we start cutting releases from gitea anyhow.

I've made a fix: https://code.wildfiregames.com/D5257.

I can't login at all. I get a "sign in prohibited" message.

Yeah, maybe they start off slower than they are now?