FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
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.
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.
-
Another thing, while we certainly aren't as aggressive against people posting twice or more in a row you seem to be a bit more likely to post a new reply rather than editing your last reply if no one has posted anything in between. It definitely depends a lot on the circumstances, and as said above, editing an existing post doesn't make the topic show up as changed on e.g. the "View New Content" page, just something to keep in mind.
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.
-
One solution for that might be allowing map entities to conform to the terrain slope and/or specify their height.
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 ^^
-
One solution for that might be allowing map entities to conform to the terrain slope and/or specify their height. The map format doesn't support either yet
Walls will probably need those changes to look good on hills, though your examples don't look bad really.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 ^^
-
Yeah, the Celtic walls will be remodeled
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:
-
Nice work Fexor, that is great. Neat shapes
How do the scripts do if you ran it on a map that wasn't flat?Works fine for descent hills. Some things look strange though (celtic wall towers for example):
Oh, and celtic walls can fly!
-
I wouldn't say it's a good idea to work around issues with the models by changing the code, better to do it right in code the first time and fix the models.
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!
-
Well, then that's an issue with the models. I wouldn't say it's a good idea to work around issues with the models by changing the code, better to do it right in code the first time and fix the models
(They might need tweaks anyway once the player wall building system is implemented.)That said I don't see the issue when manually placing walls and wall towers:
Perhaps it's harder to do in code though
There are issues in other angles than 90° though, so perhaps that's what you meant?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
-
Hmm, the Iberians do have a wall tower like all the other civilizations. So I'm not sure what you mean by that
(Also, if you're using SVN there are Roman walls and wall towers as well =) But that's up to you, it is definitely recommended to use the SVN version for any kind of development though )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.
-
What do you mean by upkeep?
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'.
-
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); -
Nice, but you seem to ignore Mythos Rulers advise to leave space around the start positions in order to place base buildings ^^
-
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.
-
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.
-
THX, I will get to work on it again tomorrow. EDIT: Monday
Edit: Well, soon 
Guess I will more or less finalize it then.
-
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.
-
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.
I have no forum experience, plz give me tips
in Help & Feedback
Posted
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.