Leaderboard

Please report any bugs you find here or on Github(preferably) and feedback is greatly appreciated! grapejuice_r12_a26.zipgrapejuice_r12_a26.pyromod

Hi all, I've made a new map that is actually a remake from a map in Red Alert 2: Yuri's revenge. I've played this map quite alot back then because it was definitely one of the harder maps to play out there. It felt as if the AI was extra aggressive on that map in Red Alert. I really like the layout because you can do pretty much any strategy you like with it. Anyway, here a quick comparison: This map will be included in my new mod that includes player position randomnization and makes sure that ridges cannot be abused by ships by unloading units over them. I've done my own take on the iber defense on the start of the game which can be seen in the screenshots below. Download my mod here New mod: Grapejuice - Game Modification - Wildfire Games Community Forums

Dear 0ad developers, I'm wondering whether it is possible to translate the scenario editor? Background: my children (4 and 8 years old) really love 0ad (as a world-building game, without fighting) Yesterday, I showed them the scenario editor, and they were very interested. Unfortunately, the scenario editor is in English (which my children don't speak). I briefly looked at the code, and it uses the wx widgets translation functions (e.g. menuBar->Append(menuMisc, _("&Misc hacks"));). However, the editor does not show up in German, even though German is reported as being translated 100% in https://www.transifex.com/wildfire-games/0ad/. Would you be willing to take patches to translate the scenario editor? If yes, I would also welcome pointers about the current translation system (I saw that the game uses tinygettext, but did not look at the scripts yet that capture the strings into po files), and how to extend it to cover the scenario editor. Thank you for making such a beautiful game! Thomas

Hi @DanW58 been awhile now lead at the vegastrike project see your still joined at the hip to Eiffel we have been cleaning the source tree so that it now compiles on current distros still no luck on OSX or Windows yet but working on it new group of coders Enjoy the Choice

Here is a complete guide to downloading 0AD Alpha 24 in Linux distributions made by my friend https://www.youtube.com/watch?v=-prK21m2XDI Then if you do not know how to set up Linux you can either search for a installation tutorial on YouTube or, alternatively, you can install it in VirtualBox. VirtualBox offers a virtual environment in which you can experiment with the software. Check out my friend's tutorial here: https://www.youtube.com/watch?v=gfvNtiak9yI You can download the Linux Mint ISO file from this website: https://linuxmint.com/edition.php?id=286 Linux is generally lighter on hardware than Windows, so you can expect more frame rates. The performance of the VirtualBox machine will definitely be much worse than in real life. But if it is already acceptable in VirtualBox, then you are definitely set for real life installations. The performance of a Linux system depends highly on the desktop environment you are using. The desktop environment provides the graphical user interface that you interact with. Some desktop environments are designed to look pretty with cool animations, but this will increase the hardware demand (e.g. Gnome). Other desktop environments look less appealing but saves up much processing (e.g. XFCE, LXDE) so you can use these processing power on your games. Most Linux distributions allow you to install multiple desktop environments and switch between them as you like. I would recommend you to choose Linux Mint with XFCE desktop as it is the lightest yet fully functional desktop. Different distributions also use different package managers (a bit like Apple Store or Microsoft Store). Linux Mint and any other Debian based distributions use apt. Manjaro and Arch derivatives use pacman. Fedora uses dnf. In terms of installing the game, I would recommend going to the terminal and type sudo apt install 0ad This is the command to install 0ad Alpha 23. For Alpha 24 please refer to the first video. Tell me if you would like to know what this command means; I can explain Linux in more detail if you want.

I think it looks gorgeous. Could be added to @coworotel' map pack and maybe improved with A24 new flora and A25 new textures

Still playable on my Surface 2 pro

(Nice to hear Vegastrike is still alive )

was hosting a game filled with 16 ppl (8+8) and then someone finally unpaused and then Gaia some how resigned? here is the game by the way

Just another video from some gameplay with Wraitii and Langbart.

You can also install it side by side to Windows, so you have a dual boot system. Btw the biggest boost is the used compiler. The Linux GCC creates a much better code than Micrsofts MSVC. On heavy graphics load I get fps increasements compared to Windows up to 30-50%.

That really fits! You are very likely to have to go save a Mauryan ally in a team game.

We have a name ! As many of you guessed, with no Hans for A24, Xšayaṛša was the pick. It is a transliteration of the original Old Persian name for Xerxes, with Xerxes I featuring in 0 A.D. I've locked the topic, please wait with eager anticipation for the A25 name suggestion thread, and it's going to be a doozy because Y is not a common letter Thanks all for your suggestions!

The PLA. Actually, it's hard to tell. All the movies from the first Century were black and white...

Ok, I will. No; I don't have Windows anymore; I quit cold turkey.

Hey, Loki! Nice to see you! Glad to hear. I worked really hard on it. Remember when the brothers went on vacation and I standardized the formatting and fixed the indentations? Even using a code formatter, that took about a whole month of full-time work; and when they came back from vacation I got treated like a pariah for one tiny mistake I made in one tiny line of code, a typo; which is when... Anyways, I hope you understand my bitterness... Glad to find a good old friend here. :-) EDIT: I'm "Chuck Starchaser", by the way; not sure if you know. Ah, I guess you do; you remembered my love of Eiffel.

I LOVE your code, guys. Never seen anything so clean and thorough and well organized (since last time I looked at MY code, of course ;-)). Also reading the Timing Pitfalls and Solutions document. I hit that wall before; just didn't know how thick it was. PRIVATE NOTE: The engine I worked with, before, was Vegastrike. If you've never looked at it, thank your favorite god and perform the appropriate sacrifices.

Fixed

1) You're experiencing texture caching. In the development version most textures are PNG's and must be converted to DDS (S3TC) DXT1-DXT5. We do it on the fly for convenience and to make it easier test changes (All the textures are hotloaded) 2) You can build farms But yeah hunting is a bit harder. Is there something planned @Nescio @Freagarach @wraitii (I mean other than the turrets patch where cavalry will be able to attack move)

well, houses providing more pop are bigger, so they cover larger area, though civs with smaller houses would have free space advantage

No, we're just single-threading really. The problem I was describing is that e.g. unit Motion can right now send messages to any other component, there's no "barriers". Essentially at the moment the only things we can really thread from the rest of the game are (NB: they are not threaded yet) - The range queries, which have their own data (but they need some clever thread pooling, starting a thread every time would be too slow) - the pathfinder, which also has its own data - AIs Yeah that's a know issue. The problem is that pathfinding is slow enough that fixing it properly was not really attainable in the past. Once the pathfinder is threaded, it'll probably be more doable. The visual field (LOS/Fog Of War) is computed per player, but AIs don't use it. The problem is that AIs are designed for threading, and that requires giving them their copy of the data, and we never got around to giving them their copy of LOS data. --- Most of the problems are known, but need a lot of rather substantial work usually. You're welcome to help

Alright, here you lost me completely; I've no idea what thread pools and local management are. Here I'm lost as well. Okay, this is my first gut feeling how I would organize threads: Kernel (a director thread using millisecond interrupts, manages simulation speed, quality, queues and thread balancing, static memory). Map, resources, updates, fog of war (singleton thread with clients, all memory allocated at game initialization). Owns path-finder lib. Unit iterator thread (visits all empires, groups and units at every sim step; calls AI client libraries, see below). Projectiles, spear tips and sword edges (perhaps a separate thread from the unit iterator, as these are smaller sim objects) User input, user interface (menus, etc), camera movement, positional sound (as in Starcraft, a request hint ;-) ), video synch. If necessary, depending on test results, I might split threads 3 and/or 4 into two threads, and assign new units to them always to the thread with lesser load, to keep the balance Client libraries to those threads would be: Unit and group "vision"(&hearing?)/awareness Path-finding Collision detection, accel/decel motion modifiers, for movement realism Empire AI, Group AI, Unit AI Client libraries would be pure, statatic-free functions, to avoid thread-safety issues. Such threads are only "modifiable" in the sense that units are born and die; groups are defined or undefined, etc.; but that's only a quantitative mod that may affect load balancing a bit... not much at all. If I'm understanding correctly, what you are doing, instead, is assigning groups of units to separate threads, all threads running the same code... Yes? A horizontal breakdown, rather than a vertical one. If so, I'd suggest a vertical approach, as a horizontal one has lots of problems. One of them you are aware of, namely that units die (if I'm understanding correctly), affecting load balance. But there are other problems with the horizontal approach: Each thread has essentially access to all of the memory, and so every thread suffers the same L1 data cache pollution as a single thread version. Additionally, if L2 cache is shared between cores, the L2 will be hotly contended. In a vertical approach, each thread has its own private, smaller memory and can read and write to swapping buffers like I described in the last post of previous page. Each thread is essentially running all of the code, ok for L2, but making L1 code cache utilization far less efficient than it could be. Not using thread pipelining and swap buffers between them, allows too much freedom, leading to confusion about previous vs current vs next unit state when threads are reading or modifying each other's data, as well as confusion in how to make class variables thread-safe. Horizontal or vertical, having threads is a way to exploit multiple cores, primarily; both approaches achieve division of labor. But the vertical approach achieves additional efficiencies by reducing the amount of code AND data each thread runs or accesses, using L1 cache more efficiently, reducing contentions for L2 cache, and enforcing a cleaner organization of the code. EDIT: Talking about path-finding, there's a "bug" in the game (I'd call it that) whereby wood cutters search for the "nearest" depot to deliver wood to, but where nearest means sqrt( dx^2 + dy^2 ), rather than the pathfinder-nearest. Sometimes they walk crazy distances to go to a depot across a wall or chasm before you notice and correct the situation. You might say it adds a challenge to the game, but the challenges that add to the game experience are those that seem logical and realistic. Nobody in the real world would be so dumb. EDIT2: I suggested a vertical threading approach when I was working on my own engine, back in 2000, but my partner insisted "that's not the way it's done!" After the project was dead, an article appeared in some magazine, about John Carmack (ID software, Doom) independently discovering the vertical approach was the way to go; and so I was right. I was also right about my suggestion in 2000 that time be treated as data; and that was another thing John discovered and wrote about in another article... EDIT3: Another problem with the game is that enemies are psychic. They clearly have chrystal balls through which they find out I'm building a CC anywhere in the vecinity of their territory, and by the time the building is 10% complete or so they come and attack with full force. Yet another game I have to Exit. Super-AI's are one thing, but psychic power really has no place in games ... unless the game is about psychic powers, or explicitly involves psychers, or unless it explicitly says "civilization Z is telepathic; beware!" (as was the case with the Elerians in MOO2). But this business of "knowing without seeing" is anti-immersive, unfair and abominable. Is visual field computed? Per unit or per group? Realistic or hacky? Are there hacks to get around visual field for some particular purpose? EDIT4: Actually, I just won a game, somehow.

Improved the Republican Roman heroes a little bit in DE: Replaced their old low quality "Imperial Attic" helmets with more appropriate helmets for the time period. Made infantry variants for all 3. Gave Marcellus a better body texture. EDIT: Romans really need new Parma shields.