Stan`

@rossenburg @Mentula @Atrik You have some experience with the GUI I recon it shouldn't be too hard to get the list of matches from the lobby and autojoin when a match is available? I suppose trusting the host is the biggest issue?

Reminds me I still have a patch to disable territory visibility. The AI still needs it iirc.

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 ?

Glad it helped, let me know if you wanna understand more of it.

Well you'd still arrive on gamesetup, have the host set up a match, and get the same issue? 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+)`

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

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.

Alright that's fair, maybe I underestimate the number of new players in the lobby. 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

Some of the ways to improve our art quality and performance have been written here https://trac.wildfiregames.com/wiki/TechnicalArtRequirements cc @wowgetoffyourcellphone @wackyserious @Alexandermb @LordGood

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.

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. @Langbart and @SciGuy42 did a great job porting a campaign to A27, hopefully will be available through mod.io 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.

My bad then.

IIRC in a A26/A27 there is an option to reduce the area that does the scrolling so I suppose if you set it to 0 it's disabled.

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.

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? How so? It will not create new players. 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. 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. 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.

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

That's what happens when 100% of the work is volunteer based.

Basically Vulkan should be more stable (aka, more stable framerate, less driver bugs) than OpenGL.

Around 300k per year for Windows and macOS. https://releases.wildfiregames.com/stats.php Sounds like an issue with your desktop manager. You can try to add borderless.fullscreen = false to your config file.

Sure. Keep in mind that most people are not tech friendly, so ideally you should provide it as a pyromod. See the relevant documentation here: https://trac.wildfiregames.com/#Formodders:

Yeah, the patch did that before, but it was split. the problem is that while you're in pause, the camera still moved.

Yeah you can restore the <history> tag in the identity components. It will then show up in the detailed view of the unit.

Flatpaks are not made by us, and they don't want experimental versions. So likely never. There is an appimage there https://github.com/0ad-matters/0ad-appimage/actions @andy5995 seems to be working on it (thanks again)

@Dizaka Can you test this version? https://releases.wildfiregames.com/rc/0ad-0.0.27.1-alpha-arm64-debug.dmg It's a special debug version, it will run really slow. You need to reenable tls, and upload the log if it still occurs.

@Mentula Do you have a stat that computes the number of hours you put in matches ? I wonder how hard it would be to integrate your stats in my replay database.