Jump to content

Stan`

0 A.D. Project Leader
  • Posts

    16.977
  • Joined

  • Last visited

  • Days Won

    522

Everything posted by Stan`

  1. borderless.fullscreen = false @real_tabasco_sauce do you have multiple instances of the game running or are you using another client to connect to the lobby? Cc @Dunedan
  2. You should not commit them. They are cache files generated by the engine, but it can lead to weird bugs if you have both the ones in your mod and the one in your cache. They will also be generated and packaged in your mod when you run the archive builder.
  3. Can you upload the savegame ?
  4. Merged the threads. I can't reproduce the problem. What OS are you on, which version of the game are you playing.
  5. There are some rules here: https://trac.wildfiregames.com/wiki/EnglishStyleGuide You can use the files from here https://trac.wildfiregames.com/changeset/19960
  6. Hello and welcome to the forums. I have moved you post to a more fitting section of the forums. Good luck with your project.
  7. 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.
  8. @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?
  9. Reminds me I still have a patch to disable territory visibility. The AI still needs it iirc.
  10. 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 ?
  11. Glad it helped, let me know if you wanna understand more of it.
  12. 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+)`
  13. 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
  14. 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.
  15. 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
  16. 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
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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.
×
×
  • Create New...