FeXoR

When I made the request to add this functions I thought of (though I didn't clearly say, sry): With 2 given points (witch also can be interpreted as vectors from [0, 0] to this point): point1 = [x1, y1] point2 = [x2, y2] getVector(point1, point2) returning the vector from point1 to point2: [x2-x1, y2-y1] getDistance(point1, point2) returning the distance between 2 points: Math.pow(Math.pow(x2 - x1, 2) + Math.pow(y2 - y1, 2), 1/2) getAngle(point1, point2) returning the angle between the vectors to point1 and point2. getDirection(point1, point2) returning the angle between getVector(point1, point2) and and a vector directed where a unit faces to when placed with angle = 0. Since we agreed to use z as y it would be getAngle(getVector(point1, point2), [1, 0]) with counter clockwise rotation with growing angle (as far as unit placement is done this way too). And, yes, as I use the function now it's the angle of the line between the 2 points towards the coordinate system.

When the angle of unit placement is fixed, add a post, too. It effects my wall_tool for example and that has to be fixed then. Luckily I did all the angle stuff in one function so only 40 lines of code to watch Though sin( getAngle(1, 0, 0, 0) ) is -1, not 1 but everything seams to be in order!

I totally agree! Balancing should be watched at this stage to ensure high playability when hitting beta. However, some things like 'allowed targets' can make a huge difference and are not implemented fully right now as far as I know.

Thanks for the fix. You are right, kept x/y2 = 0 which was wrong. Need to keep x/y1 = 0 to see against which axis it turns. Fixed the values for BUILDING_ANGlE in my post that I got wrong 1st. Edit: There's still something strange (from mainlog.html): getAngle(1, 0, 0, 0) = 3.141592653589793 <- Should be 0 or? getAngle(1, 1, 0, 0) = -2.356194490192345 getAngle(0, 1, 0, 0) = -1.5707963267948966 getAngle(-1, 1, 0, 0) = -0.7853981633974483 getAngle(-1, 0, 0, 0) = 0 getAngle(-1, -1, 0, 0) = 0.7853981633974483 getAngle(0, -1, 0, 0) = 1.5707963267948966 getAngle(1, -1, 0, 0) = 2.356194490192345 (Everything's right from this point on though) getAngle(0, 0, 1, 0) = 0 getAngle(0, 0, 1, 1) = 0.7853981633974483 getAngle(0, 0, 0, 1) = 1.5707963267948966 getAngle(0, 0, -1, 1) = 2.356194490192345 getAngle(0, 0, -1, 0) = 3.141592653589793 getAngle(0, 0, -1, -1) = -2.356194490192345 getAngle(0, 0, 0, -1) = -1.5707963267948966 getAngle(0, 0, 1, -1) = -0.7853981633974483 By the way, generally I agree with you the map surface plane should act like x/y plane. I just guess that when making the engine the clockwise rotation on the plane to design was exactly the idea that made them choose x/z (or more accurate z/x rotated by -PI/4). I think rotation direction is less of an issue for designers to get used to counter clockwise rotation then for people using trigonometric functions and has to figure out where sin/cos belongs and which sign they should have to act as they like. So, yes, it should act like x/y, I agree. OT: Did I mention that I hate the edit function of this forum? x) It often eats my newlines or adds some or adds spaces at the beginning of the line I add one.

Thanks for the reply. I was told in the chat already. Sorry for doing this since it might cause others to do as me, that's not what I intended.

Well, then you have to change the unit angle for placement too to stay consistent. Angle of 0 then should mean facing positive x, PI/2 facing bottom (on the minimap) and so on. The BUILDING_ANGlE then should be -PI/4 instead of 3*PI/4 (Edited, got it wrong 1st) By the way, I use it and it crashes with: ERROR: JavaScript error: maps/random/rmgen/library.js line 620 ReferenceError: assignment to undeclared variable output getAngle(98,86,103,55)@maps/random/rmgen/library.js:620 @maps/random/fexor.js:119ERROR: CMapGeneratorWorker::Run: Failed to load RMS 'maps/random/fexor.js' Checking my map and the libs... Edit: Just remove the 'output =' after the 'return' Edit: Thx for the fix, now it works as x/y plain Edit: And it has to read: function getAngle(x1, z1, x2, z2) { return Math.atan2(z1 - z2, x1 - x2); } Otherwise it's the angle towards negative x axis...

You are right if the coordinated are x (horizontal, right positive) and y (vertical, top positive), but they are x (horizontal, right positive) and z (vertical, top positive). Since [x, y, z] are circular it's the same as if you'd use [z, x, y] or [y, z, x] (for rotation direction). So for the plane you could use [x, y], [z, x] or [y, z] and where still right. But fore some reason [x, z] was chosen, which is not part of any of the 3 possibilities above. That means we look at the back of one of the planes. That leads to a different direction of rotation. So indeed the old behavior was mathematically correct. [0, 0, 1] (x=0, z=1) has an angle of 0, [1, 0, 0] (x=1, z=0) has an angle of PI and so on... It's the same with buildings: Placing it with a given angle of 0 let them face towards positive z, angle of PI face positive x. In the (strange) chosen coordinate system it's correct. IMO the best thing would be to choose [x, y] for the plane so that a point on a circle at the angle phi with radius 1 could be get by: x = cos(phi), y = sin(phi). But right now it is z = cos(phi), x = sin(phi). That's at least confusing. Same with the rotation direction. It's clockwise which is unusual for a mathematician. too. However, I strongly recommend to stay consistent whatever you choose!

Here's a new version to keep compatible with the SVN version. WARNING: The rmgen folder is mainly for people using alpha9. If you are using the SVN version use it with care! wall_pack2012-3-18.zip

In random maps the players are randomly distributed if they have no players in the same team. If I start a random map with unassigned players I still have the right color and race, so everything works fine for me. If there are no ther players what do you mean by unassigned slot? 4 players for example and you pick the second slot and all others to unassigned?

Is someone at it or could that be a job for one of the massively motivated translators?

Wonderful! For some ranged units melee stats are already shown in the game so I though they already could in principle attack but the unit AI didn't let them.

And I think both units should 'run' until out of stamina and the melee unit should have more stamina. I think the problem could be solved by removing minimum range from non-siege units. I think the issue is more general in nature as I posted here

Position: RMS designer, AI developer, API developer (RMS, AI and balance testing) Do you understand that Wildfire Games is a non-commercial project, work for 0 A.D. is volunteer, and work is done for free? Yes, that's why I'm here Do you agree to distribute all your work for Wildfire Games under Creative Commons Attribution Share-Alike license? Yes, and I'm loving it! Name: Florian Finke Email: Please ask me in a personal conversation MSN Messenger: N/A Location: Köln (cologne), germany Availability: 20 hours per week at least for the next 4 months, likely until the game leaves beta though perhaps less hours per week later on Age: 33 Occupation: Self-employed as private tutor (maths, physics, chemistry) and web-developer Skills and Experience: RTS gaming: I play and love RTS games in general and got vast experience with balancing, micro/macro management, tactics and strategies RTS modding: I wrote mods for warcraft III (example: in-game random map generator and maps with in game race choice with all races supported by own AIs) and glest. I designed maps for nearly every game I played Coding: - Wrote a acquisition system for a multi-channel-analyzer developed at the institute for nuclear physics at the "Universität zu Köln" in python - Developed a game where the player writes bots in python and let them play rock-paper-scissors against each other in python with bot API and GUI in QT - The bots included neuronal network simulation, collective decisions by elections and other fancy stuff ^^ - Wrote an easy to use HTML-page-generator for simple web pages - Made the wall_builder.js rmgen library for 0ad allrdy in svn. - Made the deep_forest RMS for 0ad (Not finished) Motivation: I love open source, coding, RTS, creative common... how could I NOT come here??? Personality: Socially clumsy but intelligent and "try to be objective", cooperative and forgiving but hard-hearted when it comes to the point and I never grew up in some ways... and I'm proud of it! Though it's a second sentence I think I'd mention that Spahbod described my maps/code as I am: "very odd" Short Essay: I searched for open source RTS games and found this massively above-average game in that area As said before, I have no choice but to love it and try to contribute to it ^^ I seek for the possibility to write code that is actually used, to put my work on something that is greater then any project I could possible do on my own, I seek to help making this game better than any based (slow-paced) strategy game after 'Age of Empire II - The Conquerers' (IMO the best, good new fast paced RTS are out there) Interests and Hobbies: I'm mainly interested in very general stuff like physics (methods and interpretation), philosophy (ontology), mathematics (countable and other infinite) and politics (human rights, enduring system stability). See more details in my profile. I'm also playing pen and paper roll playing games ('World of Darkness - Werewolf - The Forsaken' at the moment) My most loved PnP RPGs are Deadlands, World of Darkness - Magus - The Awakening and Earthdown. Staff: I don't get this part, it's optional anyways Community: None very frequently, only 0ad Favorite Game: Warcraft III(Blizzard), Age of Empires - The Conquerers(Microsoft Games),Diablo II(Blizzard), Warzone 2100(Now Open Source), Sacrifice(Shiny Entertainment), Starcraft(Blizzard), Total Annihilation(Now Open Cource), Glest(Open Source), Globulation(Open Source), Gothic(Piranha Bites) , Bos Wars(Open Source) generally in that order Work Examples: Most things are german, sry. Some old stuff including an old version of ssp (Stone-Scissors-Paper (more commonly known as Rock-Scissors-Paper, I know... now)) can be found on my old web side (hosted on my server right next to me ^^) In the HTML section the page generator written in python can be seen (it's an old version too.) A newer version made this page If you are interested in any new code please let me know and I'll provide it. My wall_builder.js rmgen library is already in your svn My Deep Forest map can be found here Some of my remaining Warcraft III maps can be found here (lost many by headcrash) 'The Forgotten' for example allows in-game selection of race and all non-default races are supported by self written AIs (Though that's much easier in WC3 than in 0ad) The multi-channel-analyser acquisition system WMCA for nuclear physics (Only some pics due to copyright):

Please, don't do that! This will make more units chase each other and less damage will be dealt. If you insist make it the default behavior but give the player the chance to change this in some kind of player options before the game. I can only beg you to rethink this. That is going the wrong way IMO and if you make it to be customized we'll see what players like, what is more efficient, how realistic fights look and how high the 'counter bonus' has to be to compensate. Don't reduce the players options and order priority even more!

I'd prefer a better unit AI that looks for the closest target every time it gets hit.

If the player gave the order to retreat it should have priority anyway IMO.

Agreed, just the bold 'and' is not the case ATM. If a building is finished (like this.isReadyToUse = true/false) is helpful anyway. The possibility to trade with unfinished markets is a related problem.

This looks very nice! The gulfs terrain texture and depth looks a little uniform to me but otherwise very cool! The resources seam to be well distributed and despite the players next to the gulfs entrance (that's ok) it seams to be a very fair map. With the shape similar to Mediterranean Cove the game might run into problems with pathfinding. Due to the less rough inner shape it might be less of a problem though. And, by the way, I like maps with water but no divided land parts. Well done!

Perhaps there should be a feature added that reveals all enemy units and/or structures. If a player is nearly beaten it is annoying to search the hole map for a lost peasant (or until now an unfinished civil center which should be fixed IMO). If a player has no (finished) civil center this could happen automatically but perhaps that's not good for more then 2 players left (free for all games for example). So perhaps something like 'send spys to player [player name]' could be added that reveals the players buildings and/or units for a short period of time for some resources. In AoE this was permanent and cost depended on the number of enemy peasants. I think still it was overpowered. Just reveal the buildings for a sec would do (independent of the scouted area). Price could depend on the number of civil centers (Like 250*(number of civil centers + 1) food and metal). When a technology tree is added it could be reached very late.

I just want to add that in case of a human player there should be a sound or some other feedback. And just a tweak, if not reachable and the target is an entity the unit should not start to walk towards it (an exception would be an garrison order to a ship for example) but if it's a point it should try to get near it as it is right now but still warn. Sounds good to me Oh, ok, you don't mean the tree should prevent a worker from gathering if too many peasants are working on it but just to make it easy to get the number of units (and their IDs) chopping it. That's ok! Sry, I got that wrong. When the unit AI changes the target by player order it still has to tell the old target that the unit is not targeting it any longer. The best way IMO for the playerAI to have full control without to many checks would still need the unitAI to send an event like 'targetChanged(ID)' if the gathered resource entity runs out. In combination with target stored in unitAI and assigned gatherers stored in the tree this should work fine.

OK, perhaps we are talking about different things here. In the other post I meant the problem with units trying to chop trees that are so close to the border that they couldn't be reached. As far as I get it the unitAI (perhaps because of the pathfinder) tells them to chop the nearest tree and that next tree was outside the reachable map area. However, they didn't stuck there. You could select them and send them to the map center, no problem. The main problem was that the player AI didn't do that (Maybe because there's no way for the playerAI to tell). That might change with the pathfinder if the unit AI tells to chop the tree because it's told by the pathfinder that it is reachable (I don't know how the unitAI uses the pathfinder ). But you told me you doubt it. (So I assume the unitAi acts not as I think ) In the OP its about 2 units inside a gap each small enough to pass but not at the same time. This might change with the pathfinder as well because the unit facing the civil center could take another way and might recognize the block. However, I have seen units blocking each other with no obstacles near just walking left and right to avoid each other in sync They both used the short range pathfinder I think ^^. What I meant here is that, if a player/playerAI (mainly qBot) has tons of peasants, many of them might try to chop the same tree. The first 10 succeed and begin to chop. The next could reach the target before, but now can't because other units surround it. After the first citizens got full loaded they try to bring the wood back, but they can't because the later units surround them . That is a very similar matter to the map border issue IMO because the peasants not capable of reaching the tree (in the surrounding issue the outer/later peasants) didn't tell anyone and the playerAI has no chance to know (If I get quantumstate right). I don't see how this should be resolved by the new pathfinder. Indeed there IS a way at the moment the unitAt tells to seek the next tree but later it's blocked by other peasants. And Ykkrosh said himself "...assuming no dynamic obstacles (i.e. other units) get in the way...". So what I mean is just that it isn't a good idea in my opinion to let the tree 'decide' whether a unit can gather from it or not (Like in Empire earth where only 6 or 7 workers could gather from one source). That's unintuitive and unrealistic. However it could be solved in different ways: The unitAI could seek another tree if the unit doesn't move fare since many rounds or tell 'broke up previously accepted order ', the pathfinder could cry out 'darn, i can't get through ' or the playerAI could check how many of their units are chopping the same tree. All assuming the code allowed that of cause. I hope this did lower the chance of misunderstanding... and that the new pathfinding will solve it all

Yes, there has to be a way to find out. I just wanted to point out that IMO the unit should get some kind of 'getTarget()' function (or just a variable 'target' or 'tagetOfAction' or whatever) that returns (holds) the target object (Like: 'point', 'actor' or 'template' or so) or just information that grants access to the target object (like ["point", [x, z]] or ["entity", ID]) Within the information it returns (holds) has to be a way to find it's location or other information (if point maybe it's just point.x/point.z, if it's a unit maybe there's some way to find out with somewhat like 'map.getEntityById()'). I think this is much more intuitive than adding to the tree something like 'this.unitsGatheringFromMeIds([iD1, ID2, ID3, ...])'. The unitAI don't need to be involved in my opinion. Though I seldom change my gather positions I never run into problems like 20 peasants chop the same tree and block each other trying to get to the tree to chop it or get to the next deposit. So it seams more like an playerAI problem than an unitAI problem to me. So if the playerID had a way to get this information (which may or may not be possible yet, no idea) would be ok. The playerAI has to be able to get information like that anyway for more improved versions that, for example, avoid chasing enemies half across the map or hunt chicken in an enemy base or try gather from enemy fields or this kinds of issues. Of cause that's a question of taste and priority but this information has to be available for the playerAI anyways. So in my opinion the problem can be solved there. It would be nice though if the unitAI or the pathfinding routine would avoid this in the first place, of cause. But it seams to be under heavy development already at the moment.

And I'll translate it to assembler so it can be installed with a BIOS update Oh sry, going OT

Why? It can do something like: For all own units add target to a list. For all different targets in the list count the occurrence. If the occurrence is greater than wanted and the own unit can 'gather from' the target unit, pick one of those units and send them doing something else (for example give explicit order to harvest from another tree) What's wrong with that?