Leaderboard

Ya'll do a @#$% ton of work and barely get recognition from it, it's almost a crime. It impressed me while being on the dev IRC chat how many work you all are doing behind the scene, while still helping out noobs like me with small problems. I saw alot of tickets being made/solved/adjusted. So thanks devs for all the hard work so far and getting this next release ready.

Yes, I just realized how dumb I am. Yes; I will. I will do this soon; I want to finish this shader first, and then I will start removing all the hacks, settle on a new texture stack with hyperion or whoever, and partner with an artist to demo the new capabilities.

Tower-Scene - logs, trees and fence are from BlenderKit

Slightly late this week!

Greetings everyone, The new and hopefully final release candidate (RC) is here! Revision: rP24928 Windows: https://releases.wildfiregames.com/rc/0ad-0.0.24rc2-24928-alpha-win32.exe MacOS: https://releases.wildfiregames.com/rc/0ad-0.0.24rc2-24928-alpha-osx64.dmg All RCs are available here: https://releases.wildfiregames.com/rc. The one you want is 0ad-0.0.24rc2-24928-alpha-** PLEASE READ THIS BEFORE POSTING & TESTING The RC installer will overwrite the current installed version. The RC will use your current config including mods, so make sure to disable EVERYTHING (fgod, autociv, and badosu's mods are not supported) You might get warnings about hotkeys, we redesigned completely the system, so you might have to fix some of them (you may want to backup your config file if your intend to play A23B again It goes without saying but even though we are really close to a release, this is an experimental version. macOS 10.11 and below are no longer supported. windows XP and Vista are no longer supported. If you want to help more you can also perform those steps Launch a random game Launch a skirmish. Connect to the lobby Play on the lobby with someone Launch Atlas and try things out there Open Unit tests demo (To see if there any breakage in displaying entity's) (It's in scenarios) Try mods through modio only. (A23B MODS WILL NOT WORK) Enable feedback and see if it works (Main menu) Connect to and use mod.io Test replaying new games Test Screenshots (F2) Test Big Screenshots (Maj+F2) Test hotkeys Test Saving and loading a game. Test Quickload/Quicksave If you need any help ping me And of course you can play games with the RC.

There's WAAAY too many options and conditionals in the shaders; it is an incomprehensible rats' nest. I mean, if something does not need a normalmap, just give it one texel normalmap. If something doesn't need a specular texture, just give it a single black texel specular. What is the need to have compiler switches everywhere, gazillions of different shaders...?

That's what I was thinking. Can use the skybox for the experimental shader? Well, yeah, I think that's part of the pushback you are getting. While your screenshots may showcase an improvement here and there, overall it makes the game look bad so one will wonder if the "improvement" is worth it. To fully illustrate what you are attempting to accomplish, perhaps you could partner with an artist to make a couple buildings with all the proper mapping to take advantage of your new shaders, or import some pre-made artwork into the game to show what your shader can do for the engine.

What about the skybox ?

Can we have the female SWAT team as an easter egg? 100 melee dmg, 50% pierce/crush/hack armor :`-)

Well, it's harder than an auto-installer, but it is not that difficult. I think if you give it a decent shot you'll find that it works pretty well with the auto build. And yes, I do see that it could give more instant feedback. But it also means that any failed experiment impacts players. I'm not sure the tradeoff is worth it right now. BTW, for the curious, there were previous experiments with metallic shaders: https://wildfiregames.com/forum/topic/19650-engine-questions/page/6/?tab=comments#comment-304957

Hmmm.. I'm not sure about that. With regard to meta changes, I think it stabilizes pretty fast and is actually safer to do it this way since you have a constant stream of feedback (which might be invaluable early on). That said, you are the guys on the frontlines and you know what makes sense for the team. And as always, thank you for the huge effort, 0ad rocks

I need to ask ricotz, but it's very likely it will come at the same time with the release.

https://github.com/Balanced-Annihilation-Reloaded The issue is binary patching archives I suppose we don't even need to version anything. I really liked the idea of an autoupdater. Not sure how the official maintainers would look at it, since it could be a security concern.

Bar has an autoupdater that does it on every new commit, it's pretty great for alpha development. I think having an 'alpha' lobby together with an autoupdater would do wonders for the dev-feedback cycle, does not even need to be per commit, nightly or weekly would suffice. Could keep the 'stable' one and balance the load to whichever players prefer the most. I think the result could be surprising and exciting :-).

Thanks for the suggestion! This is something I'd like to see too; there are already some existing concessions for off-screen sounds, but they're pretty limited (essentially just, things that sound in the ~200px to the horizontal sides of the screen get played a little quieter). The sound engine we're using is extremely limited: no reverb, no filters, no equalization, no effects of any kind, so everything would need to be done with sound groups and some hackery. All we can do is pretty much play sounds at different volumes and pitches (speeds), at a particular spot on the screen. So, to implement off-screen cues like this we'd need to add a new set of sounds with the reverb et al baked in and code something to determine if a sound is on or off the screen and play the right variant. This is a recipe for a lot of work (and duplicated assets), but we might be able to find a way with maybe just a generic distant battle sound. Our main focus presently is on cleaning up and standardizing the sound assets and their definitions; more or less 'triage' medicine. Most of the sound stuff specifically is from over 9 years ago and the people who did most of it have long left the project I believe, so it's more archaeology than sound design some days. This stuff was coded and designed when I was still scoring Flash games for a living! XD Once the cleanup work is done (I'm hoping for A25), we can start to actually implement new ideas or tweaks.

Once again it wasn't rejected. I emitted a concern with the amount of work it requires. I'd actually would like to have @vladislavbelov's opinion on it as he probably has plans to change some things about materials too and maybe there is some common ground to be found. I'm gonna emit a lot of concerns because I have been there a while and I've seen a lot of projects left alone. When I commit to something this big I like to have other team members back me up. Because at the end of the day I might be the one doing it instead of something else. Having a new material to migrate to sounds good for a smoother transition. Also I wonder (because I've been too busy to test) how your shader works for objectcolor.xml, basic_glow basic_spec basic_trans_wind etc

More like x50-x1000, truthfully. In terms of "Full Time Equivalent", I would wager 0 A.D. averages under one FTE/day. Forgotten Empires, the makers of Age2, are 51 people at the moment. I'd wager the team making Age 4 is even larger. The gap isn't large, the gap is huge. Two decades, in fact

Just a few thoughts (been following this conversation with interest!)- The modern, end-user-friendly solution for something like you're describing might a game install/update service like Steam or GOG Galaxy. There are many work-in-progress commercial games (M&B II: Bannerlord comes to mind) which pursue a highly-active (near daily) update schedule on such services for their Beta branch, while preserving a monthly 'Main' branch for players seeking a less buggy and more consistent experience; both separate from their internal development branches of course. Granted, we're talking about projects made by teams 5-10x larger than the active dev team on 0 A.D., who are also full-time paid employees of a company, but I digress. In my experience making music software, a not-insignificant number of (non-Linux) users struggle even to do basic things like copy/paste or renaming files. I once sought a simpler solution for sharing FOSS musical sample library projects while in development and even went so far as to advocate the mediocre but relatively simple GUI-based Github Desktop app; yet still the vast majority just preferred to download the .zip from the mirror despite my best efforts and tutorials... so, personal rule of thumb, if setting something up is any harder than 'download thing and click a button', it's not going to fly for many if not most end-users. Even proper GUI-based installers can be problematic for many, especially if they click too quickly through and do not read the steps. I like your suggestion of separating the repos for art and such out. Already many of the original raw game sound effect assets are completely lost to time, so we're stuck with either replacing them outright or working from lossy file formats. Now we mostly do sound development over on a separate Git which functions as a Mod for the game, so a small group of us can iterate quickly on a few ideas (and share them with others) before committing anything to the game itself. Returning to the topic at hand, I think what you are doing looks great so far, especially if combined with the aforementioned new textures. I think the proper solution here would be to fully implement texture maps/keys for metallic as you suggested earlier, rather than trying to auto-detect. That'd probably take an enormous effort, but it is the sort of thing which needs to be done honestly. In the sound department, for A24 we mostly just tried to patch problems up with 'meatball surgery', but for A25 we're already at work on deeper, more fundamental changes to make the sound assets and their implementation consistent and "correct". Keep in mind 0 AD has been in development for well over a decade. There are brilliant, clever implementations of things, and sloppy messy hacks right next to each other in every corner of the game. New features and changes are not checked by a singular Producer or Director, but by the team as a whole- an experience which can seem at times like an inquisition, when the actual intention is to ensure there are no weaknesses in the proposal and that it will provide a suitable foundation for future development. The deeper the change, the more things are at risk, and as a result the game tends to move more slowly the deeper you want to go. It is easy for me to replace a few bad or poorly made sound effects from a decade ago, but when we get into stuff like changing (or fixing!) the way the sound engine works, it takes a lot more planning and discussion to make sure things work and what we leave behind will be workable for many years to come. In my opinion: Having said that, it also means it is fundamentally necessary that any code changes really need to be done the "right" way. Layers of hacks upon hacks is what has caused numerous issues on the project, so I believe it's essential whatever is decided must be done fully and in such a way that it doesn't impede future work. This means in a perfect world, changes shouldn't compensate for, override, assume, or guess about assets or previous work because that creates a feedback cycle of spaghetti going back into spaghetti. Ideally every change should be at the root of the issue, not treating or concealing the symptoms. If I understand your proposal and the architectures involved correctly, that means implementing this requires fixing textures so they give you explicit information on what is metallic, and integrating that in the workflow so all textures present and future have that.

Some are compatible, some aren't (e.g. you might get away with the same binary on Kubuntu Lubuntu Ubuntu and Linux mint, but it won't work on Fedora) Having scripts to download binaries is the goal of this ticket https://trac.wildfiregames.com/ticket/1814 (It's only for windows for now) Yep https://trac.wildfiregames.com/ticket/5366 https://trac.wildfiregames.com/browser/art_source

We have too many distros on Linux/BSD to provide binaries Ubuntu, Debian, Gentoo, Arch Linux, Mageia, Haiku, FreeBSD,OpenBSD, NetBSD to just name a few. In December 2018 we released, and things seemed to get back to normal. However most of the team was weared down because of the GDPR compliance the long time without commit, and the rushed re-release due to segfaults. Then, people also got very busy with life, leaving only a handful of developpers, most of which could not tackle the challenges at the time, either by lack of knowledge, time, or both. Time passed by with little activity on the programming side, while the art part got a lot of changes. At each big holidays we were waiting for someone to finally get the time to tackle the spidermonkey upgrade, which was the big roadblock, along with macOS issues (hidpi, sdl2 etc) and the occasional library upgrade e.g. NVTT and each time, he either ran out of time, or had to tackle other problems and could not deliver. this went on for at least a year. In July last year, I burnt out. I had a big breakdown and left 0 A.D. for almost a month. After this sad episode, I decided that I wanted to give it one last shot, or let the game die on its own. So I took even more things on my shoulders than I ever did before, trying to micromanage everyone, get people in touch, fix some issues on my own, talk to maintainers, get help from other projects, look for new contributors. and generally try to move the project forward, even though forward was as blurry as "get a release done". Around september wraitii got back and the heavy task of finishing spidermonkey was given to him. In December he was almost done, and since that made a release possible, all the energy was shifted towards fixing the game breaking bugs, and releasing. I think we're at the end of the tunnel here.

Well, here's a solution I found decades ago, and haven't seen anyone else implement. Back then I was lead developer of a remake of a game of flying in space, trading and fighting off pirates, and it was running on the Vegastrike engine. I was the main programmer, the main shader programmer, AND the main artist (2D AND 3D); though I did get a bit of help now and then. And I HATED releasing, like everybody else; plus, it took a huge amount of bandwidth... My game was 900 megs, which in those days was huge, and we had a lot of players; and I was paying for my own dedicated server, and bandwidth was limited (luckily never exceeded it). But so I wondered: why not put the game, as it installs, on SVN? That way, all our gamers have to do to get the latest is svn up. Mac and Windows users had to do a few extra things, as the installation in SVN was the more typical Linux install. I got a lot of bitter complaining initially (they hated having to install Tortoise), and a lot of resistance from colleagues, but once people tasted the honey of being able to update their game every day, they loved it, and never complained again. So I had 3 SVN repos: The Art repository. The Code repository. and The Installation repository.

Some more eyecandy ... also all handmade

Developer 1: "What advantage do we give the Persians?" Dev 2: "Stable buildings!" (weak joke)

There should be a button/text that says Reveal hidden contents, click that and you will be able to see the image. If not something is going wrong

@DanW58 My friend, let me see the latest progress in your graphic production.