Leaderboard

Update: v 0.7.0 Added map preview to the maps Made fert map with hill and another fert map with mountain Added shallows paths (good idea elexis) improved terrain (now is smoother) fixed paths going off road (used bezier curves) added more decoration

It would take 5 mins to make a mod and test it out. Could even be added to the mod.io list and let players, you know, playtest. That was one of the selling points of making modding so integral to these alpha releases right? So balancing work could be done by hundreds instead of a handful? I reiterate that it is my opinion that fine tuned balancing discussions are worthless at this juncture, unless there is some kind of gross imbalance. The question is whether battering rams are grossly imbalanced (I think they are). So, let's make 2 "official" balancing mods. One where the battering ram speed is reduced, and one where they can't attack soldiers. Get people to test them out and then they can report back here. That's the real way to "balance" these things. Another mod could be adding @borg-'s flaming arrows idea. Or you can play Delenda Est where battering ram speed has been reduced for over a year and flaming arrows have been implemented for a couple civs in some circumstances for a long time too.

Han Dynasty equipment progression, Western Han to Eastern Han. While drawn in cute anime style, the equipment in these artworks are VERY accurate. Illustrations courtesy of 防弹乳牛. Progressively heavier armaments, from early Western Han (left) to mid-late Western Han (right), with a slight dose of imagination (i.e. I don't think a long halberd can be used together with a shield, unless it is a strapped shield that appeared during Eastern Han). Note the bronze and iron Pi(鈹) type spears. Various equipment. Items of note: 1) Polearms at the top of the picture (from left to right: Sha-type spear, normal spear, Ji halberd, and axe-type halberd) 2) Gourang metal buckler in the warrior's hand. 3) Eastern Han Dynasty shield at the mid-left section of the picture. 4) Straight saber with knuckle-bowl hilt at the lower left section of the picture (Yes. Han Dynasty troops did use that) 5) The way sword scabbard is tied to the belt. (late) Eastern Han-Three Kingdoms warrior. Items of note: 1) upward-curving Ji halberd (bottom), 2) Very long, armor-piercing spearhead. 3) Sha (鎩) type "ranseur" polearm. 4) Axe. 5) collared armor with full sleeves + thigh armor. 6) Helmet constructed out of vertically arranged, riveted long narrow plates, instead of lamellar (i.e. laced) construction like Western Han period. 7) Shou Ji (手戟) or Short one-handed Ji halberd. 8) Archery bracer at the mid-right of the picture.

I understand that balancing is a delicate issue, but rams should obviously be noticeably slower than the slowest infantry unit. The heavy ram is pushed forward by people, it's not outfitted with a combustion engine or anything. By definition it is slower. Just think about it for a minute... How can people pushing a heavy device outrun infantry? That one unit of speed difference isn't noticeable by the way, it results in a disorrientated mass of infantry chasing the ram from behind, rather than flanking it or immobilising it by running in front of it. You often can't effectively order your infantry to "intercept" them. Secondly, it's really cool that swords are specialized at taking out rams, no problem, but it is highly unrealistic and unintuitive that spears perform so poorly against them. Again, think about it for a minute... You'd expect spears (with all that extra reach) to be quite effective at killing the dudes operating the ram. I haven't played alpha 23 MP, to be honest, but I played more than a few MP-games in alpha 22 and people were definitely complaining about rams. Mostly during the game, and I've also seen people bring it up after games in the lobby as well... Also, how are rams even capable of killing horses? You can even effectively use rams against ranged infantry if the opponent isn't paying close enough attention. That's just weird... In short, rams are too fast, and spears should be somewhat effective at taking them out as well. It has been brought up many times before. Rams should also have a bonus against gates. If not those things, at least make it slower at dealing damage... A siege should feel like a siege, not a steamroll... First you kill/clear the enemy army, then you send in the siege-equipment. But how in the world can you send siege-equipment through an enemy army?? Anybody that does that deserves to loose their equipment. Currently they are rewarded, however, especially if they advance with rams. Sure, it's a good practice to take advice from the best pro-players, BUT, I always get the very strong feeling that many people here are forgetting the masses of single players (more than 90% of the player-base), and everyone that isn't a pro-player (99.9%). Obsessive compulsive micromanagement of units, a strong focus on APM and a good command of shortcuts, as well as making the most effective use of obscure/under-advertized mechanics isn't what most players enjoy or expect from a Real Time Strategy game. You expect that from MOBA-games like League of Legends. When playing a historical RTS like 0AD, a certain level of intuition is to be expected.. You'd expect melee units to be good against rams. I also think you can easily alienate new players by always dismissing these kind of concerns/suggestions when they come up repeatedly like this. It almost feels like calling them ignorant for not understanding things that can not be understood without asking specific players, which is unintuitive and offsetting. The vast majority of people aren't crunching numbers when they compose their army. Explaining fiddly numbers about hack, pierce and crush damage really isn't a satisfying explanation as to why you lost a game. If you want to ignore, disagree or dismiss the above, that's totally fine (no hard feelings), but at least agree that there need to be clear and unambiguous in-game tooltips explaining each of the most obscure/influential mechanics. Lower the threshold for players to understanding what they are doing wrong. When recruiting rams, it should clearly say what they are good against, and what they are vulnerable to. When recruiting swordsmen, it should clearly say that they are specialized at taking out siege-equipment.

If we ever have #2577 the one thing I'd want is doors independent from the walls. Then we could make destructions variant for them too.

@andy5995

Hi all! I've built the latest 0.0.23-alpha on Slackware64-14.2 (multilib) including all deps using SlackBuild scripts. There's a "disable-root-check.patch" script included in this build but I'm not sure if it's causing this error. Patch looks like this: --- a/build/workspaces/update-workspaces.sh +++ b/build/workspaces/update-workspaces.sh @@ -1,9 +1,9 @@ #!/bin/sh -if [ "$(id -u)" = "0" ]; then - echo "Running as root will mess up file permissions. Aborting ..." 1>&2 - exit 1 -fi +#if [ "$(id -u)" = "0" ]; then +# echo "Running as root will mess up file permissions. Aborting ..." 1>&2 +# exit 1 +#fi die() { So, this is what the terminal spits out when I try to start the game: kole@darkstar:/usr/games$ 0ad /usr/games/0ad: line 9: 14444 Segmentation fault "$pyrogenesis" "$@" Have a look at /usr/games/0ad: #!/bin/sh pyrogenesis=$(which pyrogenesis 2> /dev/null) if [ -x "$pyrogenesis" ] ; then "$pyrogenesis" "$@" else echo "Error: pyrogenesis not found in ($PATH)" exit 1 fi Finally, I followed ReportingErrors howto and here's the output: kole@darkstar:/usr/games$ gdb pyrogenesis GNU gdb (GDB) 7.11.1 (...cleared for readability) Reading symbols from pyrogenesis...(no debugging symbols found)...done. (gdb) run Starting program: /usr/games/pyrogenesis [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff3febbdb in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () from /usr/lib64/libstdc++.so.6 (gdb) thread apply all bt full Thread 1 (Thread 0x7ffff7f7eb80 (LWP 14126)): #0 0x00007ffff3febbdb in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () from /usr/lib64/libstdc++.so.6 No symbol table info available. #1 0x0000000000640fa9 in ?? () No symbol table info available. #2 0x0000000000672727 in ?? () No symbol table info available. #3 0x00000000006f3447 in ?? () No symbol table info available. #4 0x0000000000432d61 in ?? () No symbol table info available. #5 0x0000000000af3a76 in ?? () No symbol table info available. #6 0x0000000000000000 in ?? () No symbol table info available. (gdb) backtrace #0 0x00007ffff3febbdb in std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&) () from /usr/lib64/libstdc++.so.6 #1 0x0000000000640fa9 in ?? () #2 0x0000000000672727 in ?? () #3 0x00000000006f3447 in ?? () #4 0x0000000000432d61 in ?? () #5 0x0000000000af3a76 in ?? () #6 0x0000000000000000 in ?? () No debugging symbols found? Is this it or it's something else related to /usr/lib64/libstdc++.so.6? In my case it's a symbolic link to /usr/lib64/libstdc++.so.6.0.21 but I have no idea where to go from here. Also, dependencies of pyrogenesis seem fine, I guess: kole@darkstar:/usr/games$ ldd pyrogenesis linux-vdso.so.1 (0x00007ffc1edad000) libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fad45c5d000) libSDL2-2.0.so.0 => /usr/lib64/libSDL2-2.0.so.0 (0x00007fad458f8000) libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fad456c6000) libz.so.1 => /usr/lib64/libz.so.1 (0x00007fad454af000) libmozjs38-ps-release.so => /usr/lib64/0ad/libmozjs38-ps-release.so (0x00007fad44d71000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fad44a0c000) libboost_filesystem.so.1.59.0 => /usr/lib64/libboost_filesystem.so.1.59.0 (0x00007fad447f5000) libenet.so.7 => /usr/lib64/libenet.so.7 (0x00007fad445e9000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007fad4436c000) libicui18n.so.56 => /usr/lib64/libicui18n.so.56 (0x00007fad43edb000) libicuuc.so.56 => /usr/lib64/libicuuc.so.56 (0x00007fad43b43000) libsodium.so.23 => /usr/lib64/libsodium.so.23 (0x00007fad438f0000) libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fad435b5000) libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007fad433aa000) libopenal.so.1 => /usr/lib64/libopenal.so.1 (0x00007fad43112000) libvorbisfile.so.3 => /usr/lib64/libvorbisfile.so.3 (0x00007fad42f09000) libnvtt.so => /usr/lib64/0ad/libnvtt.so (0x00007fad42cee000) libgloox.so.17 => /usr/lib64/libgloox.so.17 (0x00007fad4299f000) libminiupnpc.so.16 => /usr/lib64/libminiupnpc.so.16 (0x00007fad42792000) librt.so.1 => /lib64/librt.so.1 (0x00007fad4258a000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fad42386000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fad4200a000) libm.so.6 => /lib64/libm.so.6 (0x00007fad41d01000) libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fad41aea000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fad418cd000) libc.so.6 => /lib64/libc.so.6 (0x00007fad41504000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fad412da000) libxcb-dri3.so.0 => /usr/lib64/libxcb-dri3.so.0 (0x00007fad410d8000) libxcb-present.so.0 => /usr/lib64/libxcb-present.so.0 (0x00007fad40ed6000) libxcb-randr.so.0 => /usr/lib64/libxcb-randr.so.0 (0x00007fad40cca000) libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007fad40ac4000) libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007fad408bb000) libxcb-shape.so.0 => /usr/lib64/libxcb-shape.so.0 (0x00007fad406b8000) libxcb-sync.so.1 => /usr/lib64/libxcb-sync.so.1 (0x00007fad404b3000) libxshmfence.so.1 => /usr/lib64/libxshmfence.so.1 (0x00007fad402b1000) libglapi.so.0 => /usr/lib64/libglapi.so.0 (0x00007fad40083000) libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007fad3fe81000) libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007fad3fc7b000) libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007fad3fa79000) libxcb-glx.so.0 => /usr/lib64/libxcb-glx.so.0 (0x00007fad3f863000) libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007fad3f65f000) libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007fad3f45a000) libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fad3f248000) libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fad3f029000) libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fad3ee26000) libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fad3ec21000) libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007fad3ea13000) libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007fad3e7c4000) libplds4.so => /usr/lib64/libplds4.so (0x00007fad3e5c0000) libplc4.so => /usr/lib64/libplc4.so (0x00007fad3e3bb000) libnspr4.so => /usr/lib64/libnspr4.so (0x00007fad3e17d000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fad3df58000) libboost_system.so.1.59.0 => /usr/lib64/libboost_system.so.1.59.0 (0x00007fad3dd55000) libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x00007fad3db28000) libssl.so.1 => /lib64/libssl.so.1 (0x00007fad3d8b5000) libcrypto.so.1 => /lib64/libcrypto.so.1 (0x00007fad3d462000) libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007fad3d219000) liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007fad3d00b000) libicudata.so.56 => /usr/lib64/libicudata.so.56 (0x00007fad3b628000) /lib64/ld-linux-x86-64.so.2 (0x00007fad45ec5000) libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fad3b41e000) libatomic.so.1 => /usr/lib64/libatomic.so.1 (0x00007fad3b216000) libvorbis.so.0 => /usr/lib64/libvorbis.so.0 (0x00007fad3afea000) libogg.so.0 => /usr/lib64/libogg.so.0 (0x00007fad3ade4000) libnvimage.so => /usr/lib64/0ad/libnvimage.so (0x00007fad3abba000) libnvmath.so => /usr/lib64/0ad/libnvmath.so (0x00007fad3a9b1000) libnvcore.so => /usr/lib64/0ad/libnvcore.so (0x00007fad3a7a9000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fad3a53f000) libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007fad3a2c8000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fad3a0ad000) libidn.so.11 => /usr/lib64/../lib64/libidn.so.11 (0x00007fad39e7a000) libgnutls.so.30 => /usr/lib64/../lib64/libgnutls.so.30 (0x00007fad39b0e000) libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007fad398f2000) libp11-kit.so.0 => /usr/lib64/../lib64/libp11-kit.so.0 (0x00007fad39690000) libunistring.so.0 => /usr/lib64/../lib64/libunistring.so.0 (0x00007fad3937b000) libnettle.so.6 => /usr/lib64/../lib64/libnettle.so.6 (0x00007fad39145000) libhogweed.so.4 => /usr/lib64/../lib64/libhogweed.so.4 (0x00007fad38f11000) libgmp.so.10 => /usr/lib64/../lib64/libgmp.so.10 (0x00007fad38c9b000) libffi.so.6 => /usr/lib64/../lib64/libffi.so.6 (0x00007fad38a93000) Please advise! Thanks!

Ok, i just tried out the lastest version. Everything is so good so far but it seems battering ram speed is way too high and unrealistic. They have almost the same speed as light infantry. I don't mind the fact that it is hard to be destroyed and deals lots of damage to buildings but the speed is way too high. Please reduce it. Everyone who is familiar with history knows that battering ram is a very heavy siege engine, it should not be as mobile or move as fast as currently depicted in the game. Thanks

Texturing has, and is still my weak spot, so I'm always trying to improve there, because I intend to give the flora some love. Today I experimented translating a tutorial from http://www.oggyart.com/tutorials.htm a CD Projekt Red environnement artist to blender. I found the link on Khaganat so I thought I'd try it out. In the end I didn't manage to get much of the workflow in blender, but if someone can make it more straighforward please let me know. For now, I just take a vertical picture of grass planes just like he does. Reusing game grass textures I managed to get some new terrain textures. (Files are at the bottom for people that want to try it in the game) I can upload the blendfile on request. grass_texture_1.zip

Found the problem, thanks for reporting i'm downloading the github file in another pc while i'm away from mine. I will commit a temporary fix of the template file (the bug is at the obstruction between door and walls) tell me if its fixed in the repository, i'm unable to test or play properly here.

Hack = melee. In game context. It never made sense to give them a pierce attack. It only muddied the waters.

Han Chinese had both, you know . Attached pic is a Han period halberd - the normal Ji has a horizontal dagger-like blade, but this version has an axe blade.

MP wise most decent players rely on siege weapons as the main winning strategy while most pros are trying to outsmart opponent using organic units then just use siege if the opponent won’t submit to defeat. It this is the trend then it’s viable to reduce rams speed or reduce the capabilities of every non organic sieges. SP is the worst case with AIs are too quick and very fond of siege weapons. Playing Mil AD and the hardest AI makes between 5-8 rams per massive attack destroying the beauty of your defenses. I play against 2 hardest and it’s quite annoying, the Rams. How much more if it’s against 3! With very few good maps for an infinite time game. Added by the AIs making too much offensive towers and forts wherever they can (IMO one of the RTS games annoying mechanics) is the most annoying Petra bot behavior. I think it’s better that these sieges are very powerful and slow but should cost really high! Realistically they are there for breaking the impasse. Rams exclusively for structures with very high damage and catapults for long range with varying degree of capabilities per Civ.

I meant the link to the build instructions that I posted above. The order of building the deps doesn't matter, except that I'm pretty sure that wxGTK3 must be installed before wxPython3 (if you want to build the Atlas Editor). By default, the Slackbuild script won't build the Atlas Editor. You can have a binary with the debug symbols using either the release archive or the svn. If you want to just use the release archive with the Slackbuild script, I think all you'd have to do is remove the "strip" command from 0ad.Slackbuild. find $PKG | xargs file | grep -e "executable" -e "shared object" | grep ELF \ | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null That section from the Slackbuild script there you could just comment out completely. I think it's the only place where the stripping is done.

Thanks for chimin' in @andy5995 Your info is much appreciated. I've subscribed to LQ thread, hopefully it will gain attention of 'big boys' there. Well, already did, AFAIK. :) I think I don't understand this: Did you mean the building order, as you listed, is essential to get the clean build with debugging symbols or one should use svn for that? Thanks!

Hi @konmit It looks like you've been very thorough! I assigned myself the ticket 4789 a few days ago. I'm not really sure what else to try yet. I added Slackware build instructions to the documentation. Like you, I did refer to the Slackbuild scripts to get the deps right. >No debugging symbols found? Is this it or it's something else related to /usr/lib64/libstdc++.so.6? In my case it's a symbolic link to /usr/lib64/libstdc++.so.6.0.21 The reason for that is because the Slackbuild script will strip symbols from the binary, as Slackbuild scripts generally are for packaging releases. If you use the instructions I posted directly above, and build from svn (you could also build from the a23 archive that you already have), the resulting binary will contain debugging symbols. To be honest, I'm not sure what to try next and I'm hoping that when the 0ad devs have more time they might be able to take a closer look and give me ideas to try. In the meantime, I've asked for help in the Slackware forum at LQ, so you may want to also subscribe to that thread. But I'll try to keep you updated if anything changes for the better. If you have any ideas or more questions, of course, please share them here or on the ticket.

Also I agree that movement speed of rams should be slightly slower than that of melee infantry units, just don't mess with the effectiveness of the thing once it attacks.

1v1s are over before it comes to the time of walls. 4v4s (with bots or not), it takes a lot more time until everyone is defeated if the players are similarly capable. It's important to note that walls can accumulate successively while the unit population is limited and the area where progressively is obstructed in lategame. From #3811 and https://wildfiregames.com/forum/index.php?/topic/20621-good-players-usually-say-no-walls-in-the-multiplayer-lobby/&do=findComment&comment=314820

Or removing that weird pierce attack given to spearmen and make them hackers instead. All civs have spearmen as far as I remember.

Is that even a problem anymore?

In the like 100 matches I've seen casted on Youtube, I can't remember a single player actually building a curtain of walls, but I'm not sure if that's a whole other discussion or if siege weapons should be discussed in concert with walls.

Well, yeah, people have been complaining about rams for a loooong time. Minutes to make the mods. The hours of testing don't need to be done by you or stan or the 1 or 2 other active guys. In general, maybe. Likely, they are the best to just what is best for competitive play. 90% of your user base are probably not very competitive. Though, 90% of those probably would not have any idea why they're not liking the balance, only that the gameplay feels unbalanced or bad or frustrating. Let's not get ahead of ourselves. Barely anyone even uses walls. But honestly, I think rams should be more about attacking walls and other defenses, specifically bringing down gates. But we have yet to construct a meta where the player actually is incentivized to use walls and build proper cities. That's what the "normies" and "casuals" do after all.

Insurgency - Add it to your Steam account now and keep it forever. https://store.steampowered.com/app/222880/Insurgency/

Not only food but wood too though it should be much much slower than food. People can’t last living without using wood to cook. Well it’s just a game. Stamina or attrition damage could really add gameplay. 0ad or AoE units are really 100% efficient which are not realistic. RoN’s attrition gameplay makes the player to be more cautious, tactical and strategic on military activities. It is annoying only for those who can’t play decent or advanced. Supply wagons just prevent further HP deterioration. Attrition tech is very expensive for good players that they don’t even research it until later when the resources are piling up. Attrition damages don’t deter good players from doing their raids.

Why we did not invest in something smarter, a new upgrade, "flamming arrows", deals extra damage vs sieges and perhaps also against buildings, this would make battering rams much more vulnerable, archers would become an interesting and important unit, and encourage players play with archers civ (little used at the moment).

Another attempt. This time with mixed grass. untitled1.png.zip

I like your suggestion. I like the idea of giving the underdog in a fight a chance to break their opponent (or at least get some breathing time) by a well executed quick raid. I hate to see players resign as soon as they loose their army in the first collision because "I have no realistic chance any more". One should not be able to sit back and relax after the first battle is won, knowing that the enemy has no real fighting chance to recover any more. Whether something like this would be annoying or a pleasant addition to game-play depends mostly on how well it would be executed. Of course care must be taken to not make matches last forever by making it nigh-impossible to take the enemy's base. A standing war is disheartening, I hate when it is impossible to break a front in the middle of the map and it takes many minutes to move it even a few centimetres. So some degree of snowballing effect is absolutely fine.

This was implemented in Rise Of Nations if I recall correctly. There, you had to carry around a special unit (storage wagon?). When leaving your own territory your units started to loose health unless they were in the radius of this special units. I don't remember the specifics (didin't play much RoN) except that this was extremely annoying, but then it was also probably a nuisance to the generals of old.

(Also, if you decide to go for these shallows and paths, one could have a really narrow one near enemies and a broader one near allies usig the areAllies(p1, p2) function)

Hello everyone, I didn't see any totorial to explain how to change the GUI. So, I will try to write one. I'm not English, so if they are mistakes, moderators could edit this. I will update this tutorial when I will found new things (I learn from analysing the source code). Customize your Gui 0.Create a mod 1. Add a new panel 2. Coming soon ... 0.Create a mod Go in the folder where you install 0ad : "0 A.D. alpha" then into "0 A.D. alpha\binaries\data\mods" Create a new folder with the name of you mod (replace space by _) Go in "0 A.D. alpha\binaries\data\mods\public" ; copy "mod.json" in your own mod directory Edit the file with Notepad++ : after "label :" delete "0 A.D. Empires Ascendant" and enter the name of your own mod ; you can also change the description Congratulations ! Now your mod appears in the mod selection of 0ad ! 1. Add a new panel In the directory of your mod, create these folders : "\gui\session" Go into the public mod folder (0 A.D. alpha\binaries\data\mods\public) open the zip file and then go in gui\session. Copy session.xml and sprites.xml in your own session folder. Edit session.xml with Notepad++ : line 103 add "<include file="gui/session/the_name_of_your_panel.xml"/>" Edit sprites.xml : after "<!-- Panel Backgrounds -->" (line 27) add : <sprite name="the_name_of_your_sprite"> <image texture="session/folder_of_my_pictures/name_of_my_background_picture.png" texture_size="0 0 100% 100%" size="0 0 100% 100%" /> </sprite> 5. Create in the folder session a file named the_name_of_your_panel.xml , then edit it : <?xml version="1.0" encoding="utf-8"?> <object name="the_name_of_your_panel" type="image" sprite="the_name_of_your_sprite" size="coordinateX1 coordinateY1 coordinateX2 coordinateY2" tooltip_style="sessionToolTip"> </object> You must define the placement of your panel with its coordinates. 6. Place the background picture of your panel in name_of_your_mod\art\textures\ui\session\folder_of_my_picture\name_of_my_background_picture.png Launch 0ad and activate your mod. Your panel is now present during your game !

After looking at the files you're right. They have a relative speed of 0.9, which is actually faster than pikemen. Siege towers have a relative speed of 0.7 by comparison, which is a little slower than pikemen. Given that only melee units can damage them and given that melee units are generally slower than ranged units, that's pretty ridiculous.

I totally agree with this. It seems insane that my infantry struggle to keep up with a ram that must weigh tons! It leaves factions that lack sword cavalry with effectively an invulnerable attacking enemy. Thanks for bringing this up @Thelegionare

Now we need the back. lol

babylon style1 babyloniansmall_normal.psd babyloniansmall.psd publicdomainlionmod.psd babilonian_classic.psd