FeXoR

I say: Don't limit anything, balance it...

Deep forest may be considered very demanding for the pathfinder because the trees are placed randomly on each tile. That leads to many small gaps which single units can pass but not a bunch of units (in part because of formations but even just because units may block each other). I hope a new pathfinder might do better but I am considering rewriting the tree placement (though somehow it's what makes deep forest unique).

I think it would be good to balance resource gain from markets, I agree. But please don't add more limitations! Use balancing, not limitations (like already are in/planned for fortresses and heroes). It's much more realistic and leave space for player decisions. If many stuff is overpowered and limited everybody will (have to) build them and the variety of play styles decrease...

Opera 11.60

Triple post since I can't enter newlines properly... - Copy and paste seams to somehow ignore spaces (or sometimes add some)...

Sorry for the double post but: I can reach the end of the post with the cursor when editing a post now but entering a newline there enters it somewhere totally different (somewhere at the beginning)

- In the old HP there where 2 different newlines: 1.) "Normal" newline entered with strg+enter 2.) 1 1/2 newlines entered with enter They seam to mess up things quite often (an added newline added space before the paragraph it was entered after or after submitting additional newlines where added strangely). This issue seams to be no more, great job - When trying to edit a long post you could not reach the end of the post with the cursor. This issue seams to be fixed as well - Before and after smilies spaces are added automatically. This issue is still there. In addition a smiley is wrapped ti a newline if it is entered directly behind it. - If the right (next) button of the smiley-bar is presses too often no smilies are in any more (instead of starting with the 1st smilies again). If you then press the smiley button again the bar is hidden, presses again the bar shows up again but still no smilies in. The "show all" button of the smiley-bar opens a new page with the smilies in which seams bad for me because with many topics opened you don't know to which topic the smiley-tab (or windows) belongs to. - I don't seam to be able to change my avatar. "Change" appears at mouse-over the avatar in my profile but clicking does not do anything. Animated gifs does not seam to work any longer (but I can't tell for sure since I can't change my avatar and you said there where an issue with that and they might have to be changed). Plz help me with this one. In general: Good job

The phases will have longer duration when starting resources are lowered. ATM you have enough resources for 10 female citizens (500 food), 5 citizen infantry soldiers (250 food and wood) and the 5 needed buildings (~750 wood). If you start with 250 of each resource only you just have enough for 5 citizen soldiers or 5 female citizens and about 2 buildings. That will slow things down. The final costs of the phases can be balanced if more ingame experience is there IMO.

I think lua is used already in the build environment but I agree to stick with one language in the "binaries" (JavaScript). In general I prefer Python

True, with the build time taken into consideration houses may be balanced ok. But in general the game is not balanced at all (but I think you agree though perhaps not in the parts I have in mind but that's a thing for the beta phase IMO) BTW: I updated my latest post while you wrote yours. A bad habit of mine x)

Having two types of houses that AFAIK are: Cost 150 Wood/+10 pop cap and Cost 100 Woods/+5 pop cap is imbalanced on its own because the first grants +1 pop cap for 15 Woods the second needs 20 for the same amount. Needing 5 buildings make them a bit more balanced because the hose type with the lower pop cap/wood ratio (bad/less efficient) is cheaper per house and so the needed structures can be reached faster (with less wood) with such civilizations. Iberians start with walls and towers by default (which are city phase buildings) but they don't start in city phase (which I think is good. The walls seam already hard to balance for me). For me most things are not considered "logical" in RTS games so having the goal of being "historically accurate" for me applies mainly to the text and the story told in a game. I could wright a list of 100 items right know that are unrealistic but it's not the question for me. It's a game and it should be fun and on the one hand complex enough to stay interesting for a long time on the other hand not too complex that you can't catch up with what you want to do in theory while the game runs in realtime. So both, realism and historical correctness, don't count for me when it comes to gameplay issues. Those should be clearly separated! Art, text, story and others would be good if historically accurate and realistic (as long noone feels offended by this, well, or at least not too many). But gameplay should be purely practical, easy and intuitively to use and balanced (and we're far away from being balanced but this will be a main goal in the beta phase AFAIK). So for me the phases of a game should have a gameplay impact to have a reason to exist. RTS games are often divided is such phases like building up resource infrastructure, building up decent defenses against a possible counter attack, and than the (main) expand and attack phase. In the German RTS wikipedia side it's described about as I see it.

So here's something concerning Iberians.

That patch may have broken the default civ settings in Atlas. Added a ticket: http://trac.wildfire...com/ticket/1398 Edit: Fixed.

Yes, I know, sry. Thx for the fix!

You don't need to click left and right at the same time. Left click on build button, left click at start of the wall, left click on end of the first wall part and beginning of the second, left click on the end of the second wall part and the beginning of the 3rd, continue until you are finished, right click to break up. I still don't mind if shift has to be pressed or it's build further as default. What I mind (though a little off topic) is that placing a new building foundation with the shift key pressed shouldn't actually send the selected units there if they already got a build command. Just the foundation should be placed and the units should continue finishing the foundation they are send to/working at already.

If a random map is generated with Hellenes (which is the default in Atlas) or Thebans as a players civilization selected it states a warning similar to: WARNING: Invalid or unimplemented civ 'hele' specified, falling back to 'hele' This is of cause bad. Here is the fix that now falls back to 'rome' and skips the test against g_CivData[civ].SelectableInGameSetup (added a comment) since in the game the races aren't selectable anyways and in Atlas they should work for testing reasons. civ_fix_2012-5-9c.zip (rmgen libs) However, the default selection in Atlas should be changed to Romans for example as well.

I agree but ATM I feel like building further automatically and break with right would be the way to go. But I think both makes sense.

Yes, I was told in the chat, NP, was just a little nervous that something might not always work properly but it's ok. No errors should occur and if the walls doesn't always look well we can just tweak the arguments Thx!

Removed all unneeded code. If Iberians got towers only they'll now get 7 instead of 5: iber_wall_civ_bonus2012-5-7.zip

If they deal piercing damage they already deal very little damage to siege engines because of high piercing armor of siege engines. Ranged units have less armor and health compared to melee units but I don't know if that makes up for the range (didn't check the attack speed yet). So it might be OK in the end. It's mostly the Iberian ranged mounted elite unit with crush damage that seams a bit strange to me. It's more like a siege weapon but still effective to units due to their low crush armor. I think units in general should have higher crush armor and perhaps the Iberian elite mounted ranged should have a piercing attack and attack bonus against buildings. Tweaking the piercing armor of buildings should be possible so that the 'fire arrows' deal enough damage but normal piercing units don't. Still the higher crush armor for non-siege units would be good because until now 'catapults' can take about 5 times the numbers of melee citizen soldiers, which seams quite unrealistic to me and means they are more cost efficient than normal units and have range and can attack everything.

Hm... cavalry skirmisher does not only have a very nice resource cost ratio of 2 food, 1 wood 0 metal, they also got no units with dammage bonus against them, are fast and ranged. Only disadvantage: Cannot damage siege weapons well. Even worse: Iberians ranged mounted units deal crush damage so they rape sige units as well! And Iberians are not rushable because of there walls so it's quite likely for them to get a fortress to produce these...

Recent changes in misc.js (starting entity placement including civ bonus start walls for Iberians) made me notice that functions are not that perfectly named, organized and written in general (e.g. the order of arguments and the arguments taken at all). I added placeCivDefaultEntities(fx, fz, playerid, angle, kwargs) to make starting entity placement suffice Mythos_Ruler's request here (It includes further infos and possibilities for Iberian wall placement as well). That function now (in most maps) replace createStartingPlayerEntities(fx, fz, playerid, civEntities, BUILDING_ANGlE). He added my files to the repository after some discussion but I'd like to exchange some thoughts about that and the rmgen libs in general I added keyword arguments to the function so edge case usage doesn't require all possible arguments (don't know if that is a usual practice in javascript though) and avoid the need of changing all random maps when a new feature is added (only the libs has to be changed and the maps using the new feature). As you might already have noticed the new function doesn't take the civEntities as an argument (they are got inside the function itself by playerid). That makes the starting entity placement a 'one liner'. In some cases (like used in random map fortress) the civEntities might need to be adjusted though (the number of units or even the unit types). This could now be added as an other keyword argument (but actually isn't). Well, it was somehow unexpectedly added (for me it was rather a demo version than something to commit) The naming should IMO always start with 'place' if something is actually placed, that's why the different name (and to stay compatible to custom maps maybe out there at least until some ppl agree with the concept I left the old function as was). But in the end there should be only one function for starting entity placement IMO. The placement angle should be a kwarg, too, and default should be the (strangely named) BUILDING_ANGlE IMO. So please let me know what you want have changed in the near future so no log-spamming and in the end maybe even unwanted code winds up in Alpha 10... Until then I'll further check the default Iberian wall placement function's especially a 'while' loop that caused an out of memory error (infinite looping) in an earlier version when random seeds where much lower/higher then average. I think it's fixed in the actual version but I better check again...

To reduce the number of gates (entries for now) just reduce the number of corners in rmgen/misc.js line 200. They where set to randInt(5, 10), changed max to 7 so perhaps it's ok already. If you like more corners but less gates tell me so I can drop every 2nd or so (though with 5 corners min. there might be only be 3 gates and them ending up in the woods of the random maps would cause the player to be trapped). The default fortress radius should definitely not be larger! Just raise the fortress radius in rmgen/misc.js (iberWallRadius line 193) and load a few maps. There's just not enough space on most. However, I can easily add an additional keyword argument to make the radius adjustable for each map (though I doubt this will be largely used). I dug out the old code for more organic looking fortresses and adjusted it a bit. I got the size more stable at the same randomness. Added it and it can be setup in line 203 of rmgen/misc.js. They are closed by a linear wall so not all parts of the wall are bended. I'll try to reduce the length of the linear part further. I replaced the entries with gates just to show how it looks. I will change them back before committing ofc. To make them playable just replace 'gate' with 'entry' in rmgen/wall_builder.js line 634 (for irregular polygonal fortresses) and for the others in rmgen/misc.js line 203, 206, 209 and 212. Since there are 4 shapes working fine (for me) perhaps the style could be chosen randomly... I'd like that. iber_wall_civ_bonus2012-5-4b.zip Edit: Since it's already in the SVN repo I assume you like it It seams you're not a big friend of discussions However, that was not considered final for me . There is much debug logging left and if we only want to use one fortress shape the other shape's code (documented out anyways) should be removed from misk.js. IMO. I'll post a cleaner version (only the files to update) later somewhere...

Here we go... iber_wall_civ_bonus2012-5-4.zip Best map to test this is the good old "New RMS Test" map. Perhaps you might want to play around with the arguments in rmgen/misc.js line 200. Or try the other possible fortress types by documenting them in after line 200 (and document out line 200 itself ofc.). Concave angles are not supported. I did that before but ran into problems making the last wall entity fit. It would need some tries to get a well fitting fortress and sometimes walls crossed (when random numbers where significant lower than average). In addition it was not really possible to determine the final size of the fortress in any way (only the average size which isn't enough on most random maps). So I abolished that approach.

As I said, it's gone be more irregular. Towers at gate makes at least 10 (if placed in the gap). isn't that a bit much?