Jump to content

FeXoR

WFG Retired
  • Posts

    1.426
  • Joined

  • Last visited

  • Days Won

    28

Everything posted by FeXoR

  1. Well, I will add default fortresses for each civ fitting into civil centers territory range. They will grand 20 upkeep each (0 for palisades) and will never have a production building included. This will enable good looking civ specific default fortresses that don't decay. I'll name them 'cartDefault', 'celtDefault', 'heleDefault', ... ...so they can be placed by something like: var playerID = 1; // 2, 3, 4, 5, 6, 7, 8 var civ = g_MapSettings.PlayerData[i].Civ; var myFortress = new WallTool(civ); var myFotressType = civ + 'Default'; myFortress.setFortress(myFortressType); var myX = 100; var myZ = 100; var myAngle = 3*PI/4; myFortress.place(myX, myZ, playerId, myAngle);
  2. Nice, but you seem to ignore Mythos Rulers advise to leave space around the start positions in order to place base buildings ^^
  3. I feel the fortresses are to powerful in the meaning of firepower and upkeep gain. So a to-do list: - DONE: Rotate wall towers so 'garrison out direction' shows to the 'inside' of the wall. - IT'S OK: Think of something to avoid walls from decaying because not in area with civil center. - DONE: Priority: Nice look, balancing or reasonable damage potential? I decided a mix is best (See following topics) - DONE: Celt: Change 'cornerIn' template from fortress to normal wall. EDIT: Done. Doesn't fit well without towers though. - DONE; Celt: Perhaps change 'cornerOut' from outpost to wall. Fit's better but produces a graphic glitch so added it as non-default only. - DONE: Comment to celt walls: The ramp seams not to be walkable. Units just walk 'through' it. - DONE: Hele: Change 'cornerOut' template from fortress to wall tower. EDIT: Done. Changed fortress to non-default. - UNNEEDED: Comment to hele walls: There's a graphic glitch on the top of the wall if two walls are put together. - UNNEEDED: Comment to hele gates: In opposite to other civs they have towers but no attack or garrison space. If indented as walls they are a little off to 'outside'. - DONE: Iber: Perhaps change 'cornerOut' template from outpost (that grants upkeep) to a diagonal wall tower (they are not symmetric). - IT'S OK: Iber: Perhaps change 'cornerIn' template from outpost (that grants upkeep) to wall tower EDIT: Wall extends into tower, added as non-default. - NO: Pers: Perhaps change 'entry' template from outpost to obelisk tough pers are equally powered or even underpowered. - DONE: Palisades: Perhaps change 'entry' template from outpost to a flag as alternative.. - Add 'cornerInHalf' and 'cornerOutHalf' wall element types with bending of PI/4 (45°). Especially for celt gates to look better. - Add 'autoplaceWallTo' capability. - Add circular wall capability. - Add 'romanSiege' style. - Add 'fence' style.
  4. Here's the wall demo with all civs included. The argument given to the 'wallTool' (or it's 'setStyle' function) takes the same civ strings as given by 'g_MapSettings.PlayerData[playerID].Civ' with 'playerId' set appropriate to player. For the wall demo map: Take a giant one, otherwise you will just see a mess of walls with many players. Each player gets a fortress of the style of his civ. When the civ is 'rome' (map editor only) the style will be set to 'palisades'. Fortress size depends on player number: - 1: 'demo' fortress (All wall element types included) - 2: 'small' - 3: 'very large' - 4: 'normal' - 5: 'large' - 6: 'medium' - 7: 'giant' - 8: 'tiny' In addition in the map center a 'palisades' style 'demo' type fortress is placed, just to see the size compared to existing civ's fortresses. wall_demo2.zip
  5. THX, I will get to work on it again tomorrow. EDIT: Monday Edit: Well, soon Guess I will more or less finalize it then.
  6. It would be nice if anyone interested could go through the code and tell me what to do better. Most parts of the code are setting up the length, placement angle and indentation of the wall elements appropriate to the template and the predefined fortress types, so this can be skipped and it's not much left to read. The main part I'm interested in is what types of variables should be what type of object (list/dictionary/object). For example the fortress class is not really needed for now but could proof useful for custom fortresses later. Until now a dictionary would do. I don't know how to define an object inside an object because 'this' always points to the 'most top' object. But this would be better IMO since the 'wallElement' and 'fortress' objects are not very useful without the wallTool and only take namespace. Some variables are not that well names like 'centerX' and 'centerZ' because it's only X/Z directed if the angle of placement is 0. And it's more an offset then a center coordinate, since it's the X/Z distance between the (unindented) position of the first wall element to the center. Perhaps I should do it exactly the other way around (vector from point of placement to the first wall element) and call it offsetX/offsetZ... Sounds good at the moment. And should I define the 'wallStyles' and 'fortressTypes', which take a lot of space, somewhere else? I find it makes the main 'wallTool' code harder to read because it splits the code for functionality. Don't exactly know where to put it... Also the getCenter function is really useful but I don't know when to use it exactly by default. (Returns the 'Center of mass' of the fortress) I do it when setting the wall to a preset fortress, though, if custom fortresses have been added to the 'fortressTypes' and have a 'center' defined manually, it will be overridden until you turn the 'recalculateFortressCenter' property to 'false'. That might not be very handy (though I doubt many would search for the center by hand ^^. And you still can simply use the 'wall' property and set the center vars manually). The existing 'wallTypes' are not very well documented yet. But I think they are chosen wisely. Wait to see the other fortress styles... A circular wall tool was requested and I will add it soon. It will have the functionality for generic bending of walls. Edit: Not to the ground but to one and another wall element so a point is enclosed. I guess tomorrow I will finalize the other wall styles and there will be some more screenies.
  7. THX for this map, I can actually play it without lag on my labtop. EDIT: Just bad the AIs can't play it (Pile up peasants in the nowhere). But that was on alpha8... I like the hight map. Will lure into the code ^^ The resource placement is a bit unbalanced though (at least on the maps I played) But over all very nice.
  8. Hui, I didn't read that before but 'deep forest' looks very similar to 'Ardennes Forest' in the 'MAPS AND BIOME GUIDE'. Should really have read that x) Didn't play AoK. Didn't meant to steel someones ideas or offense anybody by naming my map 'deep forest' and not ' Ardennes Forest' (which is already taken btw) or anything else.
  9. OK, I'll do all that. May take some time though until the next version cause I'll do some rewrites. Found some bad code design and since I got to know JS a bit better I want to change it. Thy for the feedback though. EDIT: I'll go temperate. I think it fit's best to a deep forest...
  10. Hiho, I found there had to be a better possibility to place walls, so I wrote a rmgen script to make it easy... and it is! With it a demo RMG to see how it works. Until now only wall design type 'palisades' available... it's a bit of work but other types are easier and will be added soon. To make a custom wall, just do something like: var myWall = new wallTool('palisades'); myWall.wall = ['wall', 'tower', 'wall', 'cornerIn', 'gate', 'outpost', 'endRight']; var startWallX = 100; var startWallY = 75; var startWallFaceAngle = 3*PI/4; var playerId = 1; myWall.place(startWallX, startWallY, playerId, startWallFaceAngle); You can also choose from prebuild fortresses (like it's done in the demo map) by: var myWall = new wallTool('palisades'); myWall.setFortress("very large"); // Sizes named like map sizes, 'giant' is missing, yet... myWall.place(mapCenterX, mapCenterZ, 1, 5*PI/8); EDIT Start: New versions in later posts! Last version for Alpha 8 can be found here. Later versions are for the svn repo and will be added in new posts. EDIT End. Well, to fully get it I think better read the comments in the file. wall_demo.zip And a screenshot of a small map with 8 players.
  11. Here we go. Nothing changed but the function names and removed some unused stuff. EDIT: Well, indeed I put it here. Edit2: Oh, it seams I raised the tree density... sry, well, at least it's a 'deep' forest then... deep_forest_v0.5.zip
  12. Thx, I thought so, I'll rename them... BTW: I hope you mean @ least notepad++
  13. Could you please check your mainlog for warns/errors? Would help a lot if there are some... EDIT: Perhaps I use the same function names as used in the new rmgen libs (and so override them?) and other rmgen functions that are using the overwritten ones act strange.
  14. This is strange! I use alpha 8, perhaps that's it... All functions I used are inside the map, perhaps some rmgen libs changed... I have no clue, I generated the screenshots of my previous post with the downloaded version and didn't change any files... EDIT: U'r screenshot shows No hight mapping(hills/lakes/paths), no texture (base, path, woods, lakes) and no entities but the start entities and start resources... Checking the 2 functions that didn't seam to run at all...
  15. Huh??? I'll test the download today, didn't check it... EDIT: Yes, U'r right somehow, it's a feature Adding some screenshots of what happened to you, I think: On tiny maps: If you have more then 3 players on a tiny map, the map will be quite empty. Similar with small maps and more then 5 players. In addition to that 'expansion' metal (normally outside the start locations) is very near to each other when you have many players on small maps. Should scale the path's more with map size and perhaps the base size. EDIT: Scaled the maximum tree density with the map size for future versions...
  16. So, here's the next version, quite playable now though many details still missing. Feedback welcome. deep_forest_v0.4.zip Whow, making screen shot of giant maps takes about 15 min... but I had to try x)
  17. In fact I think it's path finding problem... Well, pathfinding is always a problem ^^
  18. I don't think it's a bad idea to have some space at the border, looks better, the shadows for example and map doesn't end so abrupt. But it should have no game impact. Perhaps those objects could be shown but marked as non-interactable so no player/AI/Unit AI tries to interact with them... and fails.
  19. In beta 8 (installed with 0ad-r10803-alpha-win32.exe) yes. EDIT: Perhaps should install on linux and use the svn version to keep track of the actual development... - latium, tiny, players 2, seed 0, bottom on the cliff is a tree. - Cantabrian Highlands, tiny, players 2, seed 0, right bottom of the blue players start location is a tree. - Neareastern bad lands, tiny, players 2, seed 0, bottom left below the red players start location ...did'nt even need to seed to find some...
  20. I don't have problems with vector maths, I have the problem that I don't want to what Ykkrosh told me to avoid. And I don't know how to avoid it. If you wrote functions with about 4 decimal points higher accuracy (The error in trigonometric functions in JS in different OS I rad about in posts was about 10**(-6)) wouldn't it be a good idea to include them in other areas of the game as well?
  21. After a little wile I noticed that it's quite impossible avoiding placing objects on coordinates (z and z in floats). So where can I find a documentation of that 'vector maths' you are suggesting. I only found vector math libraries but don't know if there's a default lib in JS for it and which one you use allrdy (if so). I noticed though that may functions in the rmgen libs use trigonometric functions. Please, answer this one quick so I avoid doing things I have to rewrite. Thanks.
  22. On some random maps (I didn't check all the scenarios) interactable objects are so close to the map border that no units can walk there. I think the the general functions should warn if an entity is placed to close to the map border so that map/rmg designers are made aware of. In my circular rmgs I define a 'playable map radius' variable and set it to 'g_map.getMapSize()/2 - 5' and always check against it if placing entities.Walkable map area my be a bit bigger but I didn't notice units could walk behind a tree placed at this radius. Have to check though.
  23. You are right! I did try that but didn't restart atlas. The .json file does not seam to be reloaded when re-generating the map. THX!
×
×
  • Create New...