Leaderboard

I created a wiki page (Atlas Manual: Heightmap Import) based on the information in Sander's comments. Any corrections/additions are welcome (one thing which is definitely missing is images (source heightmap and resulting map in Atlas), but I don't have decent-enough-looking ones yet)

Okay, I got hold of a Raspberry Pi 3. There's now an experimental Gallium VC4 driver for the Broadcom VideoCore4 graphics chip in this device. OpenArena runs perfectly as you might expect as it is a common test case and complete. Anyway, there was 0.A.D in the Raspbian repository, albeit an old version, so I thought why not give this a go? It runs! At least through the menus, when you try to load a map it complains in the terminal about GL errors (this is with all effects disabled and quick and ugly water selected and closes. Not bad though eh? The open source driver that I'm using here supports desktop OpenGL 2.1 according to glxinfo as well as OpenGL ES. However I believe the hardware does not support S3TC and only supports... EGL? Whatever the compression Android uses is. Just thought I'd leave this here for someone to enjoy. Kind regards.

Here's the important business from the Terminal: ERROR: CRenderer::EndFrame: GL errors 1285 occurred WARNING: Fancy Effects framebuffer object incomplete: 0x8CDD GL_OUT_OF_MEMORY OpenGL error(s) occurred: 0505 GL_INVALID_VALUE OpenGL error(s) occurred: 0501 Draw call returned Invalid argument. Expect corruption. Segmentation fault I've currently got 64mb VRAM set so I'll increase this and see if it helps. I remember it also not working at 224mb though... Also left a post over at the Xonotic forums for DivVerent who created S2TC (the free encoder/decoder for S3TC) as he might be able to help me come up with some on-the-fly decoding solution for the S3TC textures 0 A.D uses. EDIT1: Here's the link: http://forums.xonotic.org/showthread.php?tid=6080 The game crashes with any VRAM amount set. I think it's not just a texture problem because on the OpenMW forum they found that their game DOES run but with pink shapes: https://forum.openmw.org/viewtopic.php?f=8&t=2850&start=10 I'm going to do some more research over the next few days and see if it's bugs in the driver, handling shaders, etc. Does anyone have a low resolution texture pack for 0.A.D I could try?

Would the easiest thing right now simply to be to implement uncompressed textures and different texture quality modes? I'm sure there's a way to force ETC on the VideoCore IV. I'm going to fire the Pi3 back up again later tonight and copy the error messages in here. Does anyone else have experience of compiling 0A.D for the Raspberry Pi? I'd like to test with Alpha 19. Also, when the game crashes where does it store crashlogs? Kind regards.

Text and image source http://resources.woodlands-junior.kent.sch.uk/townhistory/saxontonbridge.html

I'm sorry to be rude, but you have no idea what you are talking about. :-) Display block (not black) is perfectly valid. It is in fact the default display style the div element. Setting it makes other elements behave like div's do. And as noted above, 'em' is a very valid unit of measurement. It is relative to the font size used on the page. Meaning, if the user configures a larger font in their browser, the whole page scales accordingly. For accessibility this is recommended. There were two problems, both fixed. One was that the element that contains the logo & menu, had a fixed height. Since the elements inside it are floated, they can float outside the height of the element. The height was removed and an element was added below that clears both left and right. That solves that. That added the problem that whenever the elements are compressed and take up more space, the height of header increases, but the content keeps the same top margin, thus falling under the header element. I fixed that by giving the content a top margin depending on browser width. Thank you for letting us know! :-)

There is a ticket for Android support, which also add support for other texture compression format: #2996. Someone should rework it, adding some format supported by vc4 or using uncompressed, scaled down texture where not supported (alpha images).

Update. Changelog v1.3: Balanced the number of resource spots Added metal and stone resources in Karpasia area (northeast) Added visual hints to reach Morphou bay Added resources in Morphou bay Improved roads appearance Minor visual improvements Hints:

I have some pseudo code: Trigger.prototype.RipostCheck = function(data) { // Now every time some entity changes ownership, this function gets called // and you'll get an JS object 'data' with some variables inside, with the following lay-out: // { // "entity": entityId, // "from": playerId, // "to": playerId // } // What you need to do is to check whether the right entity is in the event, like this: if(data.entity == 483) && (data.from == 2) && (data.to == 1) { // do something } }; cmpTrigger.RegisterTrigger("OnOwnershipChanged", "RipostCheck", {"enabled": true});

The data for the RegisterTrigger is just a boolean to enable (or not yet enable) the trigger. See the "accepted data" on the table of the triggers page. Only some special triggers require extra data. And you also didn't put the data inside the function call. So you have to make a trigger that listens to every ownership change (note that this also includes creation of new units, as they change from no owner to a valid owner). Then in that function do the checks you want based on the returned data (the data you have as function argument). That data will include the entity id (which you can compare with a hard-coded ID, or query other things from it). And also the from- and to-ownership. In the function, it will also not know about a time variable. Perhaps it's better to only enable the trigger after a delay (so first execute a delay function, then register the capture trigger in that delay function). Or you can query the current time from cmpTimer. So something like var cmpTimer = Engine.QueryInterface(SYSTEM_ENTITY, IID_Timer); cmpTimer.GetTime();

@AtlasMapper: these specs you quote are not quite accurate, you need a fairly fast system to run the game fluently with multiple AI's.

very slow, may be stalled.

Unit formations should make a huge impact in 0 AD, if people don't want this to feel like another Age of Empires game.