Spahbod

One of the most important features of the triggers is that they are "event" based. Adding a trigger component (which is already there) and sending them there won't solve the problem. We still need to make a hook for every event in the main simulation code. So we still need some infrastructure changes. My approach also solves the problem with atlas. It works the same with map previews, where the map maker only determines the name of the script file. Helper functions will certainly be useful. I agree with that. It could simplify the "action" part of the triggers.

I know that implementation of triggers is postponed to Empires Besieged, but it shouldn't stop us from discussing the technical parts here. It is obvious that triggers should be able to change the simulation state. So either they should be part of it, or somehow linked to the simulation code. I think it would be better if we don't complicate the code by using the second approach. My suggestion is this: "Triggers" are JavaScript codes that are run in the simulation. The map maker will also create a "something.js" in the map folder and specify it in the .xml file. In the .js code, there are some overloaded functions like "OnUnitKilled" or "OnTechnologyResearched". The map maker should write the code for these functions to get the intended result (eg. if the unit killed was a hero, the player loses). These functions are actually undefined variables as default. They are called when the event occurs in the simulation code (eg. when an entity takes damage in the simulation code, the function "OnEntityTakesDamage" is called if it is not undefined. A schema: In "promotion.js" ...Promotion.prototype.Promote = function(promotedTemplateName){ ... // after everything is done if (OnUnitPromoted !== undefined) { OnUnitPromoted({"entity" : this.entity, "newentity" : promotedUnitEntity}); }}...In "mymaptriggers.js" OnUnitPromoted = function(data) { // do actions}Another approach would be parsing a new language we have defined for the triggers. They both have advantages and disadvantages: My approach: Pros: Very flexible and powerful: We can change anything in the simulation which means we can almost access anything worth of note in the game. Easier implementation and expansion: It is much easier to implement. Better performance: Unless we want to move the triggers into the C++ side, this approach is one of the fastest we could take. Cons: Too much access to simulation: This means that a badly written trigger might cause the game to crash. Harder for mapmakers without programming knowledge: It won't be easy to create the effects if you are not familiar with the simulation. Parsing approach: Pros: Easy for map makers: We can keep the syntax very simple. Restricted access to simulation: We can prevent the game from crashing/giving oos errors. Cons: Hard to make a good performance parser: It wouldn't be easy to parse the new syntax. Especially if done in js. Limited flexibility/power: Every new event/condition/effect should be added manually. Takes much more time to implement: It is obvious. I think we'd better go for the first one. This way, we might be able to implement the triggers in 0 A.D. Part 1. Also the power and the flexibility it brings is something few games offer (and those that do are usually very successful). To make it easier for map makers, we can create a GUI interface in atlas similar to that of Warcraft III. In Warcraft III, Triggers were defined in a scripting syntax, but it also had a GUI based trigger editor similar to that of Age of Mythology. Those triggers were then translated into the scripting syntax to run. Needless to say that this was one of the reasons it became so successful. A good point is that we can postpone the GUI interface for the next part, but still have triggers in Empires Ascendant.

A problem I found using the system is when I want to translate something like this: "25% faster" It thinks that the "% f" is actually a placeholder for some variable, so it doesn't let me to translate it without using the "f" character after the "%".

Very interesting. I'll look into making a fast implementation of that after the exams.

I personally think it would be a good idea. After all, we already have Mauryans, Ptolemies, and would probably also have the Seleucids.

I mean the empty spaces in the sides. Well, I really don't think it would be related to you being newbie. It is my English that sucks.

I personally like the latest concept more. But I think those extra spaces make it a little unusual.

Unfortunately, no. The current random number generation algorithm has a too low period for this work and in the end we'll have tiled textures again. You can try that. Because the current textures are picked as to be "patches" on the ground, not some standalone terrain. Also some of the textures are intended as "blending" textures and should not be used alone at all. This was done with the current philosophy of random maps (painting clumps of textures here and there). That would be a better idea because in addition to the problem mentioned above, some good textures were omitted from the current list because they did not go with the "clump" philosophy. But they could be very good textures for your system. This is on my list to be changed (to become similar to the system historic_brunno mentioned). Although speeding up some specific maps (islands, anatolian plateau, etc.) and the completion of the new clump placer are of higher priority now. Also the documentation needs another update. the problem with biome.textures.grass is that not all biomes are going to have grass, and some will have more than one such texture. I am thinking of a whole new library with a different approach. Instead of placing clumps of textures, trees, etc. again and again (which is very very inefficient), it will determine the status of each tile only once. In this system the main map file would only determine the water/unique_cliff shape and player placement. The rest will be done in library functions. Still I don't know if I can finish it before summer.

True. Perhaps apart from performance issues there won't be any problem with dense woods (although some biome like savannah may need different levels of density still) The idea itself is not the problem. The problem is with our current textures. They get "tiled" when a large enough patch is created. Also height based textures don't work nicely in all of the instances.

OK I played with the code a little. But There are still problems to be solved. The high tree/fish density is an issue. Height based terrain textures are another one. One way to solve these would be using the existing rmgen functions but that would certainly be awful both in terms of speed and the beauty. I have recently been experimenting with a new kind of placer that looks better than the current "clump placer" but is also much more unpredictable and I still have not determined if it is faster than the current approach. Another way could be using a similar way you used with the height map. Only this time the value represents the textures. For example, values between 2 and 3.5 could represent grass, the ones between 3.5 and 7 dirt, 7-9.5 trees, etc.

Maybe we can also include some constraints in the generation part (lines 197-198) to prevent it from making a very jaggy terrain around the player base. It is also possible to use a larger "beginning" map to ease the matter although it might decrease the current level of beauty. I'd like to experiment with the map as soon as I can get my desktop fixed.

A superbly good approach for a real "Unknown" map (Apart from other potential uses). The part about playability: maybe we could pick the starting locations from the beginning (again, randomly, not some pre-picked ones like the current approach) and build the map around them.

One way to include these "mini-factions" would be capturing their "settlement". When capturing is implemented, we can place some gaia buildings around the map that train those faction-specific units. There could be some defenders too. It'd be up to the player to decide if he wants to capture the building, or destroy it. Maybe gaining some resources by doing the latter. This could add a new layer to the game in which the player has to decide if he wants to be able to train some new units, or he's going to pillage a settlement for a quick gain of resources.

I really think that we should add a "Sandbox" difficulty. Something with 25% gather rate and more delay before the first attack.

Actually for part one, Ancient Persian fits the most. And Middle Persian is still spoken in some central cities by some of the Zoroasterian minority here. But There are enough known Ancient Persian words for most of the simple dialogs we need in the game. Still, I can help with all of the three languages.

The rest of the Greek portraits?

That would be the most humorous game ever made. A game named "Rome 2 Total War" without giving you the option to play as Romans.

FeXoR: Thank you for your efforts. I think we should remove the walls. And add the max player cap for this one. Moving the start locations would ruin the whole purpose of this as a Team1-vs-Team2 map. I'd rather use towers instead. Increasing the available space for players won't hurt in this one. Just that min players should be 2 (gulf). And I think Canyon should have a minimum players of 2. Edit: Just saw that you've done that already.

The latter I think. I find the last option more suitable. Another way could be not to choose a map in that the current player/size adjustment is unsuitable.

I just saw your previous post today so sorry about not being a help on this. But you found it all yourself . I wouldn't mind if the autostart is not limited for people who want to experience unusual variations. About your question, I think it is better not to change the constant. But a new global variable won't be needed as far as I can see. You can write a function that changes the player number list directly and call it on every map and map-size selection change.

I may not be able to do anything serious until early spring (in our calender) because university work is taking some time. So it would be good if FeXoR can do it if he has time. I didn't write the UI, just modified it (I think Brian was the main designer), but I agree that it should be implemented in the JSON files. Maybe an array like this: "MaximumPlayers" : [3, 4, 5, 6, 7, 8, 8], Should be added to the .json representing the maximum available players in each map size respectively (tiny, small, etc...). Gamesetup UI code will remove the extra options upon selecting size. Then all that remains is finding and adding the best max player choices for each map.

I found the core of it at last. The tileclass logic indeed has some problems as it can't handle decimal numbers as radius in "some" cases. Easy fix in the map itself.

OK. I fixed the problem in unknown maps. But it's just a hack and to be honest, I don't know why it worked. The core problem is still there and I am going to find it. The way it appears just in the northern sections of the map and that the lines are always horizontal convinces me that there is a problem in either tileclass or painter logic. Funny that we hadn't encountered them before.

I think I found the cause of the problem. The line (or lines in some cases!) seem to be generated because the painter sees those tiles as "player tile class constraint". I'm not sure about the core of the problem so I'd leave this report just here for now. Triggers are a way other than AI to change the simulation via scripting. As AIs are too specialized, they are of not much use in developing a "dynamic" scenario.

This is the weirdest thing I have ever seen in random maps. Thank you for your report. I'll see if I can find the cause.