Vantha

@Henry852 It's working again now, by the way, so you can now open the link I sent.

Ok, I'll do and see if it still happens.

The template is at binaries/data/mods/public/art/terrains/biome-aegean-anatolian/aegean_grass_dirt_01.xml and the base (color) texture at binaries/data/mods/public/art/terrains/types/aegean_anatolia/grass_dirt_01.png

See https://gitea.wildfiregames.com/0ad/0ad/wiki/FAQ#what-shall-i-do-when-joining-multiplayer-matches-fails-with-an-error-message

Yes, the engine totally supports text inputs, but as I said on the game setup screen there is a lot of extra JS logic for each of the setting types (dropdown, checkbox, etc.) but there is no "GameSettingControl_____" class for text inputs here yet: https://gitea.wildfiregames.com/0ad/0ad/src/branch/main/binaries/data/mods/public/gui/gamesetup/Pages/GameSetupPage/GameSettings, so you'd probably have to add that first.

Making it a text input is definitely possible, but not straightforward, unfortunately. In the game settings code there are a lot of layers of abstraction, a lot of wrappers and super classes, to make adding new ones easy. Like the current dropdown. But there are no such classes for text inputs yet, since no game setting actually requires them. I suggest to try to make it a slider instead, this is easier since there are existing game setting controls that are sliders. See https://gitea.wildfiregames.com/0ad/0ad/commit/38eb999ff9d627ab319820a5fc77f332b100e32d

It happens to me every now and then too, and what I always do is press Alt+Enter twice, which disables and enables full screen again, for me that fixes it and is quicker than restarting the whole game.

I'm with @wowgetoffyourcellphone on this one. I find the current tooltips show way too much information. Along time ago I even locally made some mockups revamping them, but I'm afraid those have been lost to time. In fact, I thought about using bars to visualize numbers like attack damage and resource gathering speed, which is still an idea I like. It would be cool to work on this, but for me it's a matter of time, I have so many things I'd love to implement, but they take time and I can't work on too many things at once. I genuinely hope, though, that I'll get to it eventually and I'd also be happy to review PRs for it. @wowgetoffyourcellphone, same for your viewer mockup. https://gitea.wildfiregames.com/0ad/0ad/issues/6860 (I personally prefer icons, by the way, and it would also be nice to add an option to choose between reduced vs extended tooltips)

You can blame me This is actually not a mistake, it was a deliberare decision, which I was involved in. See the discussion in https://gitea.wildfiregames.com/0ad/0ad/pulls/8062 The idea was to make the civilians' names more interesting, to change them up a bit for some civs and add historical flavor; most of the lower-class civilians in the Han dynasty were indeed farmers, and after all, the unit is best at working on fields. I was aware at the time already that this idea was not without its flaws and that someone would bring it up eventually. But I still stand by the decision, I think it's a good opportunity to reflect and teach what kind of people actually formed the lower societal class in those civilisations; and for me personally, that outweighs the oddities. And if you really need one to pick on, then please the "Carthaginian Artisan"...

Using a VPN could also solve it for you. The two possible solutions would be - dedicated servers: https://gitea.wildfiregames.com/0ad/0ad/issues/3556 - support for IPv6: https://gitea.wildfiregames.com/0ad/0ad/issues/4301 both of which, yeah, aren't trivial to implement.

STUN is now always enabled. You can try enabling UPnP on your router or manually configuring a port forwarding. There are a bunch of guides on the internet about how to do so, how exactly depends on the model of your router. There's also a section in the FAQ about it: https://gitea.wildfiregames.com/0ad/0ad/wiki/FAQ#how-to-do-port-forwarding

I don't have much to add to what @Stan` and @ShadowOfHassen said. I do try to keep up with hot topics people are talking about here, but I can't always read everything. @seregadushka Since this is an open source project, the best/fastest way to get an idea into the game is by implementing it yourself. When people suggested for you to do it in a mod, it wasn't meant maliciously. It is not uncommon around here for people to test their ideas in a mod first and then to get them into the base game eventually. If you don't want take that path, however, that is completely fine; contributing directly from the start is also possible. See: https://gitea.wildfiregames.com/0ad/0ad/wiki/GettingStartedProgrammers https://gitea.wildfiregames.com/0ad/0ad/wiki/SubmittingPatches Keep in mind, though, that in any case, consensus has to be reached for a patch to be accepted and merged.

@Atrik I can relate to the points you mentioned, actually, because I felt a similar way when I first started contributing to this project. What I can tell you from my own experience, though, is that things tend to run smoother and quicker over time, as you would become a more regular contributor and also learn how things run and what to look out for in implementations. Of course, making mods will always be faster and allow for more creative freedom, this is an essential aspect of the opens source philosophy, so I completely understand if people want to take that path. I welcome anyone who wants, though, to also open a PR and try to get the changes into the game, I think with git now it's easier than ever. I always try to work on those PRs as soon as I can, but of course it can take some time, it's important to think long-term I believe. And I'll admit that it can be difficult for me to find the balance between making it easy for the contributor and ensuring the best possible code quality. @Atrik E.g., I'd love to eventually work on the wall snapping you implemented a while ago, if you feel like it.

Ok, maybe my statement was a bit biased. But still, other games usually count connection issues in rated matches as your fault too, no?

I haven't looked at the code yet, but I think we can detect the host closing the match on both sides and send the messages to the bot as usual, as elexis suggested. Or maybe just take note when the game server of the host suddenly disappears before receiving any messages. On the other hand, the case where the client leaves, and the host finishes (and wins) the match on his own is the tricky one. Adding "game start" messages as you suggested would allow us to know which players took part in the game. And if we additionally record clients leaving, we can tell when that situation occurs, and then just accept the game report that the host sends on its own (maybe except if the client was kicked). If we don't want to trust the host with it, we can still just automatically count it as a loss for the client, if he doesn't return within five minutes or so. Well, that could result in some lag, but they still shouldn't repeatedly lose connection entirely.