Jump to content

Palaxin

Community Members
  • Posts

    217
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Palaxin

  1. 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.
  2. 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).

    • Like 1
  3. 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.

  4. 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.

    • Like 2
  5. On 10/18/2016 at 0:01 PM, fcxSanya said:

    @Palaxin did some progress in this direction, see #3918 , #3778 and #3919

    @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 :unsure:) 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 ^_^

    • Like 4
  6. 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.png

    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.png

    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_256.png

    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

     

    cloth_armour_256.png

    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_256.png

    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_256.png

    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_256.png

    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

    • Like 2
  7. 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.

  8. 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
     

    • Like 3
  9. 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...

  10. 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...

    • Like 1
  11. 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 :)

  12. 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.

  13. 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

    • Like 2
  14. 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...

  15. 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.

  16. .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)

     

  17. 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.

  18. 13 hours ago, Garaf said:

    Is already an excellent guide B)

    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) ;)

×
×
  • Create New...