wraitii

Looks like that got back it in my latest commit. And it still doesn't happen on intel, so there's something at play here. I'll try changing it later.

I wouldn't use a function if I were you and just use global variables, depending on what you want to do. It's not like it's going to become a huge issue. Alternatively, you could return a tuple with all stuff in it. Or a dictionary, yes. But again, not a python expert.

python 3 recently added the int8frombytes and I find it more readable. No other reasons. Also not an expert in python, far from it. I don't understand your question overall.

Part of the problem is that our map are 16-bit grayscale, which is a bit of an odd format. Using Pillow on Python I used a 32-bit floating point texture, saved in tiff. FYI here's the bit of my script (taken as is), with the useless stuff removed: with open(os.path.join(sys.argv[1],i.replace(".xml",".pmp")), "rb") as f: f.read(4) # 4 bytes PSMP to start the file f.read(4) # 4 bytes to encode the version of the file format f.read(4) # 4 bytes for the file size patchSize = int.from_bytes(f.read(4), byteorder='little') heightmap = [[0 for x in range(patchSize*16+1)] for y in range(patchSize*16+1)] textureTile = [[0 for x in range(patchSize*16)] for y in range(patchSize*16)] # Height,qp is 16 bit integer divided by 92 to yield the real height for x in range(0, patchSize*16+1): for z in range(0, patchSize*16+1): heightmap[x][z] = int.from_bytes(f.read(2), byteorder='little') / 92 numTex = int.from_bytes(f.read(4), byteorder='little') #print(str(numTex) + " textures used.") texNames = [] for texI in range(numTex): # first 4 bytes are texture name length then read the texture name itself name = f.read(int.from_bytes(f.read(4), byteorder='little')) texNames.append(str(name,"utf-8")) #im = Image.new("L", (patchSize*16,patchSize*16) ) #pixels = im.load() for z in range(0, patchSize): for x in range(0, patchSize): for pz in range(16): for px in range(16): texA = int.from_bytes(f.read(2), byteorder='little') #pixels[x*16+px, z*16+pz] = (texA) f.read(6) #second texture (2) + priority (4), don't care #im.save(sys.argv[1] + "." + i + "output.png","png") #im = Image.new("F", (mapSize+1,mapSize+1) ) #pixels = im.load() #for x in range(0, math.floor(math.sqrt(mapSize))*16+1): # for z in range(0, math.floor(math.sqrt(mapSize))*16+1): # pixels[x,z] = heightmap[x][z] #im.save(sys.argv[1] + "." + i + "output.tiff","tiff") #EOF

If you need help with the python script, as part of my markov chains script I have a Python script to load a pmp map which could also be used to write a PMP map if needed.

Should be somewhat trivial to adapt to use in skirmish maps as the "script" part, then you could load it up, open the map on Atlas, save it, remove the script. I agree it would be a nifty Atlas tool also, but I don't think Atlas supports running arbitrary JS, so it'd have to be C++, and that would make it much more complicated to implement. As for creating a more complete map using real markov chains, it sounds possible but I think it'd require a different, more "top down" approach.

1. Only actors, not sure what you mean exactly otherwise 2.It's for SVN (and should also work for alpha 20)

I've been adding more stuff. First thing is I now open the PMP files, which allowed me to sort which actors go over water and which go under (or both), to avoid weirdness. I also added the possibility of adding "rules", for example a map might decide to not add entities around a certain fauna/flora element, or forbid some actors from appearing (useful on volcanic lands for example). Finally I've added a beautifier based on the terrain texture, but it only works on some textures (check out Oasis) so it's not as useful as I'd hoped. It could probably be modified slightly to become a more uniform way of placing actors around a map though. At this point I'm not entirely sure what to add next, so I invite everyone to play a bit with it and see if they like it. Generally speaking I think it looks good, needs a few tweaks. Just download the mod at https://github.com/wraitii/0-AD-RM-beautifier

I don't think a beautification pass like that is really easy to do during the map generation. It might be helped by better integration with the random map generator though. I've kept the work up, now working on adding more "meta" info. I've also added a function to add a given amount of actors, so you can easily set your density. Results at "2","10" and "100".

New comparison screenshot over SVN RM Syria. I'll let you guess which is with and without.

Yes, the script currently loops over entities (and only entities) to add actors (and only actors). Ultimately I think it should also run over actors to add actors. I don't see adding entities working very well overall.

FYI, the mod runs the beautification 4 times when it should really just be run one time, to overdo it. Here are some screenshots from a modded Kerala with no beautification. I added a flag for all added props. As you can see it adds a lot of props, particularly under dense amount of trees. I've also updated the github repo with the latest version of the script and mod. It now takes basic distances into account so the result is overall better.

Added a mod to simply see the effects: https://github.com/wraitii/0-AD-RM-beautifier Just use the beautifier mod. Basically this automatically adds beautification elements around entities. The mod overdoes it so you can see the changes.

Created a Githbub repo for a simple python script that sort of implements this. For now it's very naive and only uses entities as a source. https://github.com/wraitii/0-AD-RM-beautifier/ Sample output: http://pastebin.com/11MLkwTZ

I do not see many real improvements coming unless: map size is increased massively for more realistic scales Walls become much harder to penetrate while other buildings become much easier to destroy (meaning walls become more necessary) Both these things require substantial gameplay changes and code changes. The biggest problem imo is building time.

Generally speaking, any realistic implementation of siege warfare would be too "slow" to work in the game. Unless you went with very abstract things such as a special "mining" ability that just makes walls explode instantly or something.

Hello LittleDev, For your information the current AI developer is mimo, it was previously me (like 2 years ago) and before that a few other people. If you have questions, feel free to ask.

Something like Grass waving requires many many more grass actors than the rendering engine can currently support (test it yourself in Atlas), but the waving isn't a problem: trees already do it. To support that many actors we'll need to have some real instancing which is still a bit out of reach.

Seems like a brilliant change to me, with the caveat Sanderd noticed. For our purpose, maybe make it reach a little less far? It'd probably go into the meshes of buildings too much like that.

Oh god the lag

It would need some testing, I think that might be a bit too much, it really depends. Perhaps a proper implementation would be a separate "pop cap", where different buildings have different values. SO a house costs 1 slot, but a barracks 10 or 5 so you have to decide.

Yeah this color-fade effect isn't handled very well. I think another direction to work on is to base reflections more intelligently on normals. If the reflection vector ends up being "straight up" there should definitely not be a reflection of a nearby object from the map. About depth: I find the idea of a logarithm very interesting.

I think you made refraction too weak at low waviness.

Interesting. Limiting the number of building per phase might actually be an idea I'd like to try.

Yup, you're entirely right. I tried some stuffs to fix that but it just added more problems. I'm quite interested in your patch, looks good. Re normal maps: there are no visual artifacts. There's only a visual "issue" that you see flat reflections instead of seeing what you should see (a mix of water color and sky). Check out this picture, we see very little reflection in the distance, as the water isn't flat. Compare with this. And in-game in the attached picture. It only ever happens at low angles, but it looks very bad on cinematic shots.