smiley

I think the idea behind it was to fill it with terrain textures / decals instead and to allow to have some variety. Yellowish tiles in deserts, mossy ones or something in more lush biomes. Looks kinda weird without decals or textures, but I doubt that's what the author was intending. Random map base placement would fill in some city tile texture for the area, and constructing the building in-game would create a decal IIRC.

You do not need visual studio if you do not plan on changing any core engine code. The latest version is built and provided in the repository. The wiki seems to be right still. You need those exact versions for now afaik.

Most of the time, google gives better results with "site:widlfiregames.com"

Since the refactor mentioned above would take a while, and this feature seems simple enough and quite necessary, I have done the XMPP client changes, https://code.wildfiregames.com/P288. It needs an interface that can also handle a nicer way of prompting users to reconnect. Engine.LobbyChangePassword(newPassword); // Pass in the hashed string as done in registration code and update config

The build date seems to check out though. There seems to be some overwriting going on. Can you check if there any remnants of the old installation lying around in somewhere? An old mod or something perhaps.

Remote resources are always a risk and an attack vector. Its why the mod downloader doesn't display any images from modio. If this were to be implemented, it can only be done via in-game assets. For reference, here are some historical publicly reported vulnerabilities in libpng. https://www.cvedetails.com/vulnerability-list/vendor_id-7294/Libpng.html

Its somewhat out of our hands, but we can make the gratis notice more prominent from our side.

IIRC, 0 A.D cannot be legally released on steam as of now (Valve requires some copyright waivers that we cannot give due to the lack of a CLA). So they did do something wrong, and we should probably contact Valve as we have like 2 decades of contributors who have not agreed to said waivers.

To be fair, we have more old music than new ones so probability wise, it makes sense that you would get them more. And the tracks are decently long so not much turnover there unless combat music kicks in.

The effect is more pronounced in slower simulation rates because commands only take effect the next turn. In single player that is. Which might explain why single player is better in the original post. The delay is 4 turns in multiplayer which should be a second or so. tl:dr; Commands take effect 1 turn later in singleplayer, and 4 turns later in multiplayer.

Perhaps a brief tutorial on this thread is warranted for those unfamiliar with Github actions.

There is a ticket for it at https://trac.wildfiregames.com/ticket/5423, we should definitely have this eventually. Hopefully for A27.

The process is currently like this: NetClient sends a CChatMessage to the NetServer. NetServer broadcasts the CChatMessage to every connected NetClient. What you would need to do is add another message type CNetMuted, handle it and keep track in NetServer. An intermediate step would then come in between the two above steps where you would just drop all CChatMessage from muted NetClients. Its possible to translate the current kick/ban code to mute pretty straightforwardly as it should behave identically apart from what message types are ignored. Yes, your research is accurate. It cannot be done just by JS, needs some engine network changes.

This used to happen previously too. But it was a mystery as to how to reproduce it effectively. A mismatch between actual territory boundaries and drawn boundaries. I think there is a ticket for it, will have to search it up.

Also taking suggestions on how best to define biomes. Would biome definitions similar to how we define our templates be better? How much information should be natively supported. (As in you define them and it works, no script changes needed) Should the biome affect terrain generation? Rainy biomes could have larger rivers. Snowy ones might have frozen walkable lakes. How do you define something like that? It would be better if the target state is known before commiting to something.

It was more about people not showing up. Everyone agreed upon a time beforehand. There has been one tournament that actually was super successful (the very first one by Christmas). Ironically the tournament literally had no prizes beyond bragging rights, while tournaments offering actual cash never went anywhere. In my opinion, it's an enthusiasm thing.

Indeed. For SVN mods, seeing the actual changes is somewhat possible by diffing against the 0ad repo, but for older mods even that's not possible. By keeping the history in the mod repo, the diffs are easily visible and everybody has an easier time down the line.

The function call should not be in GetSimulationState. You could set a timer in cmpPlayer instead. Even better is using cmpResourceTrickle that all player entities already have. https://github.com/0ad-matters/no-gather/pull/6 Versioning suggestion to all modders. Separate out the import commit with the modded changes so seeing whats changed from the base game is easier.

It's fun if you can manage to attract the right crowd. Usually overly technical stuff are only interesting to other programmers. https://youtube.com/c/AndreasKling streams system development and has gained a respectable following. I recall finding the channel when it had like 100 subs from a Reddit post made on r/programming. Granted the project itself has been quite successful in attracting a big community (of 100% developers too as the only people who have even heard of a hobby OS are probably devs).

Cool to see the mod is still being maintained two decades later.

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.

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; };

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 mean players playing under a different identity than what other players know them as. We prevented duplicate accounts to ensure this won't happen. The rule against multiple accounts are there to so that players actually know who they are playing against. The rationale being that incomplete information presents an unfair advantage. You can replace the phrase "combat smurfing" with whatever offense you want and the statement still stands. The point was more about collection of personal information than combating smurfs. If you have been here for a few years, my personal stance on smurfing is no mystery. Bans are ineffective because people can create new accounts. And ultimately there is really no way to stop people from doing so. A certain character in the lobby was so persistent that banning entire subnets from a whole country was not enough. An unimaginable number of accounts were banned over the years and he's still here. Then again, it's not all or nothing I suppose. ----- The features you highlighted are not missing because we thought it was a bad idea. ----- I should probably not read this thread because I still believe that having social multiplayer is not worth the toxicity. It should have just been matchmaking.

The privilege of going through legal jargon is still up for grabs. I know enough about law to not pretend like I understand legal talk. The more complicated we make our service, the more complicated the surrounding laws also become. If you want to improve the terms to allow for processing emails, the following points need to be justified. Is Combating smurfs a legitimate need? (legitimate as in https://www.itgovernance.eu/blog/en/the-gdpr-legitimate-interest-what-is-it-and-when-does-it-apply) Is processing emails necessary to combat smurfs? Not infringe on end user freedoms and privacy, might not be necessary legally, but its part of FOSS ethos and that's where we get our developers and contributors from. I don't get this point. What difference does this have from just regular smurfing which is so frowned upon? And if users know the verified account, how does it help with avoiding targeting? Either the actual identity is known, or its not. No can do, we don't store plain text passwords. (Well, the process is super weird but the bottom line is that we can't know the password you type in.) This ought to be present. Many people are behind symmetrical NATs and therefore share the same IP. (Google claims ~8% of traffic has to be relayed via their own servers, which is only done if NAT hole punching fails I am assuming). ---- The protocols we use were made with minimum information in mind, which brings in these additional complexities when things actually need more information. And that was partly the reason why they were chosen in the first place. Even for something as simple as account age, we either have to extend our XMPP server or track the information by bots. And for that, I can only link https://github.com/0ad/lobby-bots as other people have done so numerous times.