Palaxin

This problem is partially addressed by ticket #4342 "dirty aura for civic center". I think we could combine the ideas of finite fields with the intention to move fields away from the CC: finite fields finite food supply (e.g. 500), slowly depletes, also when no one is gathering (thus it is guaranteed that the field will finally vanish) no minimum distance to CC required fast and cheap to build (e.g. 50 wood) small field size, only few gatherers per field (e.g. 2) slightly lower gather rate (e.g. 80% of infinite fields) infinite fields infinite food supply require a minimum distance to CC, but not military colony (e.g. 80-120 m, thus not covered by CC range) long build time, high costs (e.g. 150 wood) huge filed size, more gatherers per field (e.g. 5) slightly higher gather rate technologies Unlock technology for infinite fields. Alternatively, infinite fields can be unlocked by advancing to Town phase. Technology for finite field enhancements. This enhancements only apply to finite fields which are separated from CCs by a minimum distance.

Agree, since your mod aims to be (partially) included in vanilla 0 A.D. Small steps are always better then. However, I hope in the long run the devs committed to balancing, e.g. @scythetwirler will re-evaluate the current allocation of civs and preferred meta strategies (rush, turtling, boom).

I like your thoughts/intentions in general. There is definitely room for improvements regarding variety of civ specific strategy. Ideally, civs are different enough that each civ fits at least one unique niche in gameplay. However, your proposed "Rush"/"Wall"/"Eco" classification of civs doesn't seem historically accurate to me. IMO Carthaginians (triple walls), perhaps also Athenians (long walls connecting the city with Piraeus) are wall civs, and Celtic civs should be used for rushing (small/simple buildings, fast infantry). Ptolemies could be eco (fertile Nile River delta). Just some suggestions. Furthermore, I suggest to add a second "dimension" to early/mid/late in order to provide even more variety or make that variety more visible. E.g. "economy"/"building"/"infantry"/"cavalry"/"siege" resulting in 3x5 = 15 fields (I don't think e.g. a wall civ necessarily needs to peak at phase 2). Or find another way to distinguish the 4 civs of each meta strategy.

Whooooah! Especially love the (big) tower scaffold! Perhaps Carthaginians could be an experimental civ for a new construction system including foundations, scaffold models and full building models?

I know two games with tree regeneration: Settlers: a dedicated forester replants tree saplings which grow big after some time (perhaps 3-5 minutes) Stronghold Crusader: trees naturally spawn other trees in their vicinity, if the tree density is below a certain threshold (otherwise trees disappear) As proposed by @Lion.Kanzen I think the best implementation for 0 A.D. or a 0 A.D. mod, respectively, would be a farm-like field of saplings. An initial seeding requires some workers "building" the "forest structure". However, it requires some additional time until the trees are grown and can be harvested.

@fcxSanya Sorry for being inactive for so long... I recently started my first full-time job, which leaves me with less free time and energy for private projects in this free time (actually more the latter ) That said, I regularly track progress of 0 A.D. development, but I am not sure when and how much I will engage again. It certainly helps if I see that people are interested in my work

Thanks @Lion.Kanzen, I already had you in mind for that task Unfortunately I won't have time till weekend to do further work, but I hope I can upload the mod within a week.

This mod is inspired by my idea to provide multiple techs to upgrade war elephants. So far I didn't receive negative feedback for this idea, but please leave any comments because I hope some or all content can be included in the game. The icons are placeholders and we would need proper ones made by the art department. related ticket: #4116 IRC discussion: 26/07/16 from 14:00 onwards mod-folder: download link will follow soon diff-file: download link will follow soon (doesn't take the mod.json into account) SVN version: r18565 Known bugs in my current version: Capture component for Indian melee war elephants, but not North African ones. Both shouldn't be able to capture. Pig and elephant fear auras don't work. For some civs/buildings the GUI panel is too small to display all available techs. Units The Melee War Elephant template has been split into two templates for the Indian and North African species. Historically, Indian elephants were significantly bigger and stronger than North African elephants. Additionally, they could be tamed more easily and were less susceptible to run amok during battles. The crush damage component has been reduced as elephants usually weren't used for siege. Defenders would easily pick of the mounted soldiers and throw hot pitch on the elephant as soon as it hit the wall. Hack damage has been increased for compensation. Additionally, cavalry got a 50% attack reduction against melee war elephants because horses were turned off by the smell of elephants. Indian Melee War Elephant 800 HP, 5 hack armour, 10 pierce armour, 20 crush armour 40 Hack damage, 120 Crush damage 400 food, 400 metal, 40 s train time, 6 population trained by: Mauryans, Persians, Seleucids North African Melee War Elephant 600 HP, 5 hack armour, 10 pierce armour, 20 crush armour 30 Hack damage, 90 Crush damage 250 food, 250 metal, 40 s train time, 4 population trained by: Carthaginians, Ptolemies Cavalry 50% damage reduction against enemy melee war elephants. Auras Pig aura effect: 80% damage reduction for enemy war elephants within 30 m range. explanation: The pig's sqeaking extremely frightened elephants. It is reported that pigs were covered with oil, set in flames and then driven towards enemy elephants to even increase the effect. Elephant aura effect: 10% damage reduction for enemy citizen soldiers within 30 m range. explanation: The main purpose of war elephants was to disrupt formations and to frighten enemies solely by their size. Especially people which hadn't seen elephants before often fled by the sight of the animal even before the battle began. Technologies Tusk spikes description: It is reported that in the Battle of Jhelum King Porus fitted brass plates to the tusks of his war elephants which were covered with sharp iron spikes. Therefore the animals could easily impale their enemies and helped Porus to inflict one of the greatest losses to the army of Alexander the Great. effect: +50% hack damage, +20% metal cost cost: 1000 metal, 40 s research time civ: Mauryans phase: City Caparison description: Caparisons were cloth coverings providing a simple protection for the skin of war elephants. effect: +1 hack and pierce armour cost: 500 food, 40 s research time civ: Carthaginians, Mauryans, Persians, Ptolemies, Seleucids phase: City Plate Armour description: Some war elephants were armoured with chain mails and metal plates so they were much less vulnerable to ranged attacks. However, the lower parts of the trunk and the legs typically remained unconvered. effect: +3 pierce armour, +1 hack armour, -10% speed cost: 500 wood, 1000 metal, 60 s research time civ: Carthaginians, Mauryans, Persians, Ptolemies, Seleucids phase: City required tech: Caparison Mahout description: From a young age and throughout their lives, mahouts were bonded to an assigned elephant which they trained and rode. They had special tools available to control their animal and could even kill it quickly if it panicked in battle. effect: +10% speed, +50% trample damage, +10% train time cost: 500 food, 40 s research time civ: Carthaginians, Mauryans, Persians, Ptolemies, Seleucids phase: City Howdah description: Indian and big North African war elephants were strong enough to carry a tower on their back from which archers, slingers and javelin throwers could fight enemies from a distance. effect: +30 pierce damage, -10% speed cost: 1000 wood, 500 metal, 60 s research time civ: Carthaginians, Mauryans, Persians, Ptolemies, Seleucids phase: City required tech: Mahout

@niektb: I accidentally followed the Script-Fu install instruction, not the Python instruction. Now it's working perfectly. Thanks!

I saved the script in my script folder (GIMP 2.8.16, Windows 10), but I can't find the new features in the GUI. Where are they supposed to be? I refreshed the scripts and restarted GIMP before.

To be honest I often choose one of the slowest game speeds. I play the game more for optimizations (e.g. winning without losing a single unit) than just for fun and I'm really bad at multitasking. This is also the reason why I don't really play multiplayer (observing is interesting though). It's like a kind of chess where more time to think and react leads to less errors. 0.1x for pure optimization (and unit microing during a huge battle) 0.25x when building up economy 0.5x for late game when everything is set up and no huge threats can be expected 0.75x feels like the most realistic game speed to me

Reminds me of the bug described here (open the image spoiler). When using the Atlas heightmap import tool there frequently appear walls at the map edges which cause the black shadows/reflections...

I think Seleucids and Ptolemies would have a significant advantage with their phase 2 mini CCs. They are the first who can claim strategic points and have lower costs for expansion. Perhaps military colonies should be disabled in this mode...

The engine doesn't support anti-aliasing? Can we change that? I think 128x128 and 256x256 are pretty close, so I would also favor 256. At least 4K displays will need this resolution. According to this site 4K displays already reach 23% market share in the TV segment. I think in a few years this will be standard for both TV and PC displays...

I intended this to be an optional version. One download button/link for the vanilla game and one for the version including the official mods. So if you don't want them, you don't need to install them. But I understand that this may not be worth the effort. Agree

I started to write classes, so the functions in one class can directly modify the variables of that class/object. The reason is because I want to bundle the majority of the code in a separate module/library which provides the necessary tools for heightmap input/output and manipulation.

I think each map should define the supported victory conditions and the map filter should be able to show maps of single or combined victory conditions

@niektb Perhaps we could also release downloadable "extended editions" which bundle the vanilla game with some official mods (Rise of the East and Millenium A.D. at the moment, maybe Delenda Est). That would provide you much more players/testers I suppose. I would also appreciate to include (parts of) some mods in the main game e.g. Rise of the East...

Sorry, it's a bit unclear indeed. I mean a readFromPMP() function (which I called the "reverse" of the write function) of course can only return one value and not "heights", "textures" etc. (the arguments of the writeToPMP() function). So if I want to extract different data from a file by using this readFromPMP() function, I will have to return an object which contains various data like height and texture arrays.

.pmp file writing is working well with the module below. I started learning Python 2 days ago, so don't wonder if the code doesn't follow any conventions. It is not really possible to reverse the write function as there can be only one return value and at least height AND textures are interesting. Perhaps define a map object and return one? @wraitii I also notice you don't use the struct module, is there a reason (performance, ...)? Thx for your script import os import struct PMPVERSION = 6 # .pmp file version MINTILES = 128 # tiles per line and column in the smallest valid map size MAXTILES = 512 # tiles per line and column in the biggest valid map size STEPSIZE = 64 # difference in tiles per line and column between two map sizes def validMapSize(mode, array): "Returns True if a 2D array of integers represents a valid map size. \ 'mode' can be 'h' for heights or 't' for textures." # 16*n texture tiles, but 16*n + 1 heights per line and column rest = 1 if mode == "h" else 0 if len(array) % STEPSIZE != rest or len(array) < MINTILES or len(array) > MAXTILES: return False for i in range(len(array)): if len(array[i]) % STEPSIZE != rest or len(array[i]) < MINTILES or len(array[i]) > MAXTILES or len(array[i]) != len(array): return False return True def writeToPMP(filename, heights, textures, texturenames, texturepriorities): "Writes a new .pmp file and returns True if successful. \ 'heights' and 'textures' must be 2D arrays of 16-bit integers, \ 'texturenames' a string array and 'texturepriorities' an array of 32-bit integers." if not validMapSize("h", heights) or not validMapSize("t", textures): print ("invalid map size") return False #if not os.path.isfile(filename) or filename[-3:] != "pmp": # print ("\"" + filename + "\" invalid path or filename") # return False numtiles = len(textures) numpatches = round ( numtiles / 16 ) numheights = numtiles + 1 # header bytes + height data + u32 array length filesize = 16 + 2 * numheights**2 + 4 # u32 string length + string for i in range(len(texturenames)): filesize += 4 + len(texturenames[i]) # texture data filesize += 8 * numtiles**2 with open (filename, "wb") as f: # write file header f.write(struct.pack("4s", b"PSMP")) f.write(struct.pack("<I", PMPVERSION)) f.write(struct.pack("<I", filesize - 12)) f.write(struct.pack("<I", numpatches)) #write height data for vHeight in range(numheights): for hHeight in range(numheights): f.write(struct.pack("<H", heights[hHeight][vHeight])) #write texture names f.write(struct.pack("<I", len(texturenames))) for i in range(len(texturenames)): f.write(struct.pack("<I", len(texturenames[i]))) for j in range(len(texturenames[i])): f.write(struct.pack("c", texturenames[i][j].encode("ascii","ignore"))) #write texture data for vPatch in range(numpatches): for hPatch in range(numpatches): for vTile in range(16): for hTile in range(16): # index of texturenames array f.write(struct.pack("<H", textures[hPatch * 16 + hTile][vPatch * 16 + vTile])) # second texture, not used in 0 A.D., so 0xFFFF f.write(struct.pack("<H", 65535)) f.write(struct.pack("<I", texturepriorities[hPatch * 16 + hTile][vPatch * 16 + vTile])) f.close() return True def writeHeightToPMP(filename, heights): "Writes a new .pmp file from the 2D 16-bit integer array 'heights' and a default texture. \ Returns True if it was successful." l = len(heights) - 1 textures = [[0 for i in range(l)] for j in range(l)] texturepriorities = [[0 for i in range(l)] for j in range(l)] return writeToPMP(filename, heights, textures, ["medit_shrubs"], texturepriorities)

Thanks @wraitii, I already implemented .pmp file writing in another scripting language and just need to "copy" it to Python (version 3.5) sanderd17's script already helped me a lot. Perhaps we could make a shared mini library "heightmap_io" (or similar) for .pmp reading and writing? Also grayscale bitmap (AFAIK .bmp is the simplest one) import/export could be included as well as .hgt reading.

@Lion.Kanzen I suggest to also add some black to the transparent parts of the shields such that that they fit to the mosaic. Or make the mosaic a bit lighter and the shields only a littler darker. Anyway, there should be only one shade of red IMO. I'm no artist though...

Now the red color of the shields is much brighter than the one in the mosaic - is this intended? Anyway, looks really nice

Thx, I added the link to the database I definitely have to test it and GDAL as well. Actually looks very promising I just started to learn Python to improve my script from the Expert section in my guide. It already allows you to select a custom height range. In the fist step I want to directly read binary data from grayscale images or .hgt files. The latter is trivial to read as it contains only a collection of 16-bit integers. Actually we wouldn't need GDAL then (though it certainly provides more than file reading and scaling). In the second step the height data would be height scaled and flattened with a gaussian blur. Also scaling to different map sizes should be possible. The textures are chosen according to biome (defined by a "biome" map you have to provide together with the heightmap), terrain slope and height, see my height dependent terrain texturing for an early example. In the last step the height data and the terrain textures are written to the .pmp map file. In the further process the generation of trees and more objects could be implemented. Of course it would be nice to add such features to Atlas as well. But AFAIK it is currently subject to a bigger (GUI) rework, so we may wait for that. I'm also no real dev with programming experience. However I would be interested where the code for the heightmap import is located. I couldn't find it till now. The mountains of your map look really authentic. I'm going to map my home region as well (though terrain probably won't be as interesting as yours)