FeXoR

Oh, ok, thx. I just read the 'libraries\wxwidgets\README.txt' and there I found * Download the wxMSW zip from http://wxwidgets.org/downloads/ (avoid version 2.9; 2.8.12 is known to work)Same problem with wxWidgets-2.9.3 (Tryed ZIP and exe) Trying VC++ 2008...

Exactly! I would want that for sure! In general I am the 'I am user, I am Boss! And an order is an order so follow it even if you die trying' type. So I'm not much a friend of formations or any type of 'glue units' option. Even in warcraft III, where it was handled quite well, I rarely turned it on. Same with stances. If you can't set a preset stance for all units, or all units of a type, by default but the game designers do, it's sure there will be players disagreeing with the default. And if you do allow the players to set default stances for all units (or all units of a type) there will be more options and some players might go 'ARGH! So many stuff! That's to complex, I don't play this game...'. I can only beg you: Look how units act in warcraft III. That's perfect in 9 of 10 cases, at least. And if it's not player have to micromanage there units, like a general keeps his soldiers in place. If you want to have stances, ok. But don't set different stances to different units as unchangeable default. Same with minimum range or fixed time of flight for projectiles (like in Empire Earth for archers), at least for archers. The velocity of an arrow is highest when it leaves the bow (if not considering hills). So the minimum distance for an archer is his arm length plus the length of the arrow. That's not so far. And a javelin type soldier wouldn't run when an enemy comes near, cause he would leave his back open for an attack. He would try to kill the enemy first. Only mechanical units should have a minimum range in my opinion. All these things disturb the player interference with the units and make the units not act like the player commanded. And I don't like that. And by the way, if you didn't follow an order in that time, you might be killed by your superior as far as I know. But I'm quite sure there are other opinions

They only occur for me at the beginning of placement. I got a ATI Radeon Xpress 1200. It seams to me it is because the objects are loaded more slowly. But since it occurred in the same revision (11291) the game did run much more smoothly, I think it's because the objects are loaded more dynamically. Before this revision I simply used the alpha8 and it didn't happen there.. I installed a new driver, too, but it still doesn't happen in alpha8 for me. For me the gray shape disappears after a few seconds.

I did, it works:ok: But there's another similar issue (occurring since before your fix, so not really related): When you click an available formation while some units selected they discard their orders. It's the same with units having a garrison order and so somehow related.

When I follow the instructions in the 0ad svn for building wxWidgets (libraries\wxwidgets\README.txt) it comes to the point 'Agree to convert all projects'. I checked 'Do this for all similar cases during this conversion session.' and agreed to 'Convert and open this project?'. Microsoft Visual C++ 2010 Express then asks me: "The project file 'C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxregex.dsp' cannot be loaded. Do you want to remove the unloadable project from the solution?" That occurs for all projects it seams. I always disagreed. Here's the output: C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxregex.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxzlib.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxpng.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxjpeg.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxtiff.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_wxexpat.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_base.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_net.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_core.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_adv.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_media.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_odbc.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_dbgrid.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_html.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_qa.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_xml.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_xrc.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_aui.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_richtext.dsp : error : Project upgrade failed. C:\Users\fexor\dat\wintools\wxWidgets\wxMSW-2.8.12\build\msw\wx_gl.dsp : error : Project upgrade failed. What did I do wrong? Additional information: - Windows Vista Home Premium (6.0, Build 6002) Longhorn 64Bit - Microsoft Visual C++ 2005, 2008 and 2010 Express (Can't use any other then 2010 to compile or don't know how) -- About says: -- Microsoft Visual C++ 01013-532-2002287-70468 -- Hotfix for Microsoft Visual C++ Express - ENU (KB2542054) -- Microsoft Visual C++ 2010 Express - ENU Service Pack 1 (KB983509) - C:\Users\fexor\dat is the mount point of an NTFS partition, so it's not really 'C:'

You'r right everything's fine now. Thx.

I build the latest version (11291) and I have a mouse cursor that is simply a black square. Indeed it was like that with all versions I played (alpha 7 and 8). I thought it was just missing and would be developed, but as it's still missing and I didn't find a corresponding post I thought I'd file a bug report. I run the game on a up to date version of windows vista longhorn home premium. I never saw such things happen in other games so I don't think it's an exclusive problem of mine. Can't make a screen shot. It's just a black picture.

I build the last svn version and will look into it. Really good job by the way. I'll do some corrections to make my files fit to the actual version. After I got used to it a bit, I'll probably ask to join the team.

Next and for now final version of the wall_builder rmgen script. It works like I had in mind and doesn't fail if an unknown civ should be placed. wall_builder_pack.zip Included files: - wall_builder.js: A rmgen script for wall placing. It's inside the rmgen folder where it belongs inside the 'random' directory. - fortresses.js/json: A simple playtest random map with fortresses added for each player of the corresponding type and style. - wall_demo.js/json: A demo map to show the different default fortress sizes and their shapes. Documentation in the map description. - A text file to help figuring out where to put the files. Here's a screenshot of a small map with 6 players: The players civs are clockwise carthaginiens, celts, hellenes, iberians, persians and romans. Since I use the alpha8 romans are not defined. So the script warns and falls back to the palisade fortress for unknown civs. I added some hills so the effect to the fortresses can be seen without making it unplayable. The fortresses add 20 population bonus each. The reason can be read in above posts. I don't think it's that tragic. To add those civ dependent default fortresses to a random map, just add the following code: // Place fortresses var civ = g_MapSettings.PlayerData[i].Civ; var fort = new wallTool(civ); fort.setFortress(civ); fort.place(baseX, baseZ, i+1, BUILDING_ANGlE); With: - 'i' the player number starting from 0 for the 1st player (with default color blue) and so on (In 'fort.place' it's i+1 because 'gaia' is 0 for template placement and 1 is the 1st player) - 'baseX' and 'baseZ' the x and z coordinates of the players civil center the fortress should include - 'BUILDING_ANGlE' the orientation of the fortress. (As far as I know the default name for the global orientation for buildings) To add customized walls it's still the same mechanism as in the opening post. Feel free to play around with it.

Ok, then I will rather edit my last post if no one posted after me and then add a new one. I may think of adding a new post anyway if no replies where there for let's say 3 days to make the post show up in new content. Thanks.

I feel my style of posting is at least in need of improvement. My main questions are: - If I open a new post for a random map, an rmgen script or other code and I want to upload new versions, should I put them into a reply or in the OP? ... and if I change the OP, should I mention that in a reply (or vice versa)? - Sometimes, especially when I have to make up my mind about something, I just speak my mind. But I seldom get replies for that. Is that bad manner of me? If you feel I am doing something wrong and don't even notice it, please let me know.

That would look bad as any architect uses plumbs to get an accurate vertical lineup. In addition to conform to the terrain slope the wall elements then need to be distorted to shape like an parallelogram in order to fit better to the ground and still remain it's vertical lineup. Similar measures have to be made if the wall bends to the terrain curvature (Like the Great Wall of China does).

Thy, now I will sleep better... Perhaps I should have gone to bed before my last two comments ^^

I think it looks fine, as I said before. Of cause it would be really nice if walls whould bend themselves to the ground, but... That would be the first game I know that supports such features. Imo the priority for that is very low. A worse problem is the garrisoning of units in wall towers. I expect them to leave divided inside and outside the fortress when 5 units are ungarrisoned, though this could be handled with the check of the nearest passable tiles next to the exit/entrance/drop-point (whatever). I don't play much yet, because the AIs pile up there peasants in my version and desperately await the alpha9. The gametest will have some surprises in it's bags I guess ^^ Well, who doesn't like surprises?!

Because many functions in rmgen scripts (like group placing methods) use sin/cos offsets. And if I got it right this will cause lightly different values on different platforms (win, linux, mac) and architectures (32/64 Bit). So even if everything will be replaced by rounded versions of the rmgen functions on big maps with many more then 256^2 (262144) tiles there will sometimes be a difference between maps. I don't know if small 'errors' of object placement don't lead to an out of sync, but I think 1 tile will for sure. An error of 10^(-10) is not so small in my book (afaik the error for trigonometric functions). I'm not fully into it, so that's just what I expect to happen from my uninformed point of view. I try to avoid the usage of sin/cos whenever possible. If you look into the fortresses RMG, you'll find much less trigonometric functions used then in the rmgen scripts. However, I might have said it a little more kind, sry for that. And, btw, I'd really like if everything works fine!

I personally don't feel a need of scenarios at all, skirmish would do. But since the 0ad concept is bound tight to realism, it's good to have them aboard. But for re-playability and for network games (as far as I can see 0ad will run in hell a lot of trouble with random maps in network games), the 'skirmish' type would be the prior map-type to work on. Since it's possible to load random maps in atlas, designers can prepare maps (scenarios or skirmish) by writing random map scripts that do the rough work. I guess that could speed up things. To the Warcraft III WorldEdit: Indeed! That was the most powerful tool I've ever seen and since there where some changes in the higher levels of Blizzard, I guess it'll stay that way. But of cause U'r welcome to try ^^

Oh, I like it. Though it caused me about 2 hours to get a fitting right angle without the ramp of the next walls are seen outside the castles...

darn! Forgot the out of memory issue caused by mass trees. Here's a fixed version: fortresses_v0.2_and_wall_demo.zip

Works fine for descent hills. Some things look strange though (celtic wall towers for example): Oh, and celtic walls can fly!

I agree perfectly, that's where the default fortresses of the different sizes come in. That should be default later. I only added civ specific default fortresses differing from one another to get about the same size, same firepower and same upkeep for all civs (well, not romans ^^) If you only have walls and towers it's boring. Test the wall_demo map to see what is possible and allrdy working!

Oh, forgot the main thing: all garrisonable buildings have a 'drop-point' where units ungarrisoned will be placed. This should for sure be 'inside' the fortress! So they have to be placed in a 45° angle (Half the angle the corner bends the wall). That's the main thing. But there's another: Iberian wall towers are not symmetrical (Not the same length then width). So to make it look nice and symmetrical, the have to be placed like I mentioned above. And then the walls coming from both sides will be seen inside the tower. By the way, I didn't check all wall towers for the 'drop-point'.

Here we go! New civs may not work but in principle it's how I think it can be done. There is no default fortress of type 'palisades' yet. Otherwise I'd added this for civs other then cart, celt, hele, iber and pers. In the simple but playable fortresses RMS can be seen how simple it is to place them for each player. All fortresses grand 20 upkeep and have about the same size and firepower. The new version of the wall_builder rmgen script includes them and the wall_demo RMS should cause no conflicts any more. EDIT: Don't dl this, take: v0.2 fortresses_v0.1_and_wall_demo.zip

Your for sure right, I'll look into it. What I mean is that the iberian wall towers don't cover 2 walls placed in a right angle (90° or PI/2) but the walls cover the inside of the tower. That looks ugly and fractional.

Sorry, it's called population bonus in 0ad ^^. If your referring to the 20 population bonusfor default fortresses it's because iberians have no templates well placeable as an corner bending in other then their outpost... and they give 5 population bonus. To 'close' a fortress with PI/2 (90°) corners you need at least 4 corners. 4*5 makes 20.

Oh, I noticed that 'setFortress' should actually be named 'setFortressType'. The above code example is correct until now though. EDIT: No, I will not change it because if you place a 'wall' it acts differently than placing a 'fortress' so you somehow set the hole behavior to 'fortress'.