Leaderboard

It's one of the relatively few remaining planned gameplay features we don't have yet. So indeed, our attention should be turning to it soon Another thing that will change, or should IMO, is the interaction of territories and diplomacy. That is, what happens when your ally expands and takes over some of your buildings. Well currently the territory manager doesn't know anything about diplomacy, so your buildings will start to decay as if they were in enemy territory, but I would argue that shouldn't happen. There is also the possibility of building some things in ally territory. Really, there's a lot that can change once we have the code in place. It won't be 100% realistic because that's not our goal, rather a balance between historical accuracy and what is most fun and challenging.

Crucifixion A technique of crucifying: Another technique, although it is argued that this might not actually have been used, and that the deformations were simply the result of contortion before or after crucifixion. Crux Simplex (single wooden pole):

Hello, I am a new player to the game 0A.D. and my group of friend, around 20, are starting to play! Hope to see you in the mutiplayer lobby!

You need to import my models X) yours are not unwrapped. Anyway, going to bed Goodnight.

Looks good =)

Very nice. How does it scale with multiple players? If more players cause more gc time in a linear way, we could give 5ms per player per turn maybe?

Looks good to me =)

I've had a look at incremental GC. Incremental GC allows splitting up the garbage collection into slices and JS code can run between these slices. It doesn't make garbage collection faster in general, but it should avoid big lag spikes when too much garbage collection happens at once. SpiderMonkey uses a Mark-and-Sweep garbage collector. First, it marks garbage in slices (that's the incremental part), then it sweeps everything in another thread. It was quite a challenge and I wouldn't have a working implementation yet if terrence didn't help me on the JSAPI channel. He also opened a bug to add some more documentation. It looks like it's not yet figured out how API users are meant to configure incremental GC because Firefox accesses it quite directly. Anyway, I implemented a quite simple logic. If no GC cycle (the whole GC with multiple slices) is running and if the JS heap size has grown more than 20 MB since the last GC, we start a new incremental GC.We run the incremental GC in slices of 10ms each turn until it's done.The numbers can be tweaked of course. The part of measuring the heap size since the last GC isn't quite accurate though. What it actually does is setting the last heap size to the current heap size if the current heap size is smaller. That's because I didn't find a way to detect when the sweeping in the background thread has finished. So after the marking has completed, the heap is shrinking because the sweeping is running in the background. Here is a graph showing GC performance. I had to change the profiler to print the exact values each turn instead of printing an average over several turns. I've also changed v1.8.5 to run GC every 50 turns because I had to use only one runtime for measuring and the current settings wouldn't have worked. What we are measuring here are the peaks. It's quite a good result IMO, but it's hardly visible on the graph with total performance and with average values (because GC only runs from time to time). Btw. It's not a fault, this time v24 is actually better The next graphs show memory usage. V24 seems to use a bit more , but most of that is probably related to the GC behaviour. The peaks in the end could be because of the way I'm calculation the "last heap size" and because it takes several turns to mark the garbage before sweeping kicks in and actually frees it. Memory overview: Memory zoomed:

I will start making tutorials for blender, when i'm more confident with it. Only real thing I did with it was exporting models, and that Minion on my profile Pic. So my knowledge is limited. I only make tutorials when I fully know something to avoid showing off. Texture is big enough for you to don't have to split it, but you can make two separate ones , just keep in mind that you can't crop the image, only delete the parts you don't want. It would be better that you work on this image only, to avoid errors, and to get used to making textures like the one in the game. Also, you can work somewhere else to do a perfect fit for the texture, and then copy paste it on the one I gave you. Your choice =) If you don't understand what I say I will explain it further.

Hi lion here is what you asked for : - Two Obj meshes fully unwraped - One flat UV to fit your creation in photoshop. I reunited both uvs in one so you have one texture for both, that way the engine won't have to load two big textures. (Resolution is 1024x1024) If someone wants to help Lion you can here is an inverted uv the other has transparency, so you can directly add layers on it. ForLion.7z

Actually, that's my issue. I accidentally committed some experimental/broken code which should be fixed now.

ok guys thank you

Use <Entities datatype="tokens">-structures/{civ}_farmstead</Entities>

Leif Eirikson's saga: the Skálholt map (1570): Grønland ('green land / land of pasture'= Groenland) Helluland ('land of flat stones/slabs' = Baffin island) Markland ('forest land' = Labrador) Skrælinge Land ('land of the savages' = Southern Labrador or St Lawrence Bay) Promontorium Vinlandiæ (the foreland of Vinland=Newfoundland) Vinland (proper) ('land of the vine' or 'fertile land'*= all the coasts beyond Newfoundland: Cap Breton, southern continental New Scotland, northern New England (Fundy Bay))** *: Although Vi-in (long 'i') means 'vine' in old Norsk, some historian see it as a "biblical-like" invention by saga writers (who were scholars) because 'Vin' (short 'i') means 'meadow' (or 'fertile'), a more obvious candidate (and it exists in Saxon and High German where it means 'fertile'). Problem is that 'Vin' was seemingly already obsolete in Norway around 1000 A.D. and it never appears elsewhere in old Icelandic. So maybe, Leif really found wild vine in Cap Breton, such as vitis riparia (shore-vine). **: Archaeological evidences still to be found, but Bay St Lawrence in Cap Breton is a candidate for the Viking camp. http://commons.wikimedia.org/wiki/File:Skálholt-Karte.png