Jump to content

FeXoR

WFG Retired
  • Posts

    1.426
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by FeXoR

  1. Giving formations a very high bonus feels like enforcing they make sense. I don't know if they can be implemented well and will grand a significant gameplay value. It would be really nice if we had a "no formation" formation so that the order is just given to each unit separately. That way "balancing" the different formations would be easier and we could see how big the bonuses for formations would need to be.

  2. Hello, I would like to ask: which you modify a file, you solve this problem?

    The file I modified was 0ad\binaries\data\mods\public\maps\random\rmgen\pathplacer.js

    I have no good solution to it so it's not fixed (see Spahbod's last post).

    FeXoR: Thank you. I think we must stop the duplicates from the beginning. We must consult with historic_brunno about this first.

    That would be the best solution (y)

  3. I think I heard that http://www.bing.com provides a cross social media API. Couldn't find it at first glance though.

    Concerning the button to turn on/off social network support: As I said before it should disable loading the code for it as well as removing the buttons from the GUI. That's the least. And I agree with Yves that code not used anyway does not need to/should not be installed. This doesn't only apply to social media support. This could include e.g. the high quality graphics actually not delivered with the prebuild Alphas or even Atlas for people that only want to play because it's quite of some size (Indeed for me it would be formations, too ^^).

  4. An option to *completely remove* the feature from the build, even if an option to turn it off is included? Your dislike sounds like irrational hatred. No offense. Like it or not, social media is how are game is going to get exposure. In my opinion, including social media into the game is just simple prudence.

    True, the option to turn it on/off could only effect what you see and what is loaded, not the installed code. But it's not that unlikely to not install specific features of software at all. It can/should be enabled by default. But the option to turn it off is a must-have IMO.

  5. This is far from being easy at this point. If I got my will and everything would be trigger based you could generate own entities at runtime and so in atlas, too, and the needed graphical user interface would be easy to add. But triggers are suspended until part 2 so it will take at least a year until I see such a feature even being considered (But I can be wrong of cause ^^). Until then you can (or have to, depends on your familiarity with code) write your own civs and entities to enable such things.

  6. Since docks can be placed well ingame and bridges would have to be placed similar I don't see why not. However, I'm not working at that part of the code so it's the decision of developers who do to add this feature. It will be some work for sure and I don't think it has the highest priority but I think it's worth a thought.

    Sorry for not saying " I'm already working on it" but that's just not the way open source projects work ;) .

  7. Do you believe Celtic people could lift those massive stones with but a glimpse of the technology we have today? You know, there are many things without answer, in our universe... :muaha:

    True! But this doesn't mean we have to mystify them or that mysticism in any way betters our understanding of "reality" or "the world" or betters our quality of living in an enduring manner. Just an example: There was much mysticism in the dark age but not much gain of knowledge or the quality of living IMO. (This is ofc. no proof, just an example)

  8. A bit of topic: Well looking dunes will soon be available for random maps with the erosion lib I'm working on. It already works but is not yet well documented and organized. I think it will be ready to use in a few weeks.

    It would be cool if some global weather variables could be set and used by different parts of the game. One example would be the wind speed, direction and how squally it is. This could then be used for tree movement, terrain erosion and dust/smoke/steam particle movement. This will be hard to do ATM because e.g. RMGEN has no access to the engine and there's no way to set such things in the engine determined by the random map AFAIK yet.

    • Like 1
  9. Is the AI runtime the same as the rmgen runtime? I haven't looked too deep into those parts of the engine, but I was under the impression they were separate.

    Though I don't like it you are right. Player AIs code is "loosely" bound to the engine to make it a threaded process later in developement (when we get to this point), which is OK but IMO not optimal. RMGEN is run before the engine is started and generates a map that afterwards is loaded by the engine (which I think is a bad choice). The reason why I don't like it is that the programmer does not have full access to all the games content (and things are rewritten in all the parts if needed).

    I'm sorry to say I have no quick answer. I build my own function to place paths in the RMS "Deep Forest" and are not familiar with the pathplacer.js. Trying to figure out what's wrong...

    EDIT: This error only appears on giant maps for me. On very large maps its working fine with the seeds I tried. It's more like normal that giant maps throw with an OOM error than an exception x). I think reworking all maps to make sure everything works fine on giant maps is not the best idea (though I did it for my RMSs). I agree with myconid to raise the memory for the Javascript runtime engine (Spidermonkey?). I don't really mind if it is set automatically or can be set in a config file. I'd say the best way to do it would be to target automatic settings but to fix it "easy" and quick add a property in a config file. If it's set to 0 automation is enabled (default). Otherwise it's set to the given value in kilobyte (or whatever is preferred).

    This ofc. doesn't fix the initial bug that paths have more points than a giant map ^^. Didn't find it yet.

    EDIT2: The number of totalSteps can be greater than the distance from the start to the end of the "path" if Waviness and/or Smoothness are > 4. In "Alpine Valley" in line 247 (create hills), 266/270 (create passages) and 289 (create rivers) the Smoothness is 9 on giant maps. The Waviness is 0.4 and so the numSteps is "only" about distance/10 (+1, irrelevant on big maps) and numISteps about twice the distance. So totalSteps are about 2/10*distance*distance (which should be OK) and will be about 50k for giant maps. BUT then lines of the paths in x direction are drawn - though the tiles in y direction the path contains is MUCH smaller than the 50K (512 at max for giant maps). So many tiles are drawn multiple times. Checking the output with added debug code before PathPlacer.place returns it's value retVec:


    var duplicatedPoints = 0;
    for (var i = 0; i < retVec.length - 1; i++)
    {
    for (var j = i+1; j < retVec.length; j++)
    {
    if (retVec[i].x == retVec[j].x && retVec[i].z == retVec[j].z)
    {
    //log("PathPlacer.place: Duplicatd values found: retVec[" + i + "] and retVec[" + j + "] are " + retVec[i].x + "/" + retVec[i].z + " and " + retVec[j].x + "/" + retVec[j].z);
    duplicatedPoints++;
    break;
    }
    }
    }
    log("PathPlacer.place: " + duplicatedPoints + " of " + retVec.length + " points are duplicated");

    ...shows that most of the tiles are duplicated (duplicated tiles may be 1 bigger but that doesn't matter). Part of the mainlog:

    Creating hills...

    PathPlacer.place: 5152 of 5859 points are duplicated

    PathPlacer.place: 7792 of 8539 points are duplicated

    PathPlacer.place: 1928 of 2209 points are duplicated

    PathPlacer.place: 1503 of 1795 points are duplicated

    PathPlacer.place: 4372 of 5066 points are duplicated

    PathPlacer.place: 4935 of 5365 points are duplicated

    PathPlacer.place: 7124 of 7759 points are duplicated

    PathPlacer.place: 4916 of 5399 points are duplicated

    PathPlacer.place: 1337 of 1589 points are duplicated

    PathPlacer.place: 7229 of 7846 points are duplicated

    PathPlacer.place: 231 of 363 points are duplicated

    PathPlacer.place: 4094 of 4670 points are duplicated

    PathPlacer.place: 3442 of 3805 points are duplicated

    PathPlacer.place: 5485 of 6087 points are duplicated

    PathPlacer.place: 4376 of 4779 points are duplicated

    Creating passages...

    PathPlacer.place: 5763 of 6978 points are duplicated

    PathPlacer.place: 6841 of 8052 points are duplicated

    Creating rivers...

    PathPlacer.place: 6559 of 7274 points are duplicated

    PathPlacer.place: 2050 of 2424 points are duplicated

    PathPlacer.place: 2649 of 3238 points are duplicated

    PathPlacer.place: 1243 of 1576 points are duplicated

    So the problem is in the function "PathPlacer.place".

    I don't really get the function so perhaps historic_bruno or Spahbod could fix it more sane.

    OFC I could just remove the duplicated tiles from the return value by skipping the "y lines" and "x values in that line" already added.

  10. Any further suggestions?

    Otherwise I think this map is quite playable now. No out of memory errors, no problems with many players on small maps, decent looking "empty" (no interactive entities) mid level ground (grass), very natural and random design in general compared to other random maps, no problems with the AIs as far as I tested.

    So if there are no others ideas at this point I think it can be added to SVN.

    Ticket: http://trac.wildfire...com/ticket/1688

  11. A few things... Any way we can get rid of the "black sky" thing happening to water when zoomed out "too far" in Atlas or the game? And also the black shroud of doom that overtakes the whole map when zooming extremely far out. One could say, "Just don't zoom out that far..." but we need to take whole-map screenshots and these issues are a hindrance. :)

    I agree. "Just don't zoom out that far..." is not a good argument in general - the player should be allowed to decide how far he zooms out.

    There should be a limit to zooming out, and that limit should be determined by map size.

    Why should zoom out be limited? I agree that zooming out that far that tiny maps are only 1 pixel and might be missed by the observer is stupid but that's pretty far. Indeed I never did that and it would take ages to do that if it works.

    By the way: A new version of Belgian Uplands is available at http://trac.wildfiregames.com/attachment/ticket/1688/belgian_uplands2012-10-5b.zip

  12. Hmm, any actors (i.e. non-gameplay impacting entities) shouldn't be as much of an issue as entities. I would say that e.g. stones which doesn't have alphamaps could be used a lot more frequently though. Big maps will have to be worked more on anyway, so don't let that concern stop you from making the maps look good. And as far as I can tell the OOM issues are when generating the maps rather than playing on them? Speaking of that, would it help to have objects which consists of several smaller objects? If the issue is that there are too many objects for the game to go through in the RM generation phase that should help I would guess. Michael had some ideas for what I believe he called POGs (I think it was short for predefined object groupings or something similar) which would essentially be small "scenes" that a scenario designer/RMS scripter could include in his maps. That should work even for less ambitious things like a bunch of stones and grass objects.

    Hmm, did a quick look among old mockups and found the attached image, seems like POG is short for premade object groupings =) At least I wasn't too far off :)

    The OOM error occurs when exporting the map due to the iteration over the objects. Javascript (or the interpreter, spidermonkey?) can't handle loops bigger than 1,000,000 (not sure about the exact value). There's not much I can do about it.

    EDIT: Correction: The OOM error occurs only on giant maps AFTER the map is exported and saved so while the engine loads the map I guess. This only happens when the number of "Entities" (shown in the mainlog after "Saving map...") is bigger then 10,000 (not sure about the exact value again). That means on giant maps (512*512 = 262144 Tiles) only one entity every 26 tiles...

    Another Correction: It indeed seems that it's not the number shown in the mainlog but depend on something else. Deep Forest raised OOM errors with roughly 13,000 "Entities" while Belgian Upands generated fine with 27,690 "Entities" according to the main log. A giant Belgian Uplands map seed had 37,960 entities which is to much though.

    ADDITION: A Giant map with half the prop density still raises an OOM error though it contained "only" 20,222 entities according to the mainlog. The number of interactive objects, however, was unchanged. So indeed there seams to be a difference but in the mainlog the number of objects are shown (not the number of "Entities" as it states). The exact error (only this one):

    "ERROR: JavaScript error: simulation/components/ResourceSupply.js line 37 out of memory"

    POGs would indeed be good. They lower the number of needed actors (and so the size of the loop during exporting the map) and make it less pain for a map designer to place them (less clicks in atlas/less needed actor types in RMS). Some of the actors seam to be such things already (like many in "campaign"). If it will become another type of objects RMGEN should handle them so entities/actors/POGs can be used with the same syntax (I can't figure out how to place terrain on a tile similar to placeTerrain() with an array of terrain string (and randomly chosen one per tile) that also support terrains with actors, not only templates/entities). Checking other maps for examples...

    BTW: The naming is pretty unclear to me:

    - While in Atlas choosing "Entities" (in opposite to "Actors (all)") only objects in simulation/templates are shown (is it an "Entity" or an "Template" then?). In RMGEN the Entity() class is a template type with a position on the map.with a certain orientation. However, it works for Actors as well (Things in art/actors) and Entity() instance can be placed with placeObject(). So is it an "Entity", a "Template", an "Actor" or an "Object"? I'd prefer the last at least for RMGEN.

    - In Atlas "Actors (all)" additionally shows everything in art/actors but they are placed in random maps with placeObject() or (in Goups though the name "simple object" doesn't make that clear) SimpleObject().place :crazy: .

    However, createSimpleTerrain() supports strings made of a terrain type string, a separator (a pipe |) and an Entity path string like e.g. "temp_grass_mossy|gaia/flora_tree_oak". That, however, doesn't work for actors so here "Entities" and "Actors" are different in RMGEN while in general it seams they are put together as "Objects" with the only difference that the type string of an actor has to start with "actor|" and include the file extension like ".xml" (which is good IMO except the need of the file extension). The problem here is that a string is used while it wold be better to use an array IMO. "temp_grass_mossy|gaia/flora_tree_oak" works but "temp_grass_mossy|actor|props/flora/bush_medit_sm.xml" doesn't because it contains 2 pipes. It would work if createSimpleTerrain() would use an array with one entry being the terrain and the other the "Object" to place on the terrain. So the "Object" could be an entity e.g. "gaia/flora_tree_oak" or also could be an Actor e.g. "actor|props/flora/bush_medit_sm.xml".

    If RMGEN had access to the engine (like trigger based RMS generation would provide) there would be no need to differentiate between Entities and Actors at all because it could search in both paths and only throw if the given path string is invalid for both (simulation/templates and art/actors).

    Off topic: art/props/flora/grass_underbrush_mediterranean.xml does not "bend" to the terrains surface but looks like it should...

    EDIT: Added many props to the map: http://trac.wildfire...com/ticket/1688

    EDIT: Trying to reduce the number of props on "Very Large" (slightly) and "Giant" maps (scip most of them) to avoid OOM errors.

  13. I think the "don't turn in place" restriction is mostly something we've hoped to have for the ships. Slowly turning would probably work fine in that case as well if it turns out to complicate things too much to do them otherwise. I would think that at least rowed ships could even move backwards though, but I'm not sure if that was practical with e.g. biremes/triremes/etc. (I doubt it would be possible to implement well since it might be hard for the pathfinder to know when the ship has to move backwards and when it can turn around etc :unsure: )

    Well, give it a try. As long as it works well and not to much hacks are needed to make it work. Would look more natural for sure.

    I feel the empty space on grassy terrain is to big on some seeds. Any good idea what to place there? Some eye candies perhaps? Does razed buildings give resources? If so perhaps some buildings for Gaia?

  14. But that would just make them even more meaningless. And true, that might balance the game in the "no unit/civ is overpowered" sense, but at least to some extent we have to balance the units in terms of "all units should be useful" as well. A balance between the different units. If a unit is not useful there's no reason to include it in the unit roster for a civ at all, then the only use it could have is to confuse new players and make it harder to learn the game =)

    Yes, that's a bad thing.

    It's another thing to have more units available for e.g. scenarios, but all units which can be built in a normal game should be useful in some situation. That doesn't say that all units has to be useful in every match you play, some may only be good against say elephants and then they'll not be useful in a match against a Briton opponent, but there should be situations at a whole where using that unit can be what gives you the advantage necessary to win :)

    An citizen soldier, even if a bit weaker than others, can still be useful to gather stone/metal because it might costs the resources easiest to get on a specific map. For elite units this argument won't work of cause.

    In general I agree with you.

  15. I am pretty sure the AI and RMS stuff was split into different APIs because it was deemed to be the best design - not because it was too hard to combine them into a "one API to rule them all" sort of thing.

    AFAIK RMGEN was split from load/save map (simulations?) because it was to complicated already.

    AFAIK AIs where split to make a later change to thread them will be easier.

    I would be interested to see any evidence to the contrary, though.

    I don't know where I got this information. I searched the forum for about an hour but couldn't find it. I'm pretty sure someone (Philip/feneur/bruno?) I consider trustworthy (Not that I distrust anyone here but some just have more information of cause ^^) said that somewhere. Would be nice if anyone would remember but IMO that's not really a point. If we see fit we still could change it. I ATM agree with feneur to leave it as is to make the game "final" faster.

    Well, if we take what both you and I have been saying into account you should probably either speak up louder now or wait a couple of years :P;)

    I'm not really against adding triggers now per se, but to me it seems better to add them when they are the most useful (together with the more story-based parts of gameplay) and together with the other things story-based campaigns brings with them they would take a long time to implement. And not to think of creating the actual content. To me it seems better to add it all at the same time :)

    True. Though I'm quite sure I would want triggers to be more widely usable (not necessarily used) than you would consider OK. I remember the "security issue" you talked about: http://www.wildfireg...24

    Guess you would consider triggers able to change "everything" be such a security issue. But IMO the "Trigger level" connecting the Javascript part with the engine closer can handle this quite well.

    EDIT: Wild guesses only!

    Never do that. I still haven't given up on a new GUI engine :P (but then again haven't made significant progress anyway)

    I don't gave up ^^. I'm extremely sure powerful triggers make things better to modify and are essential for a vital community after the game is considered finished. I just agree that having a feature complete game - considering the gameplay - is vital, too, for an open source game. I'm pretty determined to talk loud to make triggers as powerful as possible - when they are added. We just seam to have to wait a few more years ^^ (until 0A.D. 1.0).

    Since sometimes I can't shut my mouth (keep my fingers away from the keyboard) it might happen that it comes up again before triggers are added, though x). That's my fault and I try to keep myself from doing it to often because it's not helpful, sry.

    I have not much time ATM so I haven't finished a cleaned version of the map, yet. Guess it will take a few more weeks.

    Further suggestions very welcome tough.

    Off topic: I found a very good reason to avoid "turning" of units like planned (already implemented?) for siege weapons: If units can't turn on a point they can wind up in gaps not getting out again...

  16. Generally speaking not for part one at least. It's more likely units will be removed as the more units=the harder it is to balance the game, and, perhaps more importantly, the more units, the more alike each other they will get, in other words: what's the point for a player to train two separate kinds of units to fill the same role.

    The balancing reason is not entirely true. You could just balance the "needed" units (to have all roles filled) and make the others a bit less powerful. That way things will be balanced and still a great variety of units will be available. Only one strong unit can break the balance, not a variety of weak ones as long as for each role about equally strong units are available for each faction.

    That (one overpowered unit) might be a problem with e.g. war elephants and Iberian ranged elite cavalry. They can only fill the role (siege like) when dealing enough damage to structures but will then be overpowered against units if units have no high armor against crush damage (as it is now). Similar thing with other siege weapons. Guess buildings should have less crush armor while units should get more crush armor (compared to as it is now).

×
×
  • Create New...