Jump to content

Stan`

0 A.D. Project Leader
  • Posts

    17.026
  • Joined

  • Last visited

  • Days Won

    525

Posts posted by Stan`

  1. 1 hour ago, hyperion said:

    This is much better than the past no doubt, still you can't expect users to be able to fix their maps created in atlas this way. I'm not advocating to not make changes for functional reasons but cosmetic changes are hard to defend.

    I don't, that's why I spent countless hours fixing mods. I suppose just like feature creep, open source projects can suffer from technically correct nitpicking.
    But A24 was a terrible release in lots of ways, but mostly because of the amount of changes in it.

     

    • Like 1
  2. 6 minutes ago, alre said:

    Any automatic matchmaking should avoid matching players with strong differences in rating.

    Also, new players should be matched against new players when possible.

    By the way, there is a flaw, I believe, in the way the current rating algorithm computes the updates to the ratings of players losing or winning against new players. The fact that that player is new is not taken into consideration (compare this to how the new player rating receives stronger updates instead). The opponent to the new player should receive finer updates, because the new player true ability is not known.

    I suppose the issue is that every user has a default MMR of 1200 I believe @Dunedan, @Norse_Harold correct me if I'm wrong.

    I'm just wondering how it would work when there are little player available, will it wait forever for someone in your ball park? So if you're like 1600, you won't get in queue unless someone 1550 -1650 is there ?

  3. 3 hours ago, real_tabasco_sauce said:

    Well for me, I would rather play a mystery opponent than browse 1v1s in the lobby, some of which might be playing on imbalanced or noncompetitive maps. I might worry about balance while this pressure is taken off in a matchmaking system.

     

    Well you'd still arrive on gamesetup, have the host set up a match, and get the same issue?

    3 hours ago, real_tabasco_sauce said:

    s for ratings, yes, some decisions would need to be made. I think smurfing wouldn't be any more problematic than it already is. In a matchmaking system, their rating would quickly climb to that of their original account. I think it would be good to reset rankings with the introduction of a system like this.

    Problem isn't so much them gaining too much points, is you losing a lot to a 1100 player when you are 1800 (while in reality they are 1800+)`

     

  4. 1 hour ago, hyperion said:

    That change was done manually and after tripping enough people someone wrote a script, it would have helped it it had been the other way around. Write a script, if the output is what is desired commit the result of the script.

    Well that's what we've been doing since then => https://code.wildfiregames.com/paste/

    And hopefully someday here => https://git.wildfiregames.com/wildfire-games/pyrogenesis-migration-scripts

    • Like 2
  5. 54 minutes ago, Gurken Khan said:

    @Stan` IIRC you once wrote that it's a matter of art which flag is shown on a building. Since I really think the owner's flag should be shown on all owned buildings - including captured ones - where would be a good point to introduce that into the process, so that mid-term we'd have that?

    Currently it's art controlled. See: https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/art/actors/structures/athenians/barracks.xml#L25

    23	  <group>
    24	    <variant name="ungarrisoned" frequency="1"/>
    25	    <variant name="garrisoned">
    26	      <props>
    27	        <prop actor="props/special/common/garrison_flag_hele.xml" attachpoint="garrisoned"/>
    28	      </props>
    29	    </variant>
    30	  </group>
    31	  <group>

    This group controls the flag that's being displayed (here it's hele for helenistic because all hele civs have the same flag). By default the variant ungarrisoned is selected because it has a frequency of 1 (the other is 0)

    This is controlled by this code: https://trac.wildfiregames.com/browser/ps/trunk/binaries/data/mods/public/simulation/components/GarrisonHolder.js#L374

    365	/**
    366	 * Updates the garrison flag depending whether something is garrisoned in the entity.
    367	 */
    368	GarrisonHolder.prototype.UpdateGarrisonFlag = function()
    369	{
    370	    let cmpVisual = Engine.QueryInterface(this.entity, IID_Visual);
    371	    if (!cmpVisual)
    372	        return;
    373	
    374	    cmpVisual.SetVariant("garrison", this.entities.length ? "garrisoned" : "ungarrisoned");
    375	};


    As you can see it's an on/off switch, either it's there or it's not. It forces the variant with frequency=0 to be shown.

    To change this one solution could be to add a lot of variants:

    23	  <group>
    24	    <variant name="ungarrisoned" frequency="1"/>
    25	    <variant name="garrisoned-hele">
    26	      <props>
    27	        <prop actor="props/special/common/garrison_flag_hele.xml" attachpoint="garrisoned"/>
    28	      </props>
    29	    </variant>
    30	    <variant name="garrisoned-spart">
    31	      <props>
    32	        <prop actor="props/special/common/garrison_flag_spart.xml" attachpoint="garrisoned"/>
    33	      </props>
    34	    </variant>
    35	  </group>
          ...
    36	  <group>

    And changing the code like so:

    365	/**
    366	 * Updates the garrison flag depending whether something is garrisoned in the entity.
    367	 */
    368	GarrisonHolder.prototype.UpdateGarrisonFlag = function()
    369	{
    370	    let cmpVisual = Engine.QueryInterface(this.entity, IID_Visual);
    371	    if (!cmpVisual)
    372	        return;
    373	    const cmpPlayerIdentity = QueryOwnerInterface(this.entity, IID_Identity);
    374	    cmpVisual.SetVariant("garrison", this.entities.length ? `garrisoned-${cmpPlayerIdentity.GetCiv()}` : "ungarrisoned");
    375	};

    The problem is it requires a lot of manual work, it's not really flexible, and once you have a new civ, you're good to update all actors one by one. (You could automate some of it, but still)

    Another solution would be to make the flag creation the responsibility of the code  like it's the case for rally points, which need to be sent over the network. But this has a performance cost, cause creating new entities through AddEntity ain't cheap. 

     

    • Like 1
    • Thanks 1
  6. 10 minutes ago, alre said:

    it's pretty much the same thing, because there's a lot of people trying out the game, but not as many that stick. I'm sure a single player campaign would also show in the players number.

    Alright that's fair, maybe I underestimate the number of new players in the lobby.

    4 minutes ago, real_tabasco_sauce said:

    Well it could increase the interest in multiplayer. There are plenty of players nowadays that expect some kind of quick matchmaking option to get right into gameplay. But this would be a drop in the bucket compared to the interest in single player. I think many single player users really like the art and graphics for city building.

    The main benefit would be to encourage multiplayer players to try competitive play more, and develop the competitive scene. Also, matchmaking is very streamable, so this could potentially contribute to viewing interest in 0ad.

    What I don't get is what is different with connecting to the lobby? Is it like you go get a coffee and now you're in a game and people are waiting for you to be ready?
    Also, I'm not sure how to solve the level/rank/mmr/elo issue. With the number of people doing rating fakery, wouldn't it be a cursed option? You're here waiting for a nice 1v1 and you fall against a smurf of some top level player

    Agreed with the streamable part, but is the performance good enough for it? And is streaming with all options off and atomic trees really something we want to show? Those are genuine questions

    • Like 1
  7. 3 minutes ago, hyperion said:

    Worst are the ones like stone -> rock, don't think @Freagarach is guilty of similar ones.

    Except that's not really part of the API. Also those are the easiest to update ^^ I'd take automating template changes every day over updating hyrule code after we changed some of the underlying javascript

    Changing techs from json to XML is a much bigger breaking change.

    • Like 1
  8. 1 hour ago, alre said:

    Considering how huge is the number of daily downloads, one could say you are doing right by keeping the game installer online and giving it visibility.

    I did not mean it as a dismissal. I meant that somehow players are playing single player and seem to be gaining something out of it.

    31 minutes ago, Feldfeld said:

    Imo what 0 A.D. is lacking most is a campaign, and second would be better performance.

    @Langbart and @SciGuy42 did a great job porting a campaign to A27, hopefully will be available through mod.io

    1 hour ago, alre said:

    Do you know "player retention"?

    Yes. But from what I read you seemed to mean that the player base would increase, rather than not decrease. Sorry if it wasn't what you meant.

  9. If you have multiple 0 A.D. install, you can put mods in binaries/data/mods instead of the shared location. This way you'll only have the mods there available. I'm not sure, but maybe the -writableRoot option changes the install location as well.

  10. Another thing I don't know how to advertise is the opportunity the engine has. You can stick to a version if you wanna play with A23b forever and don't need anything else you can and just make mods for that.

    Hyrule (even though it was not a voluntary choice) have managed to do that people download old versions to play their mods.

    You can even package the mod with the game!

    @Freagarach is a good example of a modder that wanted more and eventually added a ton of gameplay features (he's also responsible for some of the api breakage but shhhh). I wouldn't mind having more features borderline with the game but used by mods. 

     

    • Like 1
  11. 12 hours ago, LetswaveaBook said:

    1v1s lack a campaign or interesting AI for skirmishing mode. In this light, these two game modes shouldn't be a serious contender for 1v1 online matches. The developers need to ask what is it about the game that makes 1v1 online matches not much more popular/common than the currently are?

    I suppose the first one is a typo and mean solo playing? 

    We know that there are at least 10 times more player that play solo matches than multiplayer ones (1500 per day). And those are the ones that enabled feedback.

    So we're obviously doing something right, even though we're not sure what it is.

    I suppose competitive 1v1 is just missing the "balanced" maps?

    10 hours ago, alre said:

    automatic 1v1 matchmaking would very interesting I think. If implemented, it has the potential to significantly increase the player base.

    How so? It will not create new players. 

    10 hours ago, alre said:

    of course one has to remember that this general vision of 0ad as a game to be brought trough the phases of development until it's a beta and then something resembling a full game, is not actually shared by all the people that form the development team of the game, and it's usually given for granted somehow naively here in the forums.

    I think the issue here is that it's not that we don't want that, it's more than we don't have the resources for it.

    12 hours ago, hyperion said:

    0ad doesn't offer a stable API for modding at all.

     

    12 hours ago, Lion.Kanzen said:

    What should we do?

    Well what we do currently is offer as many scripts as possible to update mods.

    But at the same time mods benefit from the extended API as well.

    11 hours ago, Genava55 said:

    From what I understand, the biggest issues pending are related to the core of the code. Is there a list of the remaining jalons before Beta?

    Is there a list? Yes tickets have been flagged beta. Does that mean it's exhaustive? Not really because there are things we hadn't forseen that came in the way.

    https://trac.wildfiregames.com/query?status=assigned&status=new&status=reopened&keywords=~beta&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=22

    Looking at it some stuff is missing and some stuff shouldn't probably be there.

    • Like 1
  12. 2 minutes ago, causative said:

    I want to say I don't have an objection to using a fasces as a Roman symbol - I'm not one to censor history because it offends modern sensibilities. But, if there is to be a fasces, it had better be very clearly based on a real Roman fasces, and not based on the flag of the Italian fascists. For example, if it had two opposing long and skinny axe blades at the top (instead of a wide axe blade and a diamond-shaped spike), like the rusted Roman fasces above, that would be sufficient to identify it as a Roman one and not an Italian one.

    @wowgetoffyourcellphone said he would look into an alternative in the coming days.

    • Like 3
  13. 1 hour ago, ShadowOfHassen said:

    You honestly should build flathub, with all the improvements flathub's getting with monetizing and donations. Besides I don't know how many downloads you get on your website but 102,391 downloads on flathub is a lot.

     

    Around 300k per year for Windows and macOS.  https://releases.wildfiregames.com/stats.php

    1 hour ago, ShadowOfHassen said:

    I tried the app image real quick, switched the render to vulcan and, I can't even use the menus because the mouse is three buttons below the one that lights up with the "mouse over" tooltip.

    Sounds like an issue with your desktop manager. You can try to add borderless.fullscreen = false to your config file.

×
×
  • Create New...