Spahbod

From what I actually know, our current Carthaginian names are actually Hebrew, as there isn't much information about Punic.

I guess that actually adding the Latin voices (coupled with an announcement) might actually raise interest in this field and help us find more voice actors/translators for other languages.

No. We need mainlog.html and interestinglog.html. oos_dump is for when we have oos in multiplayer games. And more importantly, we need the logs right after the bug happens. If you start another game, the relevant data gets overwritten.

It would have been much better if you could place the logs here.

Fog hides farther objects more. To achieve this effect, we calculate the distance and set the intensity based on it. That's why it would hide the whole map if you zoom out too much.

I know.

It was decided that such a move will decrease our current resolve to improve the pathfinder ASAP. But you can still play the game with 150 pop cap and enjoy it if you like.

Yes. Quite like Rise of Nations' cities. And the possibilities with neutral buildings are vast.

I have a proposal. Neutral buildings would be present on maps, and to capture them, the player should bring their health to zero. In this case, the building will change side and gain a little health. These buildings have a medium attack and are not defenseless. So it won't be possible to capture a lot of them in the beginning of the game. These can be captured by other players from you the very same way. This will make neutral buildings independent of intended capturing mechanism (there are some people against the idea of capturing in general) and simplifies the system a bit. Also, mercenary camps are only part of the potential of the neutral buildings. We can have trading posts (which act like markets but generate more income when part of a trade route), farm estates (which give a trickle of food), "villages" that increase the maximum population cap (which means you can have more than 300 population), buildings that have global auras, etc.

An interesting thing about what you say is that I used to have a very similar phenomenon. It started after about 30-40 minutes and didn't end. But it has not occurred to me again for at least two years. It might have resurfaced by a relatively recent change (as my SVN is probably outdated for quite a few months).

Good to hear it, but as you said, it might not be directly related to reveal map. Do you play against too many AI players? Large maps? It might help us track the core of the problem.

A question: what are the usual settings you play? (map, size, number of players, etc.)

This is known, and according to historic_brunno, might be caused by the game trying to "catch up" huge amounts of lag. But from what you say, it happened even while you didn't have high lag in the beginning of the game so it might be something else.

A note about the current interface and the possible future gui expansion: The current trigger system is based on that of Warcraft III. That game had an utterly powerful but easy to use trigger editor. Each trigger was made up of three main parts: The events, the conditions and the actions. The actions part could also have "if-else" blocks for further conditioning if needed. There was a GUI editor that helped someone with zero coding experience create sophisticated triggers using the structure mentioned above. When saving the map, the editor translated those "gui triggers" into a script that was then run by the game. Those "gui triggers" were also preserved so that the map maker could continue working on it after saving the map. The best part was that it was not limited to this. One could use an option that converted all of the current "gui triggers" into the game-readable scripting syntax, and continue working on the triggers by coding in the mentioned script directly. This way, you had access to some of the game's functions that were not accessible in the gui state. This process was not reversible and you would ultimately lose your gui based codes. It is possible to change each of the events/conditions/actions by double clicking on them. Parts in that are written in blue text can ve changed by clicking on them. This makes it possible for a non-coder to create complex triggers solely useing this GUI interface. My guess is that even in the future, we won't have the time and resources to write a GUI interface that can directly read the game's trigger scripts. The codes are simply too unpredictable to do this. So, we could plan for an entirely warcraft-like trigger system and do not go for an utterly simple interface that actually sacrifices the "coder"'s flexibility for the ease of the "gui trigger maker". We could go for a convenient scripting interface, and then create a gui editor on top of it to use as much of the power of the scripting interface as it can. Still, it can all be converted to the native scripting syntax for further flexibility and access to more features.

I think we won't really be able to use many Non-Roman names. I don't think Greek has "Q" at all. So it'd be quite hard to find a Seleucid related name that starts with "Q".

setFogColor(r,g, b ) You can also use post proc graphics in your maps. Best to check an existing map to see how they work.

Thanks for your help though, it made me clear that it was not (directly) my fault that parts of clOpen was in the water. Also there isn't a texture painted so I get the feeling that something is wrong in the clWater part. Maybe the heights? Right, in addition to lowering the ground, there is another problem. You make the set heightmap "after" you paint the water areas. This means that there will be o water area in your map. To fix this, you should comment out all of your "setReliefmap(myReliefmap);", and write just "one" before you paint the water textures (Like this): //place water texturesetReliefmap(myReliefmap);var placer = new HeightPlacer(heightRange.min, ByHeight[2].height);var painter = new LayeredPainter([tWaterBorder, tWater], [2]);createArea(placer, painter);paintTileClassBasedOnHeight(heightRange.min, ByHeight[2].height, 3, clWater);

I'm pretty sure the problem itself is NP-complete (http://en.wikipedia.org/wiki/Np-complete), Which in short means any algorithm that returns the correct answer will be very slow even for small numbers. Fortunately this particular problem is extensively studied and many good algorithms are devised for it: http://en.wikipedia.org/wiki/Travelling_salesman_problem

I agree with FeXoR about the "usability problems", but only in multiplayer mode. In single player mode, there isn't going to be a real problem with this and in fact, AoM only had such a selection screen for single player games. Although we should remember that after a player gets familiar with the civs, he really doesn't need to see all of these information for each game. It is like forcing the players to see the intro video of the game because it contains valuable gameplay information.

OK, I fiddled with the code a bit. It seems that these lines in the end are the cause of the problem: myReliefmap = getRescaledReliefmap(myReliefmap, heightRange.min, heightRange.max); // This is risky since it might bring players on another height! setReliefmap(myReliefmap); You basically lower the grounds where there are trees into the water area. Your placers and constraints are working properly. I commented them out, deleted the extra "setReliefmap(myReliefmap);" in other parts of the code, and it worked. It seems that you should change the way you generate the map a bit to fix it.

The road + forest stops at class clOpen just as it should, but strangely it continues in clWater: var placer = new HeightPlacer(heightRange.min, ByHeight[2].height);var painter = new LayeredPainter([tWaterBorder, tWater], [2]);createArea(placer, painter);paintTileClassBasedOnHeight(heightRange.min, ByHeight[2].height, 3, clWater);setReliefmap(myReliefmap);var placer = new HeightPlacer(ByHeight[3].height, ByHeight[4].height);var painter = new LayeredPainter([terrainBase, terrainBaseBorder], [4]);createArea(placer, painter);paintTileClassBasedOnHeight(ByHeight[3].height, ByHeight[4].height, 3, clOpen);setReliefmap(myReliefmap);Strange, since exactly the same piece of code is used. Also it seems that the height is overlapping (since part of clOpen is in the water) You can see it because of the pigs and textures. I guess that clWater isn't painted at all (no sand texture) but why? How are you setting the constraint? "createArea(placer, painter);" will set the constraint to "undefined" and that means there is no constraint. Unless you have changed more parts of the code, you should instead use something like: "createArea(placer, painter, avoidClasses(clWater, 0));" Edit: To also paint a tile class, you can use this: "createArea(placer, [painter, paintClass(clSomething)], constraints);"

It was actually a menace, because it contaminated water of the wells in a dry region. Although I have only seen reports of its use during the campaign of Bahram Chubin, the Sassanid General, against Hephtalites and even that's not much certain.

That's because the game doesn't support multiple CPU cores yet. So only one of your CPU cores is actually working on 0 A.D. . This is intentional for now because it makes profiling much easier. In the end, we should be able to fix this particular problem.

Another way to reduce the lag is to limit the max population to 150. This is only possible for Skirmish and Random maps though.

Which is what I'm trying to say. Still we are creating hooks inside the simulation code. I never said that we shouldn't have a trigger component. I just said that we need the hooks. Also, OnOwnershipChanged is called in a variety of occasions, ranging from entity creation to death. Are these situations distinguishable from each other? One of the most important parts of the triggers is the "condition" part. For example, we shouldn't have an event named "OnCivCenterCreated". Rather, we should have something like "OnEntityCreated", and a condition block for any condition checks (Is it a civic center? is it owned by player 2? etc.). If not, we are going to create hundreds of helper functions and still lack the flexibility. Also, we should make sure the map maker is able to use his own functions if he wants to do something not present in the helpers. I have ay idea about how to implement the conditions in the approach you are suggesting. If they can define the function that is called by the trigger themselves, they'd be able to merge the "condition" and "action" parts (The first code snippet). But in general we could make it like the second code snippet: //In the map's trigger part:var cmpTrigger = Engine.QueryInterface(SYSTEM_ENTITY, IID_Trigger);cmpTrigger.OnEntityCreated(MyOwnFunction);MyOwnFunction = function(data){ if (something) //do the checks yourself { //actions, including the ones that can be accessed using the helpers }}...//In trigger.js:cmpTrigger.OnEntityCreated(action){ //it listens to messages as you suggest or is directly called by the simulation code (for eg. in builder.js) //in any way, we get two entities: the one that was created and the creator (building and builder, trained unit and the barracks, etc.) //and we call the action action({"createdEntity": entity, "creatorEntity": creator});}//In the map's trigger part:var cmpTrigger = Engine.QueryInterface(SYSTEM_ENTITY, IID_Trigger);cmpTrigger.OnEntityCreated(AHelperFunction, AConditionFunction, otherData);Again, it would limit the flexibility, but still it is easy to understand.