Leaderboard

It was based off texts in the last test candidate of A27, we'll probably need to a bit of updating (I know @wowgetoffyourcellphone did some things to the ships), but once Vantha finishes the new UI we'll finish off the Hellenistic civs and get everything added to the game. I don't think we'll be able to finish all the encyclopedia, but we're almost half way done.

I'm kind of hoping that me and @Vanthacan sneak in the new encyclopedia UI and at least some of the new encyclopedia.

A mod designed to make the most of 0ad, with many battles with automatic weapons, maps on alien planets, ships and drones. I've had it for a while now but I intend to make it playable in alpha 27. It is only possible thanks to the beautiful animations created by @Alexandermb . I use a lot of AI generated images (https://www.imagine.art/). In addition to ideas and adaptations, especially in mods Delenda Est and Hyrule Conquest.

One of the most important sources of frustration for team game players (TG) is the amount of lag they experience in every game, especially in late game, when populations are bigger and battles involve larger armies. This post proposes two changes to the game: Adding an in-game player cpu lag indicator (similar to the in-game player network lag warning we already have) in order for players and hosts to be able to diagnose lag in their games when network problems are not the bottleneck (which is the case in most TGs nowadays). Sadly, right now, players are kept in the dark about the cause of lag in their TG games. Reverting 0AD simulation to use 2 turns per second (as it was the case in alpha 23) instead of 5 turns per second (as now) in order to increase the performance of the game up to 2.5 times compared to what we have now. As I am not a developer, please tell me if these ideas make sense to you and give me your feedback on the lag issue of 0AD. Lag complaints The complaints about 0AD lag fall into three categories: 1. Slow game The game lasts way longer than it should. It is not uncommon for a 4v4 TG of 25 minutes gametime to last 50 or 60 minutes of real time (just because of in-game lag and not accounting for pauses) and this overall sluggishness causes a lot of frustration. Players wonder: why should we be forced to play at 0.5x or 0.4x of the speed when the game setting was set at 1x? 2. Lag spikes During key moments of the game the lag spikes to ridiculous levels, especially in late game and in big battles, when the game can freeze for up to a few minutes until enough units have died. During these lag spikes all sense of movement is lost, and the battleground becomes a slideshow. 3. Frozen user interface (for slow cpu players) Players with slow CPUs experience an additional problem. Not only the units in the game run slower and come to a standstill in big battles, but the whole 0AD user interface freezes during lag spikes. While players with fast PCs can still experience a fluid user interface, for players with slower CPUs the simple act of writing a team chat message, moving the camera or selecting any entity on the game becomes almost impossible during strong lag spikes, and very difficult during moderate lag spikes. CPU lag vs Network lag Whenever a player has a ping above 400ms the game shows his name and his ping milliseconds on the top-right part of the screen, informing everyone that his connection is lagging. This type of lag is easy for everybody to understand and identify. What keeps most players confused is why can it be so much lag in a game when no lag warning is shown to them. This lag is caused by someones computer being too slow keep pace with the speed of the game and, as we know, the game will run at the speed of the slowest PC, which becomes the bottleneck in terms of game speed. In this post I will refer to "cpu lag" as the lag caused by computer performance bottlenecks as opposed to network bottlenecks. While the CPU lag will be affected by both the performance of someones computer CPU and GPU, the CPU aspect is almost always more problematic than the GPU aspect, as it will become clear below. A personal experience In the days of alpha 23 my PC was perfectly capable of playing regular 4v4 TGs. Sure, we got some late game lag and battle lag spikes back in the day, but my PC felt perfectly adequate for 0AD back then, and the experience was decent. Path finding big armies on forests or choke points like gates was a big problem but thankfully it was not that common to encounter (maybe it was really nasty in 1 out of 10 games). I stopped playing for a while, but when I came back to alpha 25 the lag spikes and overall feeling of the game had become horrendous in almost every late game 4v4 TG. Clearly my PC was now obsolete to play the new 0AD. I replaced the graphics card of my PC with a modern one, but the frame rate and responsiveness did not improve. A computer perfectly capable of running 'Red Death Redemption 2' at max settings and 60 fps was barely getting 1 fps in big battles in 0AD. Then I talked to several technically oriented players and the concensus about those who knew was that the CPU performance was the bottleneck in 0AD TGs. No matter how good your GPU is, if your CPU is old or slow (especially in single core performance) your experience will be horrible. Modern games like 'Red Death Redemption 2' need beefy GPUs but can work well on older CPUs by having more optimized code than 0AD and by making use of multiple cores of your CPU. 0AD is an old game that was designed before multicore CPUs were common. The simulation and the problem of turn rate While a slow GPU can cause low framerate, you can always lower the graphics settings to increase performance. But in the case of CPU lag there is nothing you can tweak, as 0AD requires a non negotiable amount of single core computing power every turn in order to update what is known as "the simulation". The simulation involves all the rules of the game and the inputs of the players in order to calculate what the next state of the game should be. Due to the way 0AD is designed, this is a linear process that can only be done by a single core of your computer. As I started talking to players that are also devs I came to the concept of "turn", a step which involves the calculations that take place in order to move the simulation forward. Back in the days of alpha 23 there would be 2 turns per second, which means that, for every second, the simulation would be updated twice. This involves taking into account the user inputs and applying the rules of the game to each and every unit and entity in the game in order to update them to the new state. Then, in alpha 24, the original rate of 2 turns per second was increased to 5 turns per second. Correct me if I am wrong, but this meant that alpha 24 became 2.5 times more demanding on that critical single core of your CPU. And since CPU lag is the most important cause of lag in large TGs then its pretty easy to deduce that this change might have been the single worst design change decision made in 0AD history in terms of making large TG games less enjoyable. What is the optimal turn rate How many turns should be calculated every second? What is the optimal amount? The first thing to notice is that you can input as many commands per second as you want in your game, irrespective of the number of turns per second. For example, suppose you want to snipe and you can click 5 times very quickly by pressing the shift key at the same time. Those 5 attack orders would all be queued and sent to the next turn. If you wanna cheat with an autoclick mouse you could send 30 clicks in one turn. 0AD will not complain. The number of actions you can input on a given amount of time is not limited by the turn rate. Another thing to keep in mind is that around 1 second will pass since you issue any command and your units start executing it. Apparently it works this way in order that every computer executes the commands issued by every player at the same time. So keep in mind that an unavoidable latency of 1 second for every command will be always present, again, irrespective of the number of turns per second. So, how many turns do we need per second? On the one hand we know that the more turns or calculations per second, the slower the game will run in late game TGs, which nobody wants. On the other hand, what is the advantage of increasing the turn rate in terms of gameplay, say from 2 to 5? As I see it, there is very little. Back in the days of a23 we could observe pretty good micro from top players, zigzagging their way out of javelins thrown at them, and let's not forget the nasty hero dances dodging all arrows that were so common back then. And all that was done apparently with 2 turns per second. Do we need to update units 5 times per second now? Let's remember that one second will pass anyway between any command issued and the unit acting on it. Moreover, lately the units cannot change direction instantly as before, because acceleration was added to their physics, so they became more sluggish in response. And alpha 23 with 500ms turns felt more responsive due to the lack of acceleration physics. In my opinion, the added lag caused by a higher turn rate defeats the purpose of the increased "snappiness" the developer probably intended, especially in large TGs. And the 1 second latency for every command limits the amount of perceived "snappiness" we will ever have in 0AD no matter how fast the turns are being tried to be calculated. Turn rate proposal The simplest option would be to revert to the tried and true 2 turns per second we had in alpha 23. This would probably decrease CPU lag by more than twofold. A better solution would be to allow the host of the game to select the turn rate he wants. Another solution would be to automatically adjust turnrates depending on the number of players, for example: 1v1 - 5 turns per second (like current alpha) 2v2 - 4 turns per second 3v3 - 3 turns per second 4v4 - 2 turns per second (like alpha 23) Or set the turn rate according to overall population cap. Or dynamically adjust the turn according to the slowest player cpu performance during the game. Early game it could have a fast turn rate and slowly turn it down as the game progresses. In any case, a hardcoded return to a turn rate of 2 would be a huge improvement in performance and probably a trivial change to implement. CPU lag warning Besides this, I want to propose that a cpu lag indicator or warning be added to 0AD. This warning should be similar to the network lag warning we already have. For example: zniper14 0.4x This would indicate that in the last minute the CPU of the player "zniper14" is only capable of running the game at 40% of the intended speed. In big lag spikes we will probably see numbers approaching 0.01x for some players. This number should be calculated by the amount of seconds (of real time) needed to compute all turns in the last 10 seconds (of game time), and divide that amount by 10. This is obviously an example and other ideas could be thought of.

@ShadowOfHassen@Vantha That would be marvellous, indeed - and another clear and visible improvement compared to A26.

Use as much pure white as you can for the texture

1. Download and install TortoiseSVN Dowlnoadpage https://tortoisesvn.net/downloads.html Standard setting during install will work After finishing installation create a new folder in your Userdirectory. It should be located in "C:\users\username" . I called my directory "0adsvn" Then right click on the new created directory and choose "SVN Checkout..." In the Checkout mask just enter the URL of repository: "http://svn.wildfiregames.com/public/ps/trunk" Then click on "OK" Now it starts downloading the 0ad SVN version. Depending on your Inet speed this will take 20-45 minutes and needs arround 1,5 -2GB free HardDisk Space After the checkout is complete, you can start the SVN game from the "pyrogenesis.exe" binary wich is located in your created folder under \binaries\system\ I created a shortcut for this and placed it on my desktop. Dont forget to updated your 0ad SVN copy every time you going to play in svn. This can easily be done by right click on your 0adsvn directory and choosing "SVN Update" Have fun

If you open any replay file (command.txt) you will find that the duration of each turn is stated on each line a new turn starts, like "turn 0 200". The 200 stands for 200 ms. In a23 you would see "turn 0 500". The example below comes from a multiplayer 4v4 tg on this alpha: turn 0 200 end hash b6f05acff08e123cde8c1c43ec19627c turn 1 200 end hash-quick 2c00bb0c9b7ad23bd7f74ea4a261fa82

Ok I found the problem, I feel soooo dumb The fact is that I was testing these particules on a map where is only one player, so the game consider that is a win and ask me if I want to go back to lobby or stay in the game. So it attributes the gaia color (grey), and not the player color, because i'm not a player. I tested the particules without the OnUpdate function in a normal map and it's working.

I’m not at home I will do it at near 4pm

hopefully we'll have more visibility in september, but no, no expected month.

Also note that using setvariable you could say change the intensity of the fire of the flying vehicles

Made a few more tests with this particle: <?xml version="1.0" encoding="utf-8"?> <particles> <texture>art/textures/particles/dust_256a.png</texture> <blend mode="over"/> <constant name="emissionrate" value="1000.0"/> <constant name="lifetime" value="10.0"/> <uniform name="angle" min="-3.14" max="3.14"/> <uniform name="velocity.x" min="-1.5" max="1.0"/> <uniform name="velocity.y" min="2.0" max="3.5"/> <uniform name="velocity.z" min="-1.5" max="1.0"/> <uniform name="velocity.angle" min="-2.0" max="3.0"/> <uniform name="size" min="7.4" max="7.5"/> <expr name="color.r" from="colorr" mul="1.0" max="1.0"/> <expr name="color.g" from="colorg" mul="1.0" max="1.0"/> <expr name="color.b" from="colorb" mul="1.0" max="1.0"/> <force y="-2.5"/> </particles> Custom actor: <?xml version="1.0" encoding="utf-8"?> <actor version="1"> <castshadow/> <group> <variant frequency="1" name="Carthaginian House"> <mesh>skeletal/celt_trader.dae</mesh> <props> <prop actor="props/structures/decals/dirt_small.xml" attachpoint="root"/> <prop actor="particle/construction_dust.xml" attachpoint="root"/> </props> <textures> <texture file="structural/kart_struct.dds" name="baseTex"/> <texture file="structural/kart_struct_norm.png" name="normTex"/> <texture file="structural/kart_struct_spec.png" name="specTex"/> </textures> </variant> </group> <group> <variant frequency="1" name="ungarrisoned"/> <variant name="garrisoned"> <props> <prop actor="props/special/common/garrison_flag_kart.xml" attachpoint="garrisoned"/> </props> </variant> </group> <group> <variant name="alive" frequency="1"/> <variant file="structures/cart/light_damage.xml"/> <variant file="structures/cart/medium_damage.xml"/> <variant file="structures/cart/heavy_damage.xml"/> <variant file="structures/cart/destruction_small.xml"/> </group> <material>player_trans_parallax_spec.xml</material> </actor> I used a custom texture for the following one: I used the following texture: -> (It's not all white) Few notes: Hotloading particles is crashy as in changing a few values can crash the game. SetVariable won't work if you hotload particles (each time you change a value in the XML or the modle you have to restart the match) Fortunately you can use the following code in your tests (Don't use in production) that will keep forcing the variables at each frame. class ParticlePlayerColor { ... Don't touch the previous code. OnUpdate() { this.UpdateColor(); } } As for the grey in the middle it's due to particles decaying maybe it's an engine bug @vladislavbelov would know.

Nice work. This is why stella artis was made happy someone else made a scifi mod

Late_Sasanian_army.pdf

https://www.instagram.com/0ad_memes_eae/ Be sure to follow for the most nub 0 AD memes !

Asking because I made a map where you start on a towering mesa-like rock, and well, let's say that when on top, the camera gets very close & intimate! I even noticed for the first time that the upgraded Britons get naked!... (I should had known... ) Anyway, apparently the camera in the game doesn't have the freedom of movement of the Editor's camera, there seems to be a hard-coded altitude limit, and if I had made my rock a little higher I would had only seen shoes... Is that true? Is there a hard-coded altitude limit (as opposed to a "height over ground" ratio)? This map was simple, just a quick proof of concept, but I plan on making more of those, including a chaos of desolate flat peaks like this, separated by deep ravines and only accessible by those narrow paths carved on the cliff sides (easy to defend, but only until your limited resources run out. By then you'd better have moved on, and as soon as you move "easy to defend" becomes "hard to conquer"). To illustrate: (For scale, note how far goes the territory influence marker of the civil center (yes, that's a fortified civil center)...)

Unsurprising. I'm a little busy at the moment with work, but I'll look into it when I get time. @ShadowOfHassen, hyperion's suggestion of working on top of a fork of 0ad.git is what I do for my two mods listed on mod.io. The script he provided (which works roughly the same as the script I wrote and use for the same task on my computer) detects which files have been altered, which means the output mod file will only contain files that have been modified by your commits. The script also supports auto-marking files that should be "deleted" (read: ignored) from mods that appear above it in the in-game mod list. As what you're attempting to do is modify not remove templates, this feature is probably not one you'll be using.

Here's a map I experimented with by using a dental xray for the heightmap

Offence Reporting It is necessary for you to create a post on this thread detailing the incident and including the replay file. When reporting a player, it is mandatory to upload the correct replay. Instructions: Locate replay at Main Menu/Multiplayer/Replays Select replay and note replay file path. Go to path in your file manager, locate the file named "commands.txt" Upload commands.txt to the Forums (account creation required) Tag @user1 Please state your lobby username and the lobby username of the offending player. You will not be notified of the result automatically, you may view the ongoing status of our progress at the bottom of this first post. Find more detailed instructions below: data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw== Progress Report: @Xander12 @gameraj @Nympheuz @raffut1969 @donkenburger @e.v @petiprg

Can you show me the actor? and the template