Leaderboard

Disclaimer: This would be a massive change of course, and not related to the topic, but perhaps interesting so posting. This is not needed to implement password change. Maybe, the whole client needs to be slightly cleaned up by encapsulating related things rather than having JS separately query every detail. This would result in an interface where the single source of truth about lobby entities now lie within the client and entities/gamedetails could directly be exposed to JS. This should drastically minimize the number of events too as nick changes, presence changes and game status changes could be automagically updated along with the exposed JS representation (Need to check if this could actually be a thing, but it should be. We do pretty much the same thing for param nodes.) The new interface could look somewhat like this I guess. class XMPPUser { private: std::string m_jid; std::string m_username; u16 m_rating; u16 m_gamesPlayed; u16 m_gamesWon; u16 m_gamesLost; }; class XMPPGame { private: std::string m_hostJID; std::map<std::string, std::string> m_gameData; }; class IXMPPClient2 { public: virtual IXMPPClient2::~IXMPPClient2() = default; // Allow unauthenticated virtual bool Login(const std::string& username, const std::string& password) = 0; virtual bool ChangePassword(const std::string& newPassword) = 0; // Requires being authenticated virtual void Logout() = 0; virtual bool Register(const std::string& username, const std::string& password) = 0; // Restrict clients to join only one MUC at a time. virtual bool JoinMUC(const std::string& room) = 0; virtual bool LeaveMUC() = 0; // Basic XMPP functions virtual bool SendMessage(const std::string& toUsername, const std::string& message) = 0; virtual bool SendMessageToMUC(const std::string& message) = 0; virtual bool SetNick(const std::string& nick) = 0; virtual bool SetPresence(const std::string& status) = 0; // Member info virtual const XMPPUser& GetUser(const std::string& username) const = 0; virtual const std::list<XMPPUser>& GetUsers() const = 0; // Pyrogenesis functions virtual const std::list<XMPPUser>& GetLeaderboard() const = 0; virtual bool RegisterGame(const XMPPGame&) = 0; virtual bool UnRegisterGame(const XMPPGame&) = 0; virtual bool ReportGame(const XMPPGame&) = 0; virtual const XMPPGame& GetGame(const std::string& hostUsername) const = 0; virtual const std::list<XMPPGame>& GetGames() const = 0; };

Up to now 0ad doesn't offer the ability for users to change their passwords for the multiplayer lobby. However, that'd be a great feature to have and has in fact been already a feature request for several years (https://trac.wildfiregames.com/ticket/2543). I had a quick look and believe this should be pretty straight forward to implement, as the server-side as well as the XMPP library used by 0ad already support that. So all left to implement it is to add some glue code to 0ad and build the UI for it. If you're interested in helping out and implementing this feature or have any questions, please reply to this post or send me a PM.

I made a new mod called no-gather (available for a26) Resources accumulate over time, women are champions, and on random maps players start with about 50 infantry.

I am thinking about starting a channel and commenting videos. However I think I will only be able to do it infrequently. What about a community account?

I already have it

@wowgetoffyourcellphone Here's the fix and a little history https://github.com/0ad-matters/community-maps-2/issues/47

Stack:

That should be pretty old bug. Magenta happens when you have XML for the terrain type, but not the DDS/PNG texture. It crashes when PMP refers to a not existing XML file for terrain IIRC.

Rome at War mod

This painting can provide a reference, the soldiers of the Han army use halberds and shields, and the soldiers who use pike.

I am envisioning exposing the XMPPGame object directly. The logic for sending the actual stanzas would then be a method on XMPPGame. For get profile, I absorbed the information into XMPPUser. GetUser would first lookup the xmpp user and then query the elo related data and construct the User object with all relevant information. GetProfile would no longer be needed as a separate method. Indeed. I missed it at first then hastily added it under the wrong comment before posting. Register() and ChangePassword() were swapped. Separating out these from the current monolothic client would allow to update the underlying mechanisms more easily. XMPPGame related methods only are subjected change if we switched from XPartaMuPP to PubSub events while the XMPPClient requires no changes. https://github.com/livvv2k/0ad/tree/xmpp_client, any work on this front would go here.

hi again yes i attached new logs. logs.rar

that's fine.

mm, I think I misunderstood @Darkcity's feature idea to be much more useful and precise than it seems he meant it to be. (I had visualized the following scenario: 50 units on woodline, barracks nearby, 1 click on bell for barracks, 10 nearest men are automatically selected to garrison into that barracks, letting all other units continue working.) This feature would be used by pro players in certain cases, but I don't think its quite so abusable. The main thing is that it would make it too easy to limit idle time while being harassed by cavalry. As for a bell mechanic more similar to the women-only one that we already have, I don't think it will be used.

Mesopotamia I Mesopotamia II

sugiero buscar en el anexo: https://es.wikipedia.org/wiki/Anexo:Animales_emblemáticos_de_cada_país cada animal no es emblemático solo por su belleza si no por lo común que solían ser. allí esta este por ejemplo. https://es.wikipedia.org/wiki/Xoloitzcuintle o el Manati https://es.wikipedia.org/wiki/Trichechus el Perezoso https://es.wikipedia.org/wiki/Folivora Aguila Arpia de panama https://es.wikipedia.org/wiki/Harpia_harpyja

I have a patch made last night, but the problem with how our XmppClient is setup means that it becomes very ugly. We can summarize three modes for it. Currently using two. * Registration. * Login and join MUC. * Login and don't join MUC. Join MUC implies joining the room and switching to the chat interface. Currently only the first two modes are used and is handled by passing in a boolean flag in the XmppClient constructor. This is already ugly as having to create the client object in two modes lead to cases where we cannot reuse the client to connect to the MUC upon registration and have to tear it down before remaking it. Adding the third state is extremely ugly as it involves making numerous other checks to cherry pick the needed behavior. If we go with the flag approach, it also means the mode can no longer be boolean but that's the least of our concerns. This is what I did last night by using an enum flag based thing instead. JOIN_MUC | REGISTERING. But it was just way too much of a mess. I think what we need to do is make XmppClient an actual singleton which isn't constructed based on the behavior we need. And than we can instead call xmppRegister, xmppLogin, xmppChangePassword etc rather than constructing three slight variations of it for each mode. This would still allow maintaining the current GUI to XmppClient interface untouched. I would try this next. The actual password change functionality via gloox is max 20 lines but it needs some refactor on how the XmppClient currently works.

I think having 2nd floor windows is probably a no for Suebian structures. A "yes" for Gothic structures. Prototypical Suebian structures: I think all Suebian buildings should have thatch roof and Gothic buildings can have shingles.

Nydam: https://de.wikipedia.org/wiki/Nydamboot https://www.facebook.com/LateRomanArbeia/posts/pfbid0ire8czowXTSzx9H88dnLsMd12o3sZk8oEAP4UCfd1wWwE1ht9a2dkA5t8e7aEPual Thorsberg: https://de.wikipedia.org/wiki/Thorsberger_Moor https://www.facebook.com/media/set/?vanity=matt.bunker.792&set=a.10156253670910706

the topology us a good contribution.

Yes, but since it specifies "melee" it only affects melee attacks. { "value": "Attack/Melee/Damage/Hack", "multiply": 1.2 }, { "value": "Attack/Melee/Damage/Pierce", "multiply": 1.2 }, { "value": "Attack/Melee/Damage/Crush", "multiply": 1.2 } Cyrus of Persia, for example, also has Attack/Ranged/Damage/..

Ironically, the skin tones of the westerns are the same (or relative) as those of Pompeii.

Buenos días o tardes ; -Estoy creando fauna maya, ya me dijeron que parecen un poco naranjas y veré como lo soluciono ,¿Tienen más sugerencias o críticas?. -Si saben de más animales de la región maya , por favor no duden en mostrarme los. Fauna Mundo maya,(total 12); Ciervo de Virginia Coatí; Jaguar(ya existía); Mapache; Margay; Mono araña; Mono aullador; Nutria mesoamericana; Ocelote; Pantera negra;(ya existía) Puma; Tamandúa; Yaguarundí; Disculpen las molestias*

A curious question, any further progress on implementation for core 0 AD?

At the very least, I think this should be the case for eco and building bonus heroes, like Pericles (Athenians), Xerxes (Persians), Britomaros (Gauls), and Ashoka the Great (Mauryans). It would tempt more people to make them. Well, maybe not Pericles so much, but...anyways. I don't understand why Ptols and Seleucids only should have this bonus in terms of balance.

Auras would be a good feature to use more Roman Eagle standards

I've often considered removing heroes and replacing them with officers, generals, and standard bearers, each with different auras. That was before I went all-in on the Hero RPG element in DE. They could still make an appearance if we got hard battalions. Imagine upgrading your battalions with officers and noisemakers (Carnyx for Celts, Aulos for Greeks, Cornus for Romans, etc.), giving benefits.

Alright, some progress was made. This is the version I'm considering for the next release. It is adaptive and compatible to small 1024 screens. The bottom menu is a bit crowded and I would like to maybe remove some of the stuff, but that is more a consideration of the base game.

Alright seems like some people like this draft, but unfortunately: This is not possible. the min resolution width of 1280 offers not enough space to put the wfg logo and the build / alpha name in the top menu. This would be possible when dropping support for everything under 1920, but that seems like a bad idea. So here are some alternative drafts: (Do note that those are fixed width menus -> so they don't stretch over the whole screen anymore)

Since there has been some mods made recently which change the territory dynamics: I thought this might also be something that could be used for more differentiation. So just to put the idea out somewhere: What if we would group the civs into different classes who have different ways to claim new territory? These classes could be based on their history ( or at least what most pepole know them for ). I was thinking of something like: the 'Imperial/ conqueror' civs - they get only one CC, but every building of them has a larger territory influence and they have buildings like the theatron. So they are constantly building outwards or are trying to capture the buildings of the enemy (possibly with a higher capture rate?) the 'governor' civs - they also only get one CC but can build build cheap military colonies / satrapys of some sort who give less territory compared to the starting CC the 'tribal' civs - multiple regular CC to represent the different tribes the 'nomad' civs (yet to come) - territory doesn't matter As you can see the only thing that would change are the imperial civs (and the nomads).

mockup:

The left and right seems a bit empty Note: this is fixed width, meaning that this would look different on all screen sizes. Bigger screens would have more empty space on both sides, while the min resolution has no empty space.

It seems to me that most people would agree with an experiment on a self-hosted gitlab instance. It seems mostly consensual to not store large binaries, including windows libs, in the repo (not the main repo anyways). I think it'd be great to start experimenting with the above setup. Steps I see: Having a script to copy the svn history over to git. I don't think this is vital to get 100% right for the experiment because we can still do the other steps. Creating scripts to handle binaries automatically, at the very least on Windows. Vital on windows, probably good on other platforms too. This includes "storing them somewhere" Once removed, we can see how heavy the repo is, and the make a decision on LFS, IMO. Set up some CI/CD with this. The existing jenkins script will need to be reworked. That's already quite a bit of work. IMO we need this to work well Set up ticketing & issues & stuff like that. Test out the workflow. Have a script to download Phabricator metadata (issues, comments) & ideally port-them over to Gitlab. I would prefer to port 100% of the data, but not necessarily keep 100% of the "formatting". If the inline comments aren't inlined properly on gitlab, it's perhaps OK. Again, for experimenting this can be refined later. If the above steps all work, then we already have a mirror that works, and we can refine the steps for an actual migration. I can offer help with these steps.