Jump to content

smiley

WFG Programming Team
  • Posts

    353
  • Joined

  • Days Won

    2

Posts posted by smiley

  1. 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.

  2. 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
    • Thanks 2
  3. 1 hour ago, alre said:

    or from this site.

    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

  4. 30 minutes ago, Gurken Khan said:

    There's also a noticeable delay between clicking and UI reaction. I only play single player on turtle speed, when I give an order like building a structure or producing units I always have to wait a moment to get the visual confirmation.

    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.

  5. The process is currently like this:

    1. NetClient sends a CChatMessage to the NetServer.
    2. 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.

    • Like 2
  6. 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.

    • Thanks 1
  7. 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.

  8. 1 hour ago, Stan` said:

    Regarding streaming development we talked a bit about it with @vladislavbelov and the issue was that it would be either too technical or too boring and we haven't found a way to make it interesting.

    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).

    • Like 2
  9. 7 hours ago, Dunedan said:

    but there are several Pyrogenesis related functions (like "ChangeGame" and "GetProfile") missing.

    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.

    7 hours ago, Dunedan said:

    AFAIK changing the password is only possible after authenticating.

    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.

    • Like 1
  10. 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;
    };
    • Like 3
  11. 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.

    • Like 2
  12. 1 hour ago, Norse_Harold said:

    , I assume that when you use the word "smurfing" you're talking about "duplicate accounts" instead of smurfing

    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.

    1 hour ago, Norse_Harold said:

    by making bans effective. Let's own the problem.

    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.

  13. 14 hours ago, Norse_Harold said:

    It means who has accepted the responsibility for this task?

    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.

    1. 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)
    2. Is processing emails necessary to combat smurfs?
    3. 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.
    14 hours ago, Norse_Harold said:

    Allow use of aliases in order to protect players from bullying or targeting, but require that the aliases are tied to a "verified" account in order to make rule enforcement effective.

    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.

    14 hours ago, Norse_Harold said:

    Regularly scan for weak passwords, and lock accounts with weak passwords. Ban them if there is no password reset capability.

    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.)

    14 hours ago, Norse_Harold said:

    Make account age public for all users to see.

    This ought to be present.

    14 hours ago, Norse_Harold said:

    Someone said that an IP can create 1 account per hour.

    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.

    • Like 1
×
×
  • Create New...