Leaderboard
Popular Content
Showing content with the highest reputation on 2023-04-20 in all areas
-
Hmm it might be nice, but I think only for unit behavior. It would be bad if I actually click all my archers to shoot 1 unit and some of my archers to shoot a different unit. Even so, I think the unit ai should be simple and predictable, so that player inputs are more responsible for optimizing fights. IMO dancing is really not a problem at the moment.2 points
-
Since the devs are busy with alpha 27, I thought I'd start work on alpha 28. Non exhaustive feature list, but feel free to suggest more, I will consider your opinions (no promises) 1. Name: Alpha 28 will start with B because a26 starts with 'z' and a27 with 'a' (loops back). The name that I have currently chosen is Brian Cohen (of Nazareth), who was a famous historical figure. 2. B for buff, so every feature will involve a buff in some way. 3. Slinger buff: Everyone has spears, swords and arrow, while slingers are literally throwing pieces of stone they found on the ground. No one will take them seriously. So now, they will have automatic rifles. 4. WFG Bot buff: He only has one line. He desperately needs some more. This update will introduce 100 dialogues for him. 5. Facts buff: facts need a buff. He is too underpowered, and everything around him is getting very overwhelming. 6. Shia LaBeouf: This will be a new unique unit. Whenever you are unsure, you can ask Shia and if he says, "Just do it!", you can go ahead without any worries. If you are unsure about my skills as a game developer. I can assure you that I am amongst the very best. I have won every game jam where I participated. Here is proof of my latest gamejam. This post is small since I've been busy. cheers, facts2 points
-
Would be nice to have some in-game musicians with aura to play drums or flute to motivate troops in formation. Shouts and yells during battles and wave high some flags .This will creates some war ambiance during battles.1 point
-
1 point
-
1 point
-
-¿Ustedes que opinan@Lopess , @wowgetoffyourcellphone , @Stan` , @Genava55?,¿ y de los edificios? Importantes líderes Tribales Tracios(Para la "IA"); Nombre Fecha Original 1.Olorus (siglo V a.c) Ὄλορος 2.Syrmios (siglo IV a.c) Σύρμος 3.Bergaios ( 400 – 350 a.c ) Βεργαῖος 4.Dromichaetes (300 - c. 280 a. c) Δρομιχαίτης 5.Diegylis (siglos III-II a.c) Διήγυλις 6.Zibelmios (siglo II a.c) Ζιβέλμιος 7.Mostis (130 a.c-90 a.c) Μόστις 8.Abrupolis (200 a.c -170 a.c ) Αβρουπόλις Importantes líderes del reino Odrisio (Para la "IA"); Nombre Fecha Original 1.Teres I (480 a. C.-450 a. C.) Τήρης 2.Esparádoco (450 a. C.-431 a. C.) Σπαράδοκος 3.Sitalces (431 a. C.-424 a. C.) Σιτάλκης 4.Seutes I (424 a. C.-410 a. C.) Σεύθης 5.Amádoco I (410 a. C.-390 a. C.) Ἀμάδοκος 6.Hebrizelmis (390 a. C.-384 a. C.) Ἑβροζέλμης 7.Cotis I (384 a. C.-358 a. C.) Κότυς 8.Cersobleptes (358 a. C.-341 a. C.) Κερσοβλέπτης (pongo el nombre en griego antiguo por quien sepa descifrarlo y poner su fonética) Lista de otros reyes odrisios Berisades (358 a. C.-352 a. C.)-------Bηρισάδης Cetriporis (352 a. C.-347 a. C.)------Κετρίπορις Amádoco II (358 a. C.-351 a. C.)----Ἀμάδοκος II Teres II (351 a. C.-342 a. C.)---------Τήρης II Seutes III (331 a. C.-300 a. C.)------Σεύθης III Cotis II (300 a. C.-280 a. C.)---------Κότυς II Raizdos (ca. 280 a. C.)---------------Ροίγος Cotis III (ca. 270 a. C.)---------------Κότυς III Rascuporis (240 a. C.-215 a. C.)----Ραισκούπορις Seutes IV (215 a. C.-190 a. C.)------Σεύθης IV Posibles unidades ; Héroes ;(3) (Reclutados en ;" Fortaleza") 1." Teres I ";-------------------------------------(Τήρης ) 2." Sitalces";-------------------------------------(Σιτάλκης) 3." Kotys I ";-------------------------------------(Κότυς) Disculpen las molestias*1 point
-
1 point
-
That's sounds like a generally good idea, but wouldn't people call that lag because their units do not obey them anymore? In most RPG games, units have circles, that define whether they are allowed to attack you. A bit like covalence rings, there can only be up to n enemies in each ring Battle Circle AI: Let Your Player Feel Like They're Fighting Lots of Enemies (tutsplus.com) @Freagarach added a notion of attackers in Resistance.js 0ad/binaries at master · 0ad/0ad (github.com) It's mostly used to notifiy people that their target is dead or that they are already attacking it, but I suppose it could be extended, to deny units attacking an oversolicited unit. Question is how many units per single, and whether one should take classes into account (10 archers, but no melee units attacking someone would be weird, wouldn't it)1 point
-
No, those were overwritten. I've only uploaded the files that weren't overwritten. I have neither upgraded the game nor ever installed mods. I only just started playing this week. Again, not super high priority, because there was such an easy and intuitive work around. But I thought I'd let you all know.1 point
-
1 point
-
Dunno, I think a "MaxAttackers" component would be nice for templates. Honestly seems silly that 100 archers would auto-fire at 1 dude instead of all the other dudes with swords and bows 1 meter behind that dude.1 point
-
I wanted to share some details about the migration of the lobby we did on Friday and what went problems we encountered while doing so. That'll take a bit to explain so I suggest grab a cup of tea and some cookies before you continue to read. The motivation for migrating the lobby to a new server was to get it into an up-to-date state and to improve its performance. The operating system on the previous server was already getting older and as it got manually updated over the past years, there was lots of stuff on the server, which wasn't really necessary for operating the lobby. Therefore, to start with a clean slate, we decided to set up a new server from scratch. Server in this case means a new virtual machine as part of the infrastructure Wildfire Games has available to host everything related to 0 A.D. Instead of manually configuring the new server, we wrote so called playbooks for a tool called Ansible, which are instructions written as code how to configure such a server. We did so to increase transparency and documentation what's running on the lobby server. Going forward instead of doing manual changes on the live lobby, changes are written in Ansible code and can be reviewed like any other code related to 0.A.D. as well. This also improves the ability to test changes in an isolated environment instead of having to use the live lobby for that, as the written Ansible code makes it easy to configure other computers the same way. With an additional tool called Vagrant, which allows easy creation of virtual machines running on your local computer, it's now easy to get a nearly identical copy of the official lobby running for testing purposes on your own computer. If you're interested in the details regarding that, please check out the git repository where we published all of that: https://github.com/0ad/lobby-infrastructure/. If you're interested in participating and improving the infrastructure behind the lobby, contributions are always welcome there as well. While having the configuration of the lobby available as Ansible playbooks means that configuring a new server is just a matter of running a single command and waiting a few minutes, that's only true for a new lobby without any existing state. State in this context means lobby accounts, ratings and certain logs we wanted to keep. As migrating the state takes additional time and care and because unexpected things might (and in fact did) happen during such a migration, we planned a quite long downtime of 4 hours. However, the actual migration only took roughly one hour and once everything looked good again we made the lobby available for all of you again. Unfortunately, that's when we and some of you started to notice some problems, which took us quite a while to debug and fix. Here is a list of the most critical and interesting problems we encountered: Games becoming invisible Once more and more of you joined the lobby after the migration, eager to play again, we quickly noticed that something wasn't right. Games would become invisible or wouldn't even show up in the first place. After searching for a while, we figured out that this was caused by rate-limiting of messages getting sent through the server. There is rate-limiting in place to avoid spamming of large amounts of messages. That means that each user can only send a certain amount of text per second. During the migration we made a mistake in the configuration and applied the same rate-limiting which applies to all players to the bot managing the games as well. While you don't see many written messages from WFGBot, it's actually a pretty busy bot and sends out a lot of messages which get processed by 0.A.D. to be able to show you the list of games. With WFGBot not being able anymore to send all messages it wanted to send, this meant the list of shown games would be outdated or even completely empty, because your instance of 0.A.D. wouldn't get up-to-date information of the available games. We didn't catch this problem in our testing prior to the migrating, as our test setup had too little volume in terms of online players and hosted games to trigger the rate-limiting. Fortunately the fix for this problem was easy and just required fixing the mistake in the configuration. Lots of stale and outdated games being shown With invisible games not being a problem anymore, the list of games constantly grew and quickly started to show games whose hosts had already left the lobby. That's no new problem, and you've probably seen such stale games in the past already. That happens when WFGBot doesn't get a notification when a player hosting a games leaves the lobby, as WFGBot then doesn't know that that player isn't hosting a games anymore. We don't know why that happens sometimes, but it does and when it does it leaves behind such stale games. To avoid this problem going forward we added a filter to only show hosted games whose host is still online, which fixes this problem. Windows users not able to join anymore with TLS-encrypted connections Another problem which became visible was that Windows users weren't able to join the lobby anymore if they had TLS-encrypted connections enabled in the settings (which is the default and a good idea to have set). To explain why that happened I have to back up a bit. Core of the lobby is a protocol called XMPP. At its core XMPP is an extensible chat protocol. When you connect to the lobby using 0.A.D., it'll establish an XMPP-connection to an XMPP-server running as part of the lobby. Such connections can be unencrypted or encrypted with TLS. TLS is the encryption protocol also used when you visit websites whose protocol is HTTPS, like your beloved https://play0ad.com/. TLS is available in multiple versions. For historical reasons 0.A.D. up to Alpha 26 on Windows only works with TLS v1.0, which is deprecated nowadays and usually already disabled by default. Connecting to the lobby with TLS-encrypted connections didn't work for Windows users right after the migration, because the lobby XMPP-server didn't offer TLS v1.0 anymore, but only more recent TLS versions. However, the configuration of the XMPP-server was fine. What we missed during the migration of the lobby was to enable TLS v1.0 in OpenSSL, the library the XMPP-server uses for all the heavy-duty TLS-related work. Interestingly, even if we hadn't missed that it wouldn't have worked, because the configuration for OpenSSL required slightly different parameters than before thanks to it being a newer OpenSSL version. Nevertheless, this problem should have been surfaced during testing before the migration, but didn't because we simply forgot to test with Windows. The fix was once again straight-forward and just involved setting the correct OpenSSL configuration after we figured out what exactly the culprit was there. Going forward we'd love to disable such old TLS versions, but we'll have to wait with that until all recent 0.A.D. versions support newer TLS versions as well. Some Linux users not able to anymore with TLS-encrypted connections With login for Windows users fixed, we received reports from some Linux users not being able to connect to the lobby with TLS-encrypted connection enabled. Figuring out what was causing this took us a while, as it did work for the majority of Linux users, but not for all of them. The culprit in this case were the TLS-versions supported by the XMPP-server again, but this time not an old version was missing, but a new version causing problems in certain cases. As part of the migration we enabled the most recent TLS version TLS v1.3. This usually works without having to change clients, because only clients supporting such a version will use it. The client which didn't work correctly was gloox, which is the XMPP-client library used by 0.A.D. We don't know yet why it doesn't work, but it apparently doesn't. The interesting piece is why that was so difficult to track down. Contrary to Windows it's common with Linux that application don't contain all of their dependencies, but rely on them being provided by the operating system in one way or the other. The version of gloox adding support for TLS v1.3 got released less than 4 weeks ago and Linux distributions usually don't include software which got just released a few weeks ago. That's why the majority of Linux users had no problem, as the version of gloox they were using didn't support TLS v1.3. The affected users were mainly users which did install 0.A.D. as Flatpak application, as the Flatpak app for 0.A.D. included such a new version of gloox. Our workaround for this problem was to disable support for TLS v1.3 again on the lobby server, as that makes gloox and therefore 0.A.D. happy again. That's of course just a workaround, as we'd like to be able to offer support for TLS v1.3 in future as well, but to enable it again, we have to figure out why it's currently not working with gloox and get that fixed first. Conclusion As you can see preparing and carrying out the migration of the lobby was quite some effort and not without challenges. While most of the problems which appeared during the migration could've been avoided, that's always easy to say in hindsight. I'm personally very satisfied with the result of the migration though, as it's a great base for further improvements and the performance of the lobby is even better than before as well.1 point
-
Issue: People use garrisoning to take off targetting off units. Example: Someone pushes with barracks using garrisons/ungarrisons from said barracks. That means that targetting of 30 units can be reset by garrisoning them in 3 barracks. Ungarrisoning instantly makes it possible to kill units that are capturing barracks. Suggestion: 4-6 second timer when unit is idle and vulnerable to dmg doing nothing while garrisoning. Alternative suggestion is all armor becomes 0 but unit can attack while garrisoning. Conversely, ungarrisoning units should not be instant.0 points