All Activity

The best fix to the problem of some players using mods against players not using mods, is to make the mods currently enabled visible to everyone when a player joins the match lobby, perhaps as part of the “username joined” message. Then the host of the match can ask the new player to disable said mods. Additionaly, the ability for the host to ban certain mods, or ban mods altogether, or only allow certain mods, might be useful (of course this would take having a list of every possible mod, or at least knowing the name of the few mods you allow). Finally, maybe players can only join a match if they have the same mods as the host and as every other player, though I know that this already kind of exists, and has caused @Emacz some trouble.

I wonder if people who use this Counter-Strike mod also come up with those familiar excuses? "Okay, but this is available on the internet and open to everyone. That means it’s not cheating. Go download it yourself." "A lot of other people use it too. Why are you criticizing me? That means you have a personal problem with me." "Aiming is repetitive and unnecessary anyway. I’m actually improving the game. I help new players get used to the game faster." "This isn’t a cheat, it’s a mod." "You can aim with a mouse too, there’s not much difference. In fact, the other day someone killed me just by aiming normally with a mouse."

I disagree completely with this. Techs are very imprortant to the game, and imo they should be cheaper so they can be researched earlier in the game, when they actually matter. Also, quickly clicking on a tech to queue it does not in any way slow down my economy and training, since most of the time you can just sit back and wait for units to be trained (and using rally points makes this even easier). The game should have lots more techs, or at least every civ should have unique techs rather than renamed versions of the same tech. This would go a long way in making each civ feel unique btw.

Same. Occasionally I’ll just disable the ai so I can build a perfectly defended city, who the gardens and monuments, and then switch to to the enemy player and do the same.

@user1 Hello, Player Sol_Hunter left a rated match after realizing he was losing. Before leaving, he also falsely accused me of cheating too, which is completely untrue. I have attached the replay for your review. After he ragequit, I located his last two hidden soldiers in the corner of the map. Although the game awarded me the victory, the rating points were not granted, presumably because he had already left the match. My lobby username: MelodyNelson Offender username: Sol_Hunter commands.txt metadata.json

My lobby name: Birkebeiner Offender lobby name: Elenore Quit a 1:1 rated game after 16 minutes without resigning, started hosting a new rated game right afterwards, refused to explain @user1 metadata.json commands.txt

@GufraMirtol Could you try to add the following line to your user.cfg (it lies here: /Users/{YOUR USERNAME}/Library/Application\ Support/0ad/config/): borderless.fullscreen = "false"

This is a small mod I made that creates a work elephant unit for the Kushite and Carthaginian civilizations, who can train it at the elephant stable. It's not meant to be historically accurate, but more for fun, as I like the idea of the ancient North African civilizations using elephants for work as well as war even if I'm not aware of any historical evidence for it. I will admit the building animation is a bit buggy, as the elephant's ears always bunch up during this animation. Only way I know this could be fixed is if the African elephant models had their own building animations instead of using that of the Asian elephant, but I am not yet at the stage where I am able to animate meshes for this game. african_work_elephant.zip

UPDATE 0.5.0: Added compatibility with game version 0.28

"The point of my posts is not to have a lot of techs, but to make things more historically accurate and interesting, so people that are attracted to that (which I think should be one of the magnets of the game) get more pleased and curious than when reading generic or anachronical names." This is what Classical Warfare AEA is trying to accomplish!

@Deicide4u Well, I'm not really adding techs, now for Spartans I'm mostly renaming and removing, and adding a very few to compensate, I think they'd even end with less techs than they have right now. I’m also kind of overshooting with ideas, so there’s somewhere to take from if needed. The point of my posts is not to have a lot of techs, but to make things more historically accurate and interesting, so people that are attracted to that (which I think should be one of the magnets of the game) get more pleased and curious than when reading generic or anachronical names. Regarding a “small number of generic techs and from there build upon each civ's strengths”, I agree in the sense that it would be too confusing to have tech trees that are too different between civs, but that’s not my intention. Hopefully when reviewing other civs the tech tree will converge to something common with a few differences, although many want to differentiate civs even more, to which I agree, as long as it's not confusing. On the other hand, maybe having a lot of techs could allow for civs to be played in a few different ways (and aiming at getting most techs would be a mistake, at least competitively), and also, under certain limits, would be good SP content (which I see as vital to grow the game).

I agree and disagree I think we need to choose technologies wisely, something I sometimes have a hard time doing with Classical Warfare AEA. But related to Techs being too expensive.... you can lower the cost to make them a little move viable and then it's a little more choose your own adventure/put a unique twist with your build.

@Thalatta The game doesn't need too many technologies. Only a small number of generic techs, and from there build upon each civ's strengths. Technologies give an illusion of choice, and often give bonuses that should've been there by default, or not at all. Examples are the two techs for towers for greater range and more default arrows. They are also too expensive to be viable during the period of the game when towers matter. The attention of the player needs to be elsewhere, on the training of troops and construction of production structures.

Don't think we do anything specific about it.

hmmm, they have worked every time I've used them. Ill have to double check again and see if something somehow got screwed up.

I had none so far, I was trying to generate some, but nothing happened when I clicked it

you should be able to create 5 of them.... where you trying to create more than that? There were only 5 ephors at any one time.

Ok, Thanks! I was playing Spartan, and I was trying to get this unit, but it wouldn't generate; nothing happened when I clicked it

We have already changed them a lot with Clasical Warfare, and will definitely read through this more and figure out which ones can be applied. May start with just sparta for the farms within x distance of cc, i do like that idea.

OS: macOS chip: M2 year: 2022 package_manager: homebrew version: 0.28 issues: none so far, the game runs smoothly. note: the lag issue that is usually present even in platform-native games is not present in 0 A.D., I am assuming it is due to how the Pyrogenesis engine handles mouse rendering? Message: I was so blown away by the game that I wanted to express my gratitude. Freaking awesome! 0 A.D. rocks!

Interesting... If I can help I'd be happy to

Hello GufraMirtol and welcome to the community! Thank you for sharing this bug report with us! This includes Issue #8875 you already opened on Gitea.

Thanks! Yep, that analytics are in progress (about 90% done)

@Stan`

Summary On macOS, 0 A.D. running in fullscreen does not suppress system hot corners. Moving the cursor into a screen corner during gameplay triggers the user's configured corner action (Mission Control, screensaver, lock screen, Launchpad, etc.), interrupting the game and sometimes causing it to lose focus or minimize. This is inconsistent with how most macOS fullscreen games behave and is reproducible on a clean install. Environment macOS [26.3.1 (a) (25D771280a)], Apple Silicon 0 A.D. 0.28.0 (official build, installed to /Applications/0 A.D..app) Any user profile with one or more hot corners configured in System Settings → Desktop & Dock → Hot Corners Steps to reproduce Configure a hot corner (e.g., top-right → Mission Control) in System Settings. Launch 0 A.D. and enter a match in fullscreen mode. Move the cursor to that corner during gameplay. Observed: the system hot corner action fires, overlaying or pulling focus away from the game. Expected: hot corners are suppressed while the game holds fullscreen focus, matching behavior of Blizzard, Valve, and Feral Interactive macOS titles. Root cause (analysis) From inspection of the SDL2-based windowing path used on macOS, fullscreen is implemented via a borderless NSWindowsized to the display (SDL_WINDOW_FULLSCREEN_DESKTOP semantics). This leaves the WindowServer fully in control of the display, so hot corner event taps continue to fire normally. No presentation options are set to inhibit them, and the display is not captured via Quartz Display Services. User-side workaround I'm currently using While a proper fix lands, I've written a launcher script that temporarily zeroes out the four com.apple.dock wvous-*-corner keys before open -W launching the app, and restores the original values via a trap ... EXIT handler when the game quits. It's wrapped in a minimal .app bundle so it sits in the Dock like a normal launcher. Sharing it here in case it helps other macOS users in the meantime: #!/bin/bash # play-0ad.sh — disable hot corners for the duration of a 0 A.D. session. APP="/Applications/0 A.D..app" TL=$(defaults read com.apple.dock wvous-tl-corner 2>/dev/null || echo 0) TR=$(defaults read com.apple.dock wvous-tr-corner 2>/dev/null || echo 0) BL=$(defaults read com.apple.dock wvous-bl-corner 2>/dev/null || echo 0) BR=$(defaults read com.apple.dock wvous-br-corner 2>/dev/null || echo 0) restore() { defaults write com.apple.dock wvous-tl-corner -int "$TL" defaults write com.apple.dock wvous-tr-corner -int "$TR" defaults write com.apple.dock wvous-bl-corner -int "$BL" defaults write com.apple.dock wvous-br-corner -int "$BR" killall Dock } trap restore EXIT INT TERM defaults write com.apple.dock wvous-tl-corner -int 0 defaults write com.apple.dock wvous-tr-corner -int 0 defaults write com.apple.dock wvous-bl-corner -int 0 defaults write com.apple.dock wvous-br-corner -int 0 killall Dock open -W "$APP" This works, but it's a global side effect (modifies user prefs and restarts the Dock) and obviously not something that belongs in end-user hands. It's a stopgap, not a solution. Proposed long-term fixes (in order of increasing invasiveness) Option 1 — NSApplication presentation options (recommended). On entering fullscreen, set: [NSApp setPresentationOptions: NSApplicationPresentationHideDock | NSApplicationPresentationHideMenuBar | NSApplicationPresentationDisableProcessSwitching | NSApplicationPresentationDisableHideApplication | NSApplicationPresentationDisableAppleMenu]; Restore the previous options on exit / windowed switch. The DisableProcessSwitching + HideDock combination suppresses hot corner activation of Mission Control, App Exposé, and Launchpad in practice, without giving up normal compositing or GL context behavior. This is the standard approach for macOS fullscreen games and the lowest-risk change. Would live in a small Objective-C++ shim under source/lib/sysdep/os/osx/ and be called from the fullscreen enter/exit path.