Palaxin
-
Posts
217 -
Joined
-
Last visited
-
Days Won
2
Posts posted by Palaxin
-
-
8 hours ago, WhiteTreePaladin said:
Maybe fields could be finite at first and then upgraded to infinite fields by a technology?
8 hours ago, JC (naval supremacist) said:In my case, sometimes i delete fields near my CC in order to build a castle. So, rather then deleting it, having a temporary field might be a good idea.
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.
-
On 11/6/2016 at 1:47 AM, Eraser said:
The concept may need to be reworked, but I was aiming more at changing existing design to make existing civs to fit in each role, since reworking them would take a lot of time, would break the design docs, and the patch would be too big that it'ld be even harder for the dev community to accept it for improving gameplay than it is right now.
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).
- 1
-
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?
- 2
-
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.
- 2
-
On 10/18/2016 at 0:01 PM, fcxSanya said:
@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
- 4
-
On 7/28/2016 at 9:42 PM, Lion.Kanzen said:
I can make the icons.
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.
- 1
-
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: r18565Known 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, SeleucidsNorth 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, PtolemiesCavalry
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: CityCaparison
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: CityPlate 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: CaparisonMahout
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: CityHowdah
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- 2
-
@niektb: I accidentally followed the Script-Fu install instruction, not the Python instruction. Now it's working perfectly. Thanks!
- 1
-
On 6/7/2016 at 4:02 PM, niektb said:
I assume that you've installed the LayerFX plugin from here: http://registry.gimp.org/node/186 (make sure you install the layerfx.2.8.py and not one of the others).
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 expected0.75x feels like the most realistic game speed to me
- 3
-
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...
- 1
-
18 hours ago, niektb said:
I don't think that that's a workable situation. I mean, first of all you load (bloat?) the players up with mods they might not want. (or at least ourselves since we would need to package, test and support all those different bundles.)
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.
17 hours ago, feneur said:It might be a good idea for us to host a mod list where mods can be found regardless of where the mods can be downloaded from. Maybe with a simple up/down vote system to make it easier to find popular mods.
Agree
-
On 6/6/2016 at 5:44 PM, wraitii said:
I wouldn't use a function if I were you and just use global variables
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.
-
1 hour ago, feneur said:
Or you could just restrict which maps are shown based on the selected victory condition, and/or vise versa? It's probably better the more flexible things are though, so the more maps that can support the more victory conditions the better.
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
- 2
-
Quote
which means he can be a useful link between the main game development and the mod development
@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...
-
17 minutes ago, wraitii said:
I don't understand your question overall.
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
-
13 hours ago, Garaf said:
Is already an excellent guide
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)
Relics proposals
in Gameplay Discussion
Posted
I think a ticket for relic implementation could be created. Or are there still some design decisions to be made?
According to the gameplay feature table relics are planned for part 1 and could even be an interesting feature for the next Alpha...