FeXoR

OK, thanks anyways. What about the terrain and the tree models? AFAIK they are from 0 A.D. mainly, not sure.

Do you have the unit/terrain/techs/... as export files so one could use it for other maps? I wrote a random map for WC3 so I might also make one with this "mod".

Well, you could host and your mate could join and you could start a game but at the moment you build a wall (and the difference in calculation on both systems happen) an out of sync (OOS) error would occur. I don't think it's this, though, since I think an OOS error would be logged and it isn't.

Prodigal Son: I understood that. Since this is a balancing branch thread (with the aim of maximizing playability for the current implementation - if I got that right) your solution is OK here. What I wanted to say is that IMO it is much more productive to improve the basic game system instead of fiddling around with the current, incomplete implementation that should be replaced in the end anyways (and with it your suggestion). But within this thread you're entirely right (and I was stupid to post here in the first place), so go on

Though I don't really like attack priorities due to the wide range of armor values (if units should be able to attack buildings at all) I have to say in this case it would help. (However, attack priority should come late in the unit AI's decision queue which target to attack at least after "target in range" (for ranged units)) AFAIK in the end units should not be able to attack buildings at all but capture them. So this will not be an issue at all in the end (again, if I'm informed correctly). Is there any place that sums up the targeted gameplay (http://trac.wildfiregames.com/wiki/GameplayFeatureStatus does not provide much information about this)?

Minimum range will never be a solution to anything IMO. As stated several times before: - The minimum range of a ranged weapon is quite small (1-1.5 m) so historical accuracy is not a valid argument for min. range - Min. range causes problems like the chase forever scenario (with equally fast units) (Combined with formations and attack priorities several other issues arise and still will with them redone) So IMO only siege units should have minimum range (from the historical point of view due to their fixed projectile launching angle). The so called "automicro" is a byproduct of the simple unit AI and the minimum range. If the Unit AI would be better it would be an advantage for the melee units (as it should be).

Doesn't wireless local area network cards support direct connection to another card? Otherwise a crossover twisted pair local area network cable would be the cheapest solution.

I'm not much into 0 A.D.s network behavior but AFAIK different CPU architectures (and maybe even different OS) may calculate trigonometric functions differently (which are used multiple times in wall placement). That's just a though but I can't find an out of sync error that would occur in such case so likely that's not the source of the error.

In general we should log the random map seed. Otherwise it's not really possible to reproduce more specific issues (like start position on a hill without a way down). @WellDoneToast: You created several maps. To fix this (Start position on hill without a way down) we need to know which map it was. AFAIK the CTerrainTextureManager message has nothing to do with this (since it's only the texture, not the shape of the ground). (As said above even than it might be hard to figure out what went wrong since we don't know the random map's seed) Concerning the empty map: I have never seen such a thing. The main thing to figure out would be on wich map(s) this happens (so if it's a map bug or a generator/library/export/import/load bug)

IMO there are some things thrown into this thread that are not really connected. Just to name some examples: Problem: Different languages have different word length thus the space needed differs, too, thus the spacing of the GUI elements are hard to set sainly. Solution: Use dynamically sized GUI elements and make font (and maybe icon) size a setting. Not a solution: Change the minimum screen resolution to make things fit for all languages. (This would be like moving into a bigger house because the table you bought didn't fit in your old one IMO) Problem: Gui elements are not distributed well on all resolutions. Solution: Let the user drag the GUI elements (mainly minimap, formation/stance widget, unit widget and build widget) where he wants them in a "GUI setting mode". Use dynamically sized GUI elements and make font (and maybe icon) size a setting. Not a solution: Make the GUI elements fit better on a higher, specific resolution and with it make the game unusable for lower resolution screens. (This would be like excluding 1/4th of earths human population from food supplies to slightly raise the standard of living for about the same amount of people IMO) Another solution would be to generally decrease the space needed, e.g.: Make formation/stance a button (showing the actual formation/stance) that, when clicked, opens a selection for the formation/stance. Something similar could be done with the build widget (Not so sure here, though).

Reducing the towers range is extremely unreasonable since that's what towers are for: The higher point of projectile release enhances both, the range and velocity of the projectile on impact (at ground level). Towers SHOULD be strong at the beginning but should not get as much upgrades (especially offensive) as other units (and be weak against siege at city age) so they get less powerful (relative to other units then accessible) with the advancing game.

Radagast.: I totally agree with your structure (mine was just a rough outline) And I also missed the "orders" that can be given to entities and the "actions" entities can perform (that may also need "states" the entities are in during those actions).

Reply to http://www.wildfiregames.com/forum/index.php?showtopic=17918&page=21#entry297688 AFAICS the structure of Aristeia (version from sourceforge) is like in the main game (and there is not much you could/should do about it). The change in organization of the civ definition has to be done in the main game (and it maybe will initially break some things). I don't have enough knowledge about simulations/the engine to exactly tell how much work it would be to change the civs definition (And maybe add another layer where things are defined ready to use in Atlas but the civs - what can be build/trained and the technologies - are not so the civ definition gets easy in the next layer). Better you implement the changes and search for occurring errors and then offer a patch to the main game's track with good arguments why the change is worth it. For me (as I said to Lion.Kanzen before in a PM) it's a bit early to really work on mods. However, as you work on mods anyway you should take the opportunity to let the main games team know what problems you face as moders and what things would make life easier for moders. (This will likely need much stamina, frustration tolerance and to use the channels of communication the main teams developers use - so mainly not the forum) All the best to you.

From a historical point of view as well as from a moders it would indeed be better to have something like: - Art folder containing all models (and what's needed for them) independent of the civ it's used for.(maybe split in e.g. props, units and structures) - An game content folder containing all placeable things in the game (maybe split in e.g. actors (non interactive), units and structures) Those should be fully defined to be usable already but should not contain technologies or things they can build yet. - A technology folder containing technology definitions including the higher level scripts needed for them. - Tree like structure definition folder inheriting the game content elements to form civilizations/factions by adding things that can be build/researched with each game content type by it's owner. Technologies should work for the "target" game contents like "melee, unit" would only apply to game content with both tags in it. So there's no need to add something like "gets bonus from tech X" for all game content but just add the tech with the target flag defined and it will work for all legal targets. (Not sure how it works as is) This way civilization definition would be extremely simple and adding minifactions too. Mods ofc. should be able to add to/change any of the named things. However, this will involve much work to change to and I don't know if the main game team supports this. (Roughly IMO their point of view is: Though modding should be simple the central aim is to get a game going, which I agree with... though I like generalized structure)

Though I appreciate PPL playing, testing and trying to making the game "more playable" and fun I have to say that the title of this thread "The Official General Feature/Gameplay Thread" is (at least) misleading... (e.g. what does "official" mean here? If it's about the "balancing branch" it's not even part of the original game) PLZ try to keep in mind the big picture...

AFAIK there never was a "viking civilization". It was more like a part of a society made of Balts and Germanic peoples (or perhaps better "initially mainly PPL from the surroundings of the Skagerrak and Kattegat") in a specific part of their life. Many young man followed the "viking lifestyle" for a few years in the hope of getting respected and finding treasures. The majority of this society seamed to consider PPL following this specific way of living for too long criminals or at least didn't welcome their return to the base society very much (Guess because it was hard to reintegrate them into the sedentary society). So I'd see it more like an extended "initiation rite" of a civilization and not as a standalone civilization at all. (As I wouldn't consider PPL being out on the wallaby a civilization) Norse might be considered a civilization and seam indeed to be founded by some parts of the viking PPL - especially some exiled ones (e.g. Eric the Red was exiled for murder). So the exploration (and later colonization) of Greenland by Europeans (at that age) was somehow an act of necessity for the explorers. The European colonists in Greenland are AFAIK what now is considered "Norse" mainly (though there seams to be no strict definition whatsoever). However, this was long after 500 A.D. (986 the first settlers arrived and the colonies lasted for about 500 years). So I fear the image of "Vikings" is more based on legend, tales and rumors than it is based on facts and historical accuracy. Though it might be interesting to have the original civilizations (Balts and Germanic peoples and later also Normans and (Celtic) Gauls) in that had extended knowledge in building small and fast ships able to cross oceans and - on disembark - exploit the local population to trade goods of warfare (e.g. horses) just to use them to raid other parts of the same local population or just blackmail them for stopping their raids this still happens after 500 A.D.: "The period from the earliest recorded raids in the 790s until the Norman conquest of England in 1066 is commonly known as the Viking Age of Scandinavian history. (English Wikipedia)" It's hard to exactly distinguish the cultures since the names (Germanic People, Balts, Normans, Gauls, Celts) most of the times refer to PPL living in a roughly specified region with a roughly defined ancestry with a roughly known culture and often also blur with groups of PPL speaking a similar language. Additionally most of the naming and classification was done by other cultures and not the cultures themselves so we might still be quite wrong with our modern grouping. EDIT: I didn't initially see that this was for a mod, not the main game, sorry. (Still hope this post might help clarifying things)

If the opponent chooses random and the AIs units can't see the enemies CC I'd consider getting the enemies CC and with it (in most cases) it's civ cheating (not very bad but still). IMO the AI should try to make the best of what he has, not specifically focus on enemies weaknesses (especially if, if it was a non-AI player, it wouldn't have the informations for that in the first place). If an AI notices (like a non-AI player also would e.g. by scouting) that an opponent masses a specific type of unit it for sure should adept to that. Is any AI development going on that would work for totally different civs (unknown to the AI scripter at the time of implementation) like needed for civ changing mods?

niektb: While showing a multiplier sounds reasonable it's not very telling because the player meeds to know the incline of the graph at the current position to know what happens if he expands/raises an expansion CC (and the second should never be beneficial IMO). Showing a graph is neither trivial, nor telling (many PPL don't understand graphs and you have to mark the current x) and it will not fit well in the GUI (which is a lesser argument for me but for others it would be a big one). So if done it has to really add some benefit to gameplay and IMO it doesn't (In fact it makes it worse IMO). 1.) I meant a fixed "handicap" multiplier. Your approach always benefits a specific situation and is bad in all others so freedom is less and that's bad IMO. 2.) And longer ago there where many other players stating the overall gameplay is to slow. 3.) Try and error is IMO the last option to learn with. Though experience will always be beneficial OFC hegemonic knowledge is never a good thing IMO. Expansion has to be rewarded (it actually costs much and thins the units per territory contour length so it's risky in the first place) and as is (constant multiplier) assures that. 4.) Maybe for the map designer but not for the player (at least to understand). IMO RTS games are complex enough (with few well designed core features like armor/attack type, physical collision detection/projectile speed/trajectory, damage bonus vs. specific other units, bonus to ranged units based on height and/or (mainly or) other things). Balance the basic gameplay in the end feels much more "free" and rewarding IMO then enforcing specific strategies by arbitrary rules (despite they are much simpler do balance). IMO we already have to many features (like e.g. stance + formations + armor/damage type + damage bonus vs. XYZ + many different civilizations) to be sanely balanced at all. Don't dare to replace balancing with capping (like fortresses and defense towers), arbitrary crippling/rewarding or other stuff that simply takes away the freedom of play and will lead to an/a few "optimal" strategy/strategies (like so many modern "professional" games come with)! (I actually have the feeling the term "balancing" is not really understood by many people - without meaning any offense. One of the few astonishingly balanced games is e.g. Warcraft III (though for sure the focus on heroes might be considered a balance breaker). Very diverse races and an attack/armor type matrix with diverse unit speeds and what comes out is an awesome game.)

Here's the patch for collision detection and as "standalone" as possible: rmgen_collision_detection.diff The entity IDs are stored in the collision grid and are returned if something is to be placed but collides. However, I didn't find a safe and fast way to find the blocking entity by ID (is in g_Map.objects or in g_Map.terrainObjects). So if anyone knows how to do this (without going through the entirety of both lists) or what the IDs are for in the first place, plz let me know. This would be extremely illuminative... EDIT: Like suggested by sanderd17 I'll add a function that can be called with the actor string, the position and the angle to check for collision without actually placing anything (so a temporary abstract object is generated but not placed) However, to generate the obstruction map the collision check has to be called every time an object (with obstruction, checked in the function) was/is about to be placed. It might be better to just log collisions because they are rarely fatal. To know what the entity ID is for would be very nice (in fact vital if e.g. the IDs must be continuous since the above function (as well as not placing "units" because they are blocked by "buildings") will then break things)! The remaining questions are: - What's the entity ID for? - Does the 0.5 m grid catch all units (like e.g. any small chicken)? (It's checked but there might be rarely occurring cases) - How to get an object by ID (For me this seams to need to go through all g_Map.objects and g_Map.terrainObjects and compare the entity ID to their ".id" property which would be horribly slow. If we don't do it too often (the average map contains about 20 collisions) this may still be an option)? A fast solution to find an entity object by it's ID would be not to use "this.objects.push()" to add objects but use "this.objects[entityID] = " and then check for with "if (entityID in g_Map.objects)" (or "if (g_Map.objects.hasOwnProperty(entityID))") and at map export do the same check (and cycle to 150+ undefined objects, yes, but only once so that's OK IMO). Same goes for map.terrainObjects ofc. That's for sure not the cleanest solution but for a clean solution I need to know what the entity ID is supposed to do/ment for!

Something like this is already possible. Depending on the density of trees placed units can walk through or not. Bushes, that grand resources, are also blocking units. To make sure no unit can harvest the blocking trees/bushes actor trees/bushes (non-gatherable non-blocking versions of trees/bushes) could be placed and the terrain below them made impassable. ATM such maps are quite unplayable though because the pathfinder is to slow to find units their way through dense forests (the passable parts OFC).

Proposal for collision detection (THX much Itms for adding template data loading from RMGen): collision_detection.zip ToDo: - Add collision detection for gates - Return the blocking entity IDs (and eventually remove those entities, ATM it just warns then) - Extract the part from Map.addObject() to a standalone function e.g. addObstruction() returning a list of entity IDs it's blocked by - Decide what's to do if something is blocked by something else in general (if such a decision seams reasonable) - ATM it needs quite long to check rectangular objects and (proper) walls are always blocking the adjacent wall parts (So what's to do here?) - Decide what scale to use (ATM it's 1 meter, simulations collision detection is 1/2 meter, terrain tiles/RMGen scale is 4 meters... Larger scale means less precision but faster checks OFC. Scale can simply be changed by changing Map.obstructionGridSizeInMeters) Any ideas welcome!

As said before that's not a problem with walls. And as I stated long before champion cavalry skirmishers are "general game rule breakers" (like Hunnic Tarcans was in AoC but additionally with ranged attacks) due to their crush damage. They are fast, have range, are decent against all other units and especially strong against buildings and siege weapons (in stark contrast to other non-siege ranged units). wowgetoffyourcellphone: I agree with your proposal removing the stone/metal resources from the start locations. For Iberians, however, that would mean they have no such resources inside their walls. Not sure if that would be good or bad. Concerning entities (e.g. trees) in walls: I'm working on this for random maps now that RMGen has access to the entity templates.

- Gather speed dependent on territory size: This would be hard to communicate to the player. Also this makes faster expanding players (usually the "stronger" player) even stronger. 1.) This should be a setting in the gamesetup and only be changeable (from 100% gather speed/health/damage/whatsoever to less) by each player himself. With default settings the "strong" player should win... 2.) Casual gamers also complain about the game takes to long. So that's no argument for me. 3.) IMO There shouldn't be an "ideal" amount if territory or an optimal strategy. Ideal for me would be the freedom for the player to use multiple strategies that are able to win the game with. This shouldn't be "hardcoded" in any way, though, but be achieved by the general game rules, the type of units available (and so a little, but not exclusively dependent on the civilization a player chooses), the map the match takes place and the alliances of the players. 4.) For such specific maps the proposed thing might be useful but this could also be achieved by different amounts of starting resources, defensive structures placed on the map, expansion resources and the distance to the players etc. IMO. So in the end I'm not thrilled by such specific advantage/disadvantage systems that just mean players knowing the game better have an even bigger advantage then without such things and that means an additional disadvantage for newcomers (the opposite of what you are trying to achieve as far as I get it). Also the number of strategies will get harder to balance which I don't like at all. I agree with point 1 (if set before the game starts and not by a system taking into account the "stats" of a player which would encourage deliberate "bad" playing).

In general I like the idea. However, there are some things to consider: - Will maps be easier to create with this (Atlas)? - Will everything be possible with this system that is possible now (and if not it is worth to maintain two systems)? General side note: Atlas interacts with the engine, Random map generation is not. So those parts are entirely different (That's a flaw IMO in the first place but has to be considered). So adding this to Atlas and RMGen (Random map generation) needs different libraries (or better get fused). Whatever is chosen this will be a big pile of work.

Yes, auras are what heroes should be good for IMO and all of the auras I see here are reasonable (might need some balancing but that's for the beta stage). And making heroes sturdy sounds reasonable to me to "simulate" they where well guarded and enable them to actually make use of their aura. (Attack power should be normal though IMO. Just by being sturdier they're allready stronger in combat than any other unit)