All Activity

@NewWorldHero You've spurred me into action. I managed to install 0ad ver. 0.0.23.1 on Linux Mint Live 22.3 (still in beta). I figured there's no point in bothering with 22.2 since 22.3 will be released soon. 0ad is from Bullseye, and some dependencies are also from Bullseye, the rest from Mint – it works for now. If you're interested, post on the forum, but first read: https://wiki.debian.org/DontBreakDebian The whole thing – from start to finish. This also applies to other systems, including Mint. By installing 0.0.23.1, I turned Linux Mint into Frankenstein Mint, which, in my opinion, can only be done for fun or for testing purposes. Best regards

@NewWorldHero I understand what you're writing as follows: I have Linux Mint 22.2. Why don't you tell me where the *deb 0ad file is in version 0.0.23? Of course, that would be the simplest. But it's IMPOSSIBLE. 0ad ver. 0.0.23 (0.0.23b, Debian 0.0.23.1) was released in May (December) 2018. https://releases.wildfiregames.com/ Linux Mint 22.2 was released in August 2025. https://pub.linuxmint.io/stable/22.2/ Linux Mint 22.2 is based on Ubuntu 24.04 LTS, Noble Numbat, released in April 2024. https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions Six years passed between 2018 and 2024. Systems from 2024 no longer contain the package versions that 0ad 0.0.23 requires. Such old packages (boost, icu, and whatever else) cannot be installed on new systems. Therefore, it can't be done. The only thing left is to find an older distribution for which this version was available and install it on a USB flash drive as if it were a hard drive. Ubuntu 22.04 LTS Jammy includes 0ad already in version 0.0.25b https://packages.ubuntu.com/jammy/0ad I found such a distribution for you – Debian Bullseye 11.11, which, moreover, still has the repositories enabled. Speaking of which, the Bullseye repositories won't be disabled until 2026-08-31. https://wiki.debian.org/DebianReleases You'll easily be able to install both the system and 0ad 0.0.23.1 on a USB flash drive before the repositories are disabled. After installing, keep the USB flash drive in a drawer, and when you want to play, you take it out, start your PC, and play. When you decide that's enough, you turn off your PC, disconnect the flash drive, put it back in the drawer, and then start your Mint. And you can go on like this forever. Well, maybe not that long – until you replace your PC with one that Bullseye can't handle. Happy New Year!

I really wanted this feature of being able to capture ships, but how would one even go about implementing this? it would probably need drastic change in mechanics, and so much more. (oh yeah, cool historical balance: If this does get implemented, Kushites should get a bonus of capturing ships,due to Nastasen's historic victory against the egyptians that made him capture lots of ships)

Of course, one soldier on a fishing boat should not be able to capture a large warship. But 10 warriors on a merchant ship, capturing an empty ship (conditionally empty, i.e. without a garrison) with close contact - why not. If, of course, the boat can swim close and stay afloat for some time without being sunk. Very suddenly, one player's unprotected fleet (without a garrison) can be intercepted by an even weaker fleet (but with a large garrison) of another. In my opinion, this would be very interesting and generally corresponds to the historical outline, when ships were captured on board. Note: That’s why I wrote the idea about a two- or three-fold advantage of units in the garrison of a ship going on board, so that it would not be one soldier, but several. And of course, there must be technologies that improve boarding practices. For example, “grinding hooks on ropes”, which could significantly reduce the time required to capture a ship. And vice versa, the technology “high sides” and “military commandant” to reduce the possibility of boarding a ship (increases the time for interception) even if there is no garrison. And if there is a garrison on the ship, these technologies make it very difficult or almost impossible (as with towers). Moreover, “high sides” are only for wood. And the “military commandant” technology is only for metal. ..... But these are all dreams... dreams. However, maybe the developers will really like it and do it?

Once upon a time, the idea of capturing a ship was presented on the forum. https://wildfiregames.com/forum/topic/104332-naval-overhaul-alpha-27/ In my opinion, it is a great idea to provide the opportunity to capture an enemy ship. My development of this idea is very simple: Let's make this possible for the ship to be another ship with a garrison. For example: one ship that has no garrison (or fewer units) and another ship with a garrison (or two/three times more than the first) move very close to each other for a while, after which the ship becomes the possession of the player with a more powerful garrison. Much like taking over buildings. After capture, the first ship will receive part of the second ship's garrison. To do this, you don’t need to make animation, just add mechanics. Of course, it would be better to take into account the forces of the units located in the garrison, but only if it looked like hand-to-hand combat (without representing the battle itself, only capturing the line, as for buildings). And ships without a garrison could not be used for capture. Only for fights. Thus, the player can add units to the ship's garrison and go to capture another fleet. This will add dynamics and unpredictability to naval battles.

OK! Thank you guys. I'll investigate and let you know if I encounter any obstacles. Cheers.

In that python example they wrote a client with the endpoints IIRC You can run arbitrary JS with /evaluate and /step to make the simulation progress. Regarding saving the map itself I'm not sure you can do it one go might have to replay the map and save it after. You can load any map with that endpoint. If you're on Windows you might have some issues with python not going as fast as it can. Probably some issue with flushing.

No his point was that you could install an old debian to get it to run without compiling it. Same as running an old ubuntu.

Wildfire Games doesn't do packaging for distros, the distros package it on their own. That way they can package the dependencies and other things required for the game. In short, that is more of a Linux mint problem, not a Wildfiregames. However, they usually only provide up-to-date packages because that's what most people want. I honestly would recommend trying to port the scenarios. It may be difficult, but while installing v23 successfully might work, you'll be kicking the can down the road, and eventually you'll have to port it.

Wow. I most certainly appreciate all the work and responses in this post. Thank you. But I feel like Im back to square 1 (start) and dont know what I should try that will actually work. -The Debian Bullseye is just that isnt it? Using Bullseye to compile and try and get a working .deb that will work in Mint 22.2. But Mint (the cinnamon version I use) is Ubuntu. Why wouldnt you use a Live USB of 22.2 that is Ubuntu based? - I still dont get why I cant get Wildfire to merely state WHERE the original Ken Wood v23 is that was uploaded to the Mint repositories already in a complied .deb format. If I run these commands in the terminal it will install the latest v. 0AD only apt-get update apt-get install 0ad

I checked the python repo and it picked my interest. Particularly headless option you mentioned would be very useful. I have question regarding this cmd: pyrogenesis --rl-interface=0.0.0.0:6000 --autostart-nonvisual --mod=rl-scenarios --mod=public Is there any api documentation regarding how to communicate with this interface? I.e. what should you send to this port to execute some part of the game (assuming I understand this interface correctly, sorry I didn't have much time to examine python scripts in detail..). In my case what I needed would be to actually load given map remotely, and save this map after period of time.

Happy and prosperous new year to all of you!

My idea is to place each tip in one category of each, e.g. the siege tower tip in "Medium" & "Military". That way the number of tips per combination stays relatively small and will hopefully make it easier to find specific tips or browse in an area that you're interested in. An index for all tips would be nice to have indeed, and some basic search functionality too. But that'll be more work.

The de-facto standard these days is GLTF.

I( wonder then, if we were so inclined, what format would we go to then? Why is Collada dropped? Its XML formatting seems really handy.

All clear now? (it would be possible to run the game headlessly (with no rendering) and to force it to execute turns a quickly as it can)

Thank you Stan. All looks amazing. Still doing some minor fixes here and there but overall, very nice! Added some screenshots here https://www.danielnylander.se/2025/12/30/uppdatering-av-0-a-d/

While I'm here: luiskeys111 left the game while in a losing position last night. This was a bit after a 30 minute pause, as well. commands.txt

Apparently a repeat offender, jojolapra left the game instead of resigning as I was capturing buildings and demolishing them. commands.txt

Nope. Very interesting. This would be precisely what I'm looking for. Thank you.

Happy New year guys

Bonne année 2026!

Feliz ano novo a todos! Muita paz saúde e prosperidade!

@ffm2 I assume Arch has the latest Blender which deprecated (removed?) the DAE import and export because they no longer wanna support this. This means 0 A.D. is probably the last big open source project to use the Collada format. I haven't checked if the settings allows you to restore it; Doing a bit of 3D printing myself, NIFA is right, unless you get a way to get the normal map details from the textures, your models will look very bland, and they clearly are not meant for printing, because of their non manifold nature.

Have you seen -> https://gitea.wildfiregames.com/0ad/0ad/wiki/GettingStartedReinforcementLearning