FeXoR

Yes, yes, I'm often going to far, you're right ^^. But basically that's what I was proposing: Maximize the distance in color space for all kinds of color blindness (with higher respect to the more common ones). Making it dependent on the number of players would "only" need 7 pallets (2-8 players) that than are available. With many players it will still be hard but for a lower number of players that should be quite easy. At first glance there are at least 4 colors that can be differentiated between by all (non monochromatic) color blinded (and named as well for in-game communication): - dark red - light yellow (shifted a bit to orange) - light blue (between blue and cyan) - dark purple (more like blue shifted a bit to purple but looks purple to me) (And I like those colors) Though red (or purple if shifted to far to pure purple) will be seen as gray by some they know what color it is because it's the only gray. Adding the colors name to be shown in the game setup screen might be still helpful for communication later in-game. Why not use green? Because some see it as yellow while others see it as blue (the two most frequent color blindnesses). So it would sort out two other colors. Any experienced person here to show examples for 5-8 color pallets? (I certainly wouldn't mind if those for higher numbers of players look not that cool cause it's not the common case anyway. The main thing is they work for 97.5% of PPL - meaning Monochromacy and Dichromacy might be ignored for 7 and 8 player pallets. If the color 7/8 color palates look too ugly we can still ignore color blindness in this cases IMO. It's hard enough for a non-color-blind to differentiate 8 colors with blending on the mini-map). Other helpful resources might be: http://www.daltonize.org/ http://jfly.iam.u-tokyo.ac.jp/color/ http://unm-bioblog.b...-blindness.html http://mengbomin.wor...resting-points/ http://www.mrexcel.c...nd-viewers.html http://colorschemedesigner.com/ http://www.disturbmedia.com/max/colour-blindness.html (Including HTML code to simulate color-blindness) (Off topic: I stumbled over this one on the way: http://3.bp.blogspot..._viruscomix.jpg )

You have a very positive idea of humans (which honors you) ^^. I'm quite sure, though, that this will not work in most cases. Finding 8 easy to notice player colors is hard on its own if blending like in the mini-map is involved IMO. What about distorting a color space in a way that less easy to differentiate colors occupy less space in it (for normal users and all forms of color blindness) and then leaving the color to take to the player (while removing an area of size and shape hard to differentiate from a player color already present). That way it should be possible to be about optimal. It may be hard though to find the optimal distortion function as well as the shape of the removed area per present player colors (I guess it would be more a star or a cross instead of a circle). If we would grand a player the option to pick his "type of color blindness" (with default set to "None") in the player options and have color space distortion functions for all types of color blindness (including non-color-blinds ability to differentiate colors) only those functions needed could be applied to the color space (The shape of the removed space might as well depend on that). Another possibility would be to calculate the optimal player colors for a given number of players (or just be picked by a person experienced in it).. I don't think it's that hard for up to 4 players (+ gaia and ground textures) but for more players it will get harder. If the number of players change all player colors would be change then. So problems are much easier to avoid with less players (which indeed might be the more common case). For non-color-blind it would be something like this: http://en.wikipedia....LMS_color_space It should be easy to determine those functions for color blinded because they generally have the same wavelength they can see just one of them is missing AFAIK. So if not two kinds of color-blind PPL enter a game you have still tree dimensions in the color space (Hue (determined by players ability to see colors), Colorfulness and Darkness/Lightness) Other resources: http://en.wikipedia....ute_color_space If the psychophysical color space is understood well enough it could also be taken into consideration. (It's funny: Though I'm not aware of any color vision deficit I fail the "Test for deuteranopia" and "Test for tritanopia" in http://en.wikipedia....Color_blindness)

Yes, thx! My concern within that ticket is fixed now. Not entirely sure about historic_bruno's one though. Maybe, however, everything is fine now ^^. Thx! EDIT: Thx for adding http://trac.wildfiregames.com/ticket/1855 , leper!

In Germany e.g. you buy the right to use the software - as long as you like. You have no right to change/distribute the code or to get support for an eternity - but you have the right to use it (and so it must work at least theoretically). If you can't use it any more because steam decides not to support it any longer this right is not granted and thus the sale is not consistent with the law. Additionally you are free to decide what support you accept and what you don't. But steam only supports the version up to date.

zoot, it's the math.round that does that. As said in the last post integers (for percentage damage reduction) give only sane values up to armor 25 or so. If the calculated damage reduction is not rounded but changed to float, however, it will work much further (about 5 times as much armor per additional decimal precision so 32 bit float values would allow 2M armor [5 ^((2^32)^0.1) ~= 2649998]). Armor 101 reduces the damage compared with armor 100 by the same amount than armor 1 would compared to armor 0 - the unit gets 10% less damage: Armor 0: 0.9^0 = 1 Armor 1: 0.9^1 = 0.9 Compare armor 1 to armor 0: 0.9 / 1 = 0.9 <- gets 10% less damage than before. Armor 10: 0.9^10 = 0,3486784401 Armor 11: 0.9^11 = 0,31381059609 Compare armor 11 to armor 10: 0,31381059609 / 0,3486784401 = 0.9 <- gets 10% less damage than before (Though the % damage reduction only changes by 3.5 percent points but that's exactly the idea) And it will be the same for armor 101 compared to 100.

Steam is a no-go IMO. It breaks the law in many countries especially the right of usage of bought software (that with steam depends on the settings of the steam servers, not the setup of your system).

Added a patch to also make them available to the RMGEN lib wall_builder.js and added them to the RMS "Wall Demo": http://trac.wildfire...com/ticket/1855 They look very nice! (I also noticed that Hellenic defense towers now have the entrance on the correct side. I added a ticket for this some time ago but can't find it any more (maybe it was changed). If someone finds it plz let me know, thx).

That's another very nice thing with exponential armor increase: There is no limit in armor "level"! And it always reduced the same amount of damage compared to the last level no matter how high it is (of cause only if the accuracy of the calculation allows it. Even integers would give a reasonable accuracy until armor 25 (93%). Changing to float values would be good though). That's not necessarily true. If damage scales the same way per upgrade this would work too. Just the hitpoints would look poor compared to the extreme damage that would be dealt then. Still units would need the same amount of hits to kill each other due to the extreme damage reduction on the other hand.

Sry, zoot, forgot to point out that in general you are right: Armor is more like subtraction than multiplying (with a number smaller than 1) the force of an attack (in context of games referred to as "damage"). How balanced a game is on the other side mainly effects its "playability" IMO and with it the amount of fun playing it grants. So making it "easy" to balance to me is equivalent to making it more fun. I like fun games ^^. I don't have any objections though if anyone wrote a physics engine and abandon all the game rules that got obsolete with it! I just don't think that will happen... (On the second thought I can't remember a game based on a physics engine - e.g. total annihilation - that was as much and as long fun to play as games with a more "synthetic" ruleset - like Starcraft, Warcraft 3 or Age of Empires 2: AoK/AoC)

What should "upgrade 10% of this armor" mean? That's what this discussion is about. In WC3 "add 1 armor point to every unit with this kind of armor" exactly means "reduce the damage compared to the damage done before the upgrade by 8% (to every unit with this kind of armor)" (in our example it would be 10%).

In reality mechanically "dealt damage" (so not considering lasers or nuclear bombs) and the "reduction" of it by other material depends on the force divided through the area it is focused on and the absorbing materials hardiness to be deformed. So for weapons of the 0 A.D. time-frame that would mean piercing weapons might deal less damage to a body but get absorbed much less by armor also. It indeed extremely depends on the angle an attack hits because the absorbing material might be a lot thicker in that direction than it's thickness normal to it's surface. Such complex considerations might be helpful for RPG/H&S games but due to a lot harder balancing it seams unsuitable for RTS games to me. Besides: It is hardly intuitive that the damage dealt to a catapult is considered when hitting the catapults wooden frame (like it is considered for armor values as it seams). I pretty much doubt that (non-fire) arrows where used to destroy the catapult but to kill the operating crew. So the armor values of catapults against piercing attacks are much to high IMO. On the other hand an axeman could disable a catapult with a single blow by cutting an essential rope. So non-tank mechanical units are quite vulnerable to attacks - that's why they where heavily guarded.

I think showing the armor value (that might seam arbitrarily to some PPL) and the percentage damage reduction would be fine for most PPL like: Armor (Damage reduction) 1 (10%) 2 (19%) 3 (27%) 4 (34%) 5 (41%) ... Only showing the armor value in the GUI and the percentage damage reduction in the tooltip/mouseover and adding an explanation to the manual would do IMO. Note that Warcraft 3 was and is a very popular game and uses that as well. Most players are not at all interested how a game works in sense of game rules and are just happy when they works fine. They don't notice/care "why" it is fine in most cases IMO (sorry if I do the gamers wrong but that's my experience). So focusing on good game rules while making the GUI as informative as possible and explaining them to interested PPL in the manual seams the best way to go for me. The game rules should not depend on the average understanding of math but on the fun PPL have in average playing this game. Most will find out by try how the game "works" anyway rather then calculating everything before actually playing.

Another advantage of exponential armor increase by upgrades is that balancing applies equally despite the level of upgrade . So a specific unit 2 times as strong against an other specific unit will exactly remain 2 times as strong against that other unit if both got the same number of upgrades (This only exactly fits if the units have the same range because higher armor favors melee while higher damage favors ranged units, just to mention that side effect). Same with attack upgrades if done exponentially.

It just came to my mind that an AI saving it's data to evolve over more than one game will break sync in multiplayer games if the data (in this specific case the rules if I get that right) are not shared before the game starts.

IMO that aproach would still be static in code. Just the data the code uses change. To get dynamic code with C++ would mean you'd have to compile during runtime. In that sense uncompiled/JIT-compiled languages seam the right decision to me if "dynamic code" is indeed the aim. So Yves question seams quite relevant. Could you tell us a little more detailed what you intent to do, agapsguy?

In AoE 2: AoK/AoC playing together meant you are indeed considered one player - just you share control of that player. That doesn't mean you are weaker than 2 separate players though. The game is complex enough to be efficient enough together as one player. How the two players arrange responsibilities should be their decision IMO.

Thx! Good to know. I thought mods where js exclusively and since AIs are part mod/simulation it would not really fit into the design.

Hi and welcome to the forum What you want to do is at least ambitious as well as problematic because it does not fit to the overall design with mods and simulations (both done in js) AFAIK. It's for sure possible though. I have no overview of the files you'd need but CCmpAIManager.cpp seams like a good point to start as zoot.stated. For more detailed information you might want to visit the development chat and ask there: http://webchat.quake...hannels=0ad-dev Good luck with your project and have a nice stay.

Where is it (I can't see any download link)?

Perfect! Thx for letting me know Recollecting issues on random maps (to get an overview about how helpful player restrictions would be): Legend: Connected to number of players to map size ratio. Connected to wall_builder.js in general or specifically to Iberian Civ bonus defensive structures. Connected to not enough space for players bases Not really RMS related General issues: - Iberians on Tiny maps (General issue): By default tiny maps don't grand any defensive capacity to Iberian players. Fix: Only changing the start positions (so they are at least 20 tiles away from the map border) and add player caps can help here IMO so there is enough space to place the Iberian Civ bonus defensive structures. - 8 Iberians on Small maps (General issue): Iberian Walls are to close to each other (shooting at each other right from the beginning of the game). Fix: Only player caps would help here IMO. - Entities inside walls obstruction (General issue): Walls placed with wall_placer.js functionality may be placed on trees. Fix: Grand RMGEN access to the entity templates, add a "remove entity" function to RMGEN, add "remove obstructed entities" to wall_builder.js. - Walls in unreachable areas: Sometimes Iberian walls (or walls placed with wall_placer.js in general) may wind up on cliffs or in water. Fix: Grand players enough room for the walls (20 tiles radius) on Small or bigger maps (Irregularity of the wall still might cause issues). General fix: Make the wall builder check if walls can be placed in that area. For that RMGEN would need access to the entity template data and information about how step the terrain can be to place buildings. - Many RMS take long to be generated (historic_bruno thinks that is a big issue). Fix: More or less complete rewrite of all RMS and eventually the RMGEN API as well (I think this might help but is also a little drastic. Current RMS have issues but are far away from being unplayable). Map specific issues: - Aegean Sea: Unreachable trees on islands. Fix: Check in the Unit AI if target is reachable. - Alpine Lakes: Iberian Walls reach into cliffs and lakes. Fix: Grand the players more space. - Alpine Valley: Iberian Walls reach into cliffs. Fix: Grand the players more space. - Anatolian Plateau: OK. - Archipelago: Not sure how it should work. - Ardennes Forest: Iberian Walls reach into cliffs. Fix: Grand the players more space. - Atlas Mountains: Iberian Walls reach into cliffs. Fix: Grand the players more space. - Belgian Uplands: Iberians get no Civ Bonus defensive buildings. Fix: No idea. The map is not always fair. "Fix": Add a category for random maps that are not as balanced but more realistic or random than the "standard" RMS. - Cantabrian Highlands: Iberian Civ Bonus towers are placed on cliffs. Fix: Add a keyword argument to change the radius of the Iberian Civ Bonus to placeCivDefaultEntities() in rmgen/misk.js. - Canyon: This map causes an error when generated with 1 player. Fix: Hunt down the bug in the code. Iberian Walls reach into cliffs. Fix: Grand the players more space. - Continent: Iberian Walls reach into each other on Small maps with 8 players. Fix: Grand walls to Iberian players only on medium and larger maps or add player caps. - Corinthian Isthmus: Iberian walls/circle of towers excess the map border: Fix: Change players start positions. - Corsica vs Sardinia: Iberian Walls overlap each other and wind up in Cliffs. Fix.: Remove Iberian Civ Bonus defensive structures and add player caps. - Cycladic Archipelago: On Tiny maps islands sometimes are connected. Fix: Add Player caps. - Deep Forest: On big maps the many trees cause huge CPU/GPU usage. Fix: No idea. Formations get stuck in the forest. Fix: Fix Unit AI, Pathfinder and Formation functionality. With high player to map size ratios there is not much wood left on this map. Fix: Not really a bug, it's just nut much space left. The numbers of paths could be reduced though. - English Channel: Iberian walls/circle of towers excess the map border: Fix: Change players start positions or make it a rectangular map.. - Fortress: On tiny maps with 8 players walls overlap. Fix: Add player caps. On small maps with 8 players walls are so close to each other that they might shoot arrows right from the start of the game. - Gear: Iberian Walls reach into water. Fix: Place towers instead. Unreachable trees on island. Fix: Check in the Unit AI if target is reachable. - Guadalquivir River: Iberian Walls overlap. Fix.: Change start positions. - Gulf of Bothnia: Iberian Walls reach into cliffs. Fix: Grand the players more space. - WIP... NOTE: I am just summarizing issues and tell how they could be fixed. That does in no way mean that they have to be fixed like I suggest. IMO we have to gather ways to fix them and then decide what to do. Pointing out things are bad but then rejecting a way to fix them without telling an another suitable way to go does not help so please focus on (alternative) ways to fix issues (and at some point we have to agree on something ofc.).

I created it myself (from mods on, no files put there by the game) to test changes to RMS while still having changes applied made in SVN without interfering with my changes. My Games\0ad\mods\public works perfectly, thx. It would be nice though to reload mod data in Atlas if they changes during Atlas is opened. It's not doing that for some time now (long before the path change) but in the beginning reloaded them depending on the last date of change (so if the latest changes where made to the specific file in the 0ad dir this is used, otherwise the one in the cache or hopefully now My Games). It still uses the newest version when Atlas is launched but does not check if a file is changed while running. Reload during runtime would make debugging/designing much more easy. EDIT: Oh! Changes in RMS are applied during runtime of Atlas! Checking RMGEN lib changes... Whow! They too! Thx much for this! Wonderful!

Thx, saw it. I'll not have much time in the next weak but after that, who know I just noticed that RMS are no longer loaded from AppData\Local\0ad\cache\mods\public\maps\random so is there another folder maps are loaded from now (like Documents/My Games or so)?

First of all thanks for the reply. I agree. I think I read somewhere that CPU usage is quite high to simulate (if done, not sure) that a projectile can hit a unit not initially targeted by the unit the projectile comes from. That might be considered as well for a decision here. I'm uncertain about this as well. Thats OK for me just think that picking one of them would do. Good to know. What are the plans to fix this? Give ranged units a melee attack that is weaker that their ranged attack seams bad to me because ranged units then by default fight "imperfect". That seams to be stupid and will result in more micromanagement. In combination with the yet crappy formation behavior it will be a pain for the player to manage. I didn't make myself clear here. I meant 1.) (Physics engine, not many other game rules) or 2.) (Complex game rules, graphics "unlinked" from the game rules just representing the action mainly) not damage/armor type or "bonus vs.". Sorry. Good to here. But it is still planned to stick with orders+stances+formations? That's my main concern. It results in a vast amount of combinations to be handled sanely which seams to be a quite impossible job.

Since I got no response whatsoever concerning player caps on random maps I can only assume that there will me no such thing in the near future. However there are other matters: - Load an RMS (it's js and json) from within another RMS.js (mainly for "The Unknown" maps): So far AFAIk only a hole directory but not a single js file can be loaded from within an RMS.js (with RMS LoadLibrary([Directory to load]) in public/ps/trunk/source/graphics/MapGenerator.cpp line 149) So it would be nice to be able to load a single js file as well. In addition to that the json file has to be reloaded to adjust the settings appropriate to the map chosen by "The Unknown" RMS after or during its runtime. Any suggestions how to do this? I guess we need the agreement of the coding team here as well so please check if they want to do it themselves or if they in general agree to add this functionality at all or what other suggestion they have for "The Unknown" maps to be easier to debug and contain less duplicated code. So if any of the team members read this a comment would be highly appreciated. EDIT: It seams that there are at least 3 ways to do a similar thing (not sure if all of that works as wanted): 1.) Add different "Random" maps in the gui code that then randomly chooses from a given map pool (e.g. "Random Land" etc.). 2.) Add finer categories like "Naval Maps" or such and let "Random" then load a random map of this category. 3.) Add a LoadRms() function in MapGenerator.cpp similar to LoadLibrary(). - Fix the maps so none of them raises errors with any number of possible players and reduce wired things like walls reaching into water, other walls or the map border or towers starting to shoot at each other right from the beginning of the game as far as possible: Canyon: Fix the PathPlacer() function pathplacer.js or see if wrong values are given to it. I used my own functions to generate paths so far so I don't have any experience with this. Better someone else look into this if possible. Iberian Civ Bonus in general: This can be determined as an optional argument to placeCivDefaultEntities() in binaries/data/mods/public/maps/random/rmgen/misc.js line 171 already so only the RMS.js would have to be changed. I'll look into this. If any agreement is needed here as well please let me know.

I'm not sure if this changes are indeed wanted. Please try to avoid assigning a task before this is certain. EDIT: I think the patch is helpful and working as it should. I'm open for changes ofc. Avoiding limitations and trust the intelligence of the user is IMO a good thing, too, so this argument is valid for me as well. EDIT2: I would like to know which decision was made on this matter: - Reject player caps because a number of players to use on the different map sizes is recommended already in the map size description and the host should decide on this basis by himself? - Reject the patch but in general agree to let RMS choose the player caps? - Anything else? - None?