Leaderboard

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

Shader effects 0 vs shader effects 10. It's not really a beauty. 842 model tris in atlas, 421 in blender, hope that is not too many @Genava55 @Ultimate Aurelian Should I make a stone baba and steles from the deer stones culture or would that be ahistorical?

*sigh* Enough. Both of you. I'm locking this thread for a few hours, in order to force a time out. Kindly get some sleep, fresh air, (or whatever) and come back tomorrow. Please do not continue this via Private Messages or elsewhere, or you may face temporary bans. @SKAcz: I hope the responses you received in good faith proved helpful, and Welcome to the 0 A.D. Community.

@SKAcz The opinion of myself and plenty of other players is that while economy management tasks can be repetitive, they are an important part of the game. Namely that a player must decide where to allocate their attention when they are under pressure or applying pressure. The autoqueue we currently have is simple so that you still have to manage economy. Learning how to multitask well is a (probably the) key skillset in RTS games, and overly automating the economy would ruin that part. Also just be aware that its widely considered cheating to use progui in multiplayer.

Update on the encyclopedia GUI page: I was not happy with the code at all, it was written in a very "unconventional" (bad) way and not really integrated into 0ad's codebase. That's why I decided to basically rewrite everything. The various panels are now different classes (and have their own XML and JS files). Values are now (as usual with JavaScript) stored in properties and passed between them. The CivDropdown (as well as the related civData) is created and used from already implemented classes and functions. And countless more smaller improvements. All in all, I guess the code will be around 30% more efficient than before. But most importantly: the code is now much much more readable and usable, and no longer embarrassing to show. It might not seem like a big step to some, because essentially all I did was lift it to the expected standard, but it certainly is for me. Because I only had little experience I programmed the project in the wrong direction. Yes, everything worked just fine on the surface, but I eventually had to take my time to "fix" it. And that being done now means I can actually start designing and cleaning up the UI. Plus, because the code is now much better integrated into 0ad, I'm able to "intertwine" it with 0ad and make it feel less like a seperate entity. I, for example, already added a button to the structure tree, civilisation overview and the small unit/building/technology viewer page to open the respective encyclopaedia article. If you want to take a look at the code, I put it on a GitHub repo: https://github.com/indoptogopt/GUI-page-for-0ads-encyclopedia

WIP

Carthage 4: The Island of the Palace-builders After securing blessing at Kition, you continue to sail West, in search of new lands to settle. As supplies run low, you make a stop at Crete, the island of the palace-builders. You remember the lessons from childhood, about a great people who lived on the island, their palaces and wall paintings. All of that is history is gone though, Dorians from the North have been raiding the islands for centuries and there is little left of the palace-builders. You have dispatched two of your most loyal servants with a small contingent to secure food supplies. The hills nearby are inhabited by herders -- we must capture their corrals and secure a total of 650 animals for the journey ahead. To the West, lies a small Minoan settlement that we can trade with. Further to the North is a Dorrian city, well fortified and protected -- we must beware! We are likely to face attacks both on land and sea so build up your forces fast! News of our arrival has spread and we can expect a much larger Dorian army to arrive within 2 weeks time (~50 minutes game play) -- we must secure the animals by then! AI Settings: Dorians and Minoans should be set to Petra with a difficulty of your choice. All others should be Sandbox

DirectX vs Vulkan: Battle of the Modern Graphics APIs https://beebom.com/directx-vs-vulkan/ OpenGL vs Vulkan https://thatonegamedev.com/cpp/opengl-vs-vulkan/ Two interesting articles, this should really emphasizes the importance of the changes for A27.

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

Over the course of researching for the encyclopedia I've found and noted down a few cases of units or buildings, where (I think) a new native name in place of the current one would be more fitting and correct. Plus, if I remember correctly, @ShadowOfHassen did too, from his research. And, of course, everyone is free to share their suggestions here as well. My question is: Would it be possible to get them into the game? It would only require editing the "SpecificName" property in he designated XML template. My idea is to list all of my suggestions in this thread here, explain my thought process and cite the sources. And then submit the names, that people agree with / confirm, on phabricator. Is this wanted / welcomed? I only want to make the effort of extensive researching and laying out my reasoning if there's a good chance the names make it into the game. (Of course, only the ones that members of the wildfiregames team end up considering worth using). I really don't want to seem uppish or pushy because that's totally not how this is meant. I just don't want to dedicate myself to work that ultimately leads to no outcome. Hope you understand what I mean, Vantha

Adds a more advanced bot(based on PETRA) to the game. Settings are more noticeable after 15-20min of play. Focused on players with experience. Bot with the same bonuses for each difficulty level as the basic PETRA. At population limit(e.g. 300) it will hire units up to the ceiling. More technology and economy oriented at the start. More active in the Market. Builds more buildings to hire units. Possibility of limited recruitment of siege units: In the Civic Center added hiring of rams (limit 4 on the map) from the start of the game. Reduced resistance to Pierce. After building the Arsenal, the limit increases. bot_PETRA_Expert.zip

Yeah, @Vanthais pretty amazing. Even with the ui work he’s still writing articles. For me though the articles are not just educational but also entertainment . Learning is fun.

Wow, you've been busy. You went from not knowing where to start on GUI development in January to an integrated GUI in April. I'm guessing that you got some help along the way. It's great to see an encyclopedia being implemented in 0ad. It helps make the game educational instead of merely for entertainment.

What I would like is that autoqueue is not stopped if I run out of resources, it would be nice if it were just paused until resources are available. Same as with population limit, it just pauses production until population cap is available.

It's true, it is open source and I am not a dev. So it is easy for me to complain about the poor performance in team games, even though I myself cannot put in the work to fix it. Nevertheless, I have been asking myself recently: should I really be playing a game this laggy in 2024? Time out of one's day is lost in games where actual time is significantly longer (2x, for example) than game time. WAY more than the unit rebalances or new units, I look forward to performance improvements like Vulcan. I also heard a27 will bring a way for the host to check if a player is causing lag due too just having a slow computer. So the host can choose not let that player in 4v4 games for example. That is annoying. Probably what you are running into is the fact that a maximum of 200 units can be selected at a time. 2 things can help mitigate this now: Hold alt while dragging the mouse to select military units only. Holding alt + y while dragging the mouse to select will select NON-military units only. Or, Play games with a lower pop limit. A bit of self critique: Some of the performance issues can be mitigated by choosing different options. We DON'T HAVE to play 4v4 200 pop team games. I think 3v3 is pretty interesting, actually. We can play lower pop limit games (albeit this effects the defensive structure vs unit balance). Just because we have the freedom to choose grander options doesn't mean that it's the best choice.

Thought this might be helpful for those of you working on their first own linothorax.

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.

First message on the forum, to talk about a pay-to-win mobile game with a suspicious account name and a shutterstock profile picture?

There is now a ticket for that: #6918.

Quite clearly, your proposal would be interesting, logically it should work that way.

Temple of Hatra.

Two more articles: https://github.com/TheShadowOfHassen/0-ad-history-encyclopedia-mod/pull/141 Slingers and their role in in ancient warfare: And the weapon of a sling itself:

Interesting. I actually think, the Skiritai are actually one of the best (and most underestimated) units in 0ad, especially for new players. Not in terms of stats. But they are available as soon as reaching phase two, nearly twice as cheap as full champion units, and they can gather resources, champions can't. When reaching phase 2 at 100 pop, you can easily train 100 Skiritai before hitting the 300 pop cap, and that while sacrificing barely any booming speed. And the Skiritai are significantly stronger than basic citizen soldiers, especially spearman. 100 of them so early can give a huge advantage. Athenian marines on the other hand require a gymnasion to be built and then the tech to be researched, can only be trained at the gymnasion itself (while Skiritai can be at the barracks), and cannot gather resources or build anything. It's simply impossible to train them at the speed that you can Skiritai. Ive tried several times but never managed to take advantage of the fact that Athenian marines are available in phase 2 already, at least not without significant drops in booming efficiency. All in all, Skiritai can't compete with champions, but can replace your much weaker basic spearman in huge numbers, which can give you a bigger advantage than a few (but individually stronger) champion units.

PR for the companion cavalry (Hetairoi): https://github.com/TheShadowOfHassen/0-ad-history-encyclopedia-mod/pull/139

Two Macedonian soldiers https://github.com/TheShadowOfHassen/0-ad-history-encyclopedia-mod/pull/138 Hypaspists: Argyraspides:

Good idea. You're right. All of the followers except DerekO were spammers. All of the spammers except 1 were already banned. I banned the last one and removed all followers from this topic. I think this topic is attractive to them because it's in the "Announcements / News" section of the forum.

I don't care if you want to make me or any mods a bad reputation nubs. Now even when I talk about it only to reply to a player who actually describe the features in it the same 3 people feel the urge to intervene and make sure to anchor in all minds "imagine if you automate the entire game" or other silly and unrelated things. The topic you quote also start with masterclass of describing some features that have implementations in progui, while the few same people take the very same progui as a counter example. Add to it that the author admit never tried it, just like @chrstgtr, yet are the most vocal guys advocating against for reasons. I'm am guilty of [Whatever you want] idc f u. Autoqueue with the ability to resize the batch also will just kill the game, I agree with all your impressive logic. CheatedyCheat Atrik = cheat Here is your win flag, you'll sleep a bit happier now I hope.

Wow. You go far into the made up stuff. I remember well enough that after you banned me from your host, I asked 1-2 question to understand, then other one when banned from spec. So 2-3 questions to understand what are you up to is "playing the victim". Seriously you just want me to reply to your bs so that the topic become as tribal as possible right?

It wasn't factored into the original math that training a batch allows the next group of units to be trained sooner than 1x1.

Probably that come from over-simplified calculations. There are enough variables in this game that no formula could define the optimal number of units to train at a given time. But what's for sure is that in a lot of cases, if your goal is to get fastest population grow, consuming a maximum of available resources into training units is extremely often the best. Because of this, you can assume that a better autoqueue would try to always train with the biggest batch possible. I use this assumption in ResizeQueue mod. @Baelish @SKAcz If you want autoqueue to be able to adapt to resources and housing, well, I did a mod that do exactly that. I've just added some default configuration to ResizeQueue, so you don't need to checks options to make it work. Resize Queue repo : https://gitlab.com/4trik/resizequeue With this mod, autoqueue should: Resize the training batchs. (will not consume last 100wood, this is a setting you can change) Stop production when housed, or out of resources, and resume it when possible. Prevent autoqueue to consume resources for a building while player is placing it. (I hated when autoqueue made you fail to place a building, and sometimes you don't even realize it) I'll summit this mod for review for mod.io today. The mod progui also has a feature that does exactly the same with added graphical panels to: Control production settings (change for example how much wood not to consume (for advanced players in some cases you want to change it briefly to 0, or 200..) In addition of picking units to produce from a specific building panel, you have a global panel where you can select what units to train, it also make mixed production accurate so you can get the army composition you plan for.

Same. It's very annoying, especially for animals queue

This stone baba is from the Scythian period so no issue. The deer stone pillar is a bit older vut it is fine, it was still used by the Scythians even if they didn't build it. For the sake of diversity we can let it pass through.

I'd bake some subtle shadows into the texture at least, give the illusion of a little more detail. Also remember that the stele we see today are very weathered. In their prime, their details woukd be easier to see. I wonder if there is evidence of paint.

the game is better at lower pop imho.

What I think makes the Seleucid cavalry so interesting is that they were, unlike other Hellenistic kingdoms, forced by external enemies to develop a strong cavalry force. And this necessity aggravated even more after loosing (and becoming enemies with) some of their own important cavalry suppliers, regions like Parthia and Bactria. This even led to a tendency to neglect infantry which turned out fatal in some battles. In the above text, I was focusing on the composition of Seleucid cavalry. Its role and importance probably deserve its own text. You worded it pretty well, if you're fine with it, I'm gonna use the passages you wrote, I couldn't write it better.

I regenerated the repo and associated data (that broke some links, I can't do much except rewiping the databases and users, which I'll try to avoid doing too frequently). I'm going to stop changing/fixing bugs in the PoC for now, thanks for all the reports and testing. I am now going to focus on the Unix build environment and the setting up of CI/CD. Changelog: git repository: - used short hashes in messages (I didn't have to choose the length, git automatically chose 10 chars) - wrapped the content of commit messages to 72 chars, ignoring the first line - grouped metadata lines in commit messages as much as possible (my regexp detects "[...] by:" and "Differential Revision:" but not for instance Trac tickets:, I can't cover and test all cases) - handle phab: links and [Pp]hab: links to non-commits - added a Bugs herder team Imported issues: - updated label display (typography/color), removed activity labels - disabled time tracking - do not publish a Patch change if the new value is empty wiki documentation: - added notices to install git LFS - adapted contents to label improvement Cosmetics: - added link to docs.wildfiregames.com in top menu Future branch: - merged Stan's update to .gitignore In gitea 1.22 (currently RC, will upgrade when it's released): - command-line instructions to merge will be adapted to our merge strategies - username will be correctly used instead of real name in commit feeds (including the RSS consumed by the IRC bot) Didn't do: - rename TracUser, I really think it's important to be explicit about the fact content comes from Trac - keep the Trac registration date of users... because Trac doesn't record that at all (only the last activity date) - I cannot reproduce @hyperion problem with "issues created by me"

It would be cool to if when you click on a unit you can see how many other units they killed, possibly even "humans" and buildings and siege. I cant take full credit for the idea. JBC (in game name, not sure if same on forum) mentioned it in a chat. Not sure how hard/feasible this would be. But it would be helpful for people to learn what units are better suited for different type of situations. Thoughts?

I think best to have the option to have 2 versions of world population with one distributed per player and to have one distributed per team.

PR for two more articles:https://github.com/TheShadowOfHassen/0-ad-history-encyclopedia-mod/pull/134 Battle of Gaugamela (I wrote this one a long time ago, but forgot to submit it). It is good text in my opinion, but I'm unsure whether its length actually fits in the scope of the encyclopedia. Same for most other texts in the unused folder and some heroes. I am going to try harder to keep the texts shorter and leave out irrelevant details from now on. and cavalry warfare during the Hellenistic period (lengthwise much better): The UI work on the encyclopedia page has been on hold for the last weeks, but I will resume working on it this weekend or next week.

I think this is a great idea. Bigger houses should need less time for producing women. That would be fair for civ balance. Moreover, reducing women training time from houses would give an alternative way to boom. I would go as far as: - 25sec from small houses - 18sec from big houses - 12sec from apartment

I just did some combat demo huge testing on svn vs a26. Not using vulcan here because of screen tearing issues I reported earlier. a26 - 4 avg fps, lots of stutters. svn - 25 avg fps, no stutters. That's really great stuff to see, so well done @wraitii @vladislavbelov @phosit and more! I noticed that the bodies really make a difference as well, which is why @nani has an option to turn off the bodies in autociv. I wonder if it would be impactful at all to make the sinking animation for the bodies much more coarse, aka updating the dead soldier less frequently. Its not like the animation needs to be ultra smooth, since ppl don't pay much attention to it.

The technical issue is fairly well summed up by Sam James from Gentoo at https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 A rather good video by Theo discussing the human component of the exploit:

@Itms Glad to see progress was made and we might have an improved workflow in the not so distant future. Appreciated. I wonder if it would make sense to create a subforum for the git migration and keep this topic as a means for informing the community about the general progress. I already see me bringing up various issues which each might warrant a discussion. Putting them into separate threads would help keep some order at least and help avoid duplicate reports to some extent. Or maybe we simply should use trac?

The story is scary but thankfully it was not found in stable releases of Debian. Here the concerned versions: It’s known that XZ Utils versions 5.6.0 and 5.6.1 were included in the March builds of the following Linux distributions: Kali Linux, but, according to the official blog, only those that were available between March 26 and March 29 (the blog also contains instructions for checking for vulnerable versions of utilities); openSUSE Tumbleweed and openSUSE MicroOS, available from March 7 to March 28; Fedora 41, Fedora Rawhide, and Fedora Linux 40 beta; Debian (testing, unstable and experimental distributions only); Arch Linux – container images available from February 29 to March 29. However, the website archlinux.org states that, due to its implementation peculiarities, this attack vector won’t work in Arch Linux, but they still strongly recommend updating the system.

@ShadowOfHassen I guess its a multiplayer inside joke, but ill explain. Basically this player has been regularly playing for multiple years and only plays Mauryas. he's known for funny all-in rushes and playing maury but this was the first game ever playing another civ.

I don't really understand the trapezoid in the minimap. As you can see the marked rabbits are in the top half of my screen while their dots are in the lower half of the trapezoid. (Especially the wabbits can be hard to spot.)