Jump to content

elexis

WFG Programming Team
  • Content Count

    3,448
  • Joined

  • Last visited

  • Days Won

    58

elexis last won the day on May 16

elexis had the most liked content!

Community Reputation

2,363 Excellent

About elexis

  • Rank
    Primus Pilus

Profile Information

  • Gender
    Male

Recent Profile Visitors

4,722 profile views
  1. Or a different player (owner), undisputedly. That was the naive thought committed, I still hold other uneducated thoughts, so actually let me forget this now gg. I guess there tickets, logs, forum posts of animal UnitAI that one can pay for with his time to uncover. Also UnitAI has 6000 lines, which means it takes more than 6000 lines of your life away when you look at it. Doesn't mean that my naive thoughts that I forgot might have been true in retrospect. I'm currently on a different construction site, perhaps the others can tell you more. It would have the advantage that it is not linked to animals at all. And the simulation components are as far as I understand the situation a part of Pyrogenesis and not 0 A.D., since they should also be usable for mods that don't base on 0 A.D. templates/art/history. (For example starcraft like RTS with arbitrary entities that aren't animals seems like a realistic use case for Pyrogenesis with a solid UnitAI)
  2. Oh it's public now. I don't know if it was public before already or if someone moved it. Anyhow, the linked graphcis are broken, but the cited graphcis above comes from this thread. The links were broken 2 months ago and there hasn't been a response to my posts and proposed fixes yet. (That's what I meant with noone handing out gifts.) (Editing the thread manually may work for this specific thread but won't scale to fix all old threads.)I'll just funnily attach it here: I guess the text is more important, but if the graphcis are missed, the text that refers to the graphics becomes less comprehensible.
  3. I didn't read all posts of all related threads, but these are relevant points I found so far: Account for the previous game designs: Hard-counters were designed already in 2004, it ought to be implemented or consciously argued against it, not ignored. Account for the development process: Reach out to devs: It is rare that people make gifts towards each other, seeking out developers and asking them questions when and how something may be reviewed is much more successful than offering something and hoping that someone will come around and do the hard work without being bothered. It shouldn't be like that, but it is. Package it for devs: Entirely unrelated features should not be added, the more features are combined in one diff, the harder it becomes to review and audit, the more oversights and mistakes are added, the more has to be fixed in retrospect. It can only be committed for a24 / svn, not a23. The longer this is postponed, the more changes gets added to a24, the harder it becomes to transform it for a24. Successful communication: Communication is bidirectional, so I guess if we haven't conveyed the information what we wanted to change, then we probably didn't express ourselves appropriately. But communication is bidirectional, so you also always have the choice to read statements multiple times and ask questions for those that you didn't understand. At least I asked the above two points before in the lobby and on the forums already. About the design stage, I didn't reall all versions from the design documents, nor all related forum threads. But fatherbushido posted it in 2017 already, we reminded in december 2018 again to evaluate that, it must be done before thinking about having your proposal commited. The source for this hadn't been posted. It's from 2004, so from the time when 0 A.D. was closed source (< July 2009). After 0 A.D. was open-sourced, noone had spent the time to try to make these relevant threads public. I spent the last months on IRC logs with that regard, when/if I finished that I will try to publish it for all versions of the design documents (unless something changes my destiny) and relevant old forum threads, but this will take a while. Perhaps this thread can be published, perhaps as a PDF. It was discussed by WIjitmaker (project founder), Acumen (programming manager) and Phoenix-The-Real-Deal (Ken Wood) This should be accounted for, at least by the one who does the review if not by the general public.
  4. The Polar Sea map originally introduced the wolves as non-domesticated animals and made non-domestic animals controllable, so that the wolves could be ordered to attack the player. But following D156#6745 the wolves were changed to a domesticated animals rP19323 so that they can both receive orders and roam. I think using the name "Controllable" would be more descriptive than "Domesticated", since there are some domesticated animals that can't be ordered either, I guess domesticated sheep sheep are not ordereable in real life directly but they are only fleeing from orderable domesticated wolves. Also entity component properties are supposed to determine the behavior of entity components, not Identity classes. But I speak from ignorance as I don't know what the previous generations of developers laid out in plans (and I don't intend to work on UnitAI right now).
  5. So there are three classes of contributions: Hard-counters (core idea) Prerequirements / Dependencies Unrelated goodies If that is correct, then I would again recommend to stop working on unrelated goodies, get the dependencies uploaded if you want this in Wildfire Games 0 A.D. (like FeldFeld did with the hard-counters tooltip). Then get the hard-counters in. Then you can continue to work on unrelated goodies. The more unrelated stuff is added, the more time-consuming it becomes to split it apart later, for you, anyone who would commit it, and anyone who reads it years later. If you want to only have it a mod, I won't stop you, but if your objective is to not have it in a mod, there has to be some theory how this happens. I understand many people offer their contribution and leave it there, but reality is one chances to get something committed increase by some orders of magnitude if one actively looks for oneself how to get it in (i.e. trying to identify the developers, getting them interested, making it as easy as possible for them to agree). The mod was tested for 5 months now, so I guess you have sufficient results to stop adding new unrelated features? I mean it's your work and WFG review is the end-boss, your choice, I can only show the situation.
  6. I seem to recall that you wanted to make a hard counters mod in 2016, but then didn't do so because you thought the developers would review and reject the idea, or reject the idea based on prejudice? The problem is more the missing caretaker. But I don't recall ordering you to do something, but rather explaining how WFG operates with regards to committing such changes, which was mostly creating a branch that has one single feature and nothing else, getting that tested, then committed, then considering the next feature, rather than stacking many features. Secondly the design document needs to be checked. 0 A.D. started in 2001, people wrote on design documents until 2003 until development was started. There was a link to the hard-counters in the design document since 2017 in the thread. In december 2018 we reminded that there is this design document that should at least be reviewed. One can still decide against it if it turns out to be a good idea. After that I had tuned out due to several circumstances. But I didn't order it. Problem is if one spends some time to give some valuable feedback, one gets implicated (i.e. one gets bad reputation if one provides some feedback for improvements but doesn't finish off with a complete review, test, discussion, commit, fixing bugs or balancing defects of that afterwards), so developers are often faced with the decision to not respond at all, to go all the way, or to appear as someone who orders someone to do additional work for no reason. I.e. one has to bring a lot of dedication and time if one wants to start working on something. If I look at the description on the first page I see so many features. Suppose the hard-counters were tested against the design documents and there is a developer who wants to commit the hard-counters mod, it seems very difficult now to review, distinguish the changes: It should be development of one feature (hard-counters?), then that should be tested and committed, then one can add the others afterwards. FeldFeld did everything correct with uploaded the tooltip to display hard-counters in D1707. I understand that you take the opportunity to test multiple features if you already make a mod for hard-counters, but to me doing this is more assuming responsibility than doing something that is entertaining, i.e. to me it's hard work to do it right and (reviewing or development). I'm sure it contains a lot of hard work for you as well that you didn't want to do. If you wanted me to review this, why not ask me, why not check for the design documents as we asked, why keep adding stuff instead of closing the development and proposing it to be committed as is? Perhaps the plan is to have the above list of features all committed as above (similar to the scythetwirler balance branches from years ago)? I remember we also had a discussion in the lobby to split these into one feature per commit and that you mentioned that it was a lot of work but doable. But why not avoid that extra work by adding only one feature at a time? I'm open to alternative ideas, but I'm currently inactive (I either get stuck reviewing day to night because everyone wants something and expects another review or test and commit after one review as posted, or I have to not even give the first feedback). The other developers may also be open to different ideas how to get the best and acceptable contributions into the game. One's chances to find a developer are greatly increased if one actually looks out who is active, who is involved in which areas of development, which deal they could accept (i.e. making it as easy as possible for them to accept. For some it may be easier to review one feature at a time, for others it may be easier to commit a huge bag of features. One also has to consider that that merging balancing branches makes it harder for future people to look read what that commit changed and to identify possible mistakes or improvements in it). Target audience, indeed. My perception has been / is that the experienced players aren't an exclusive target audience, but they are the ones who are most able to identify defects in the balancing, since they run the laboratory tests in these petri dishes all the time. Less experienced players may be considered part of the target audience, since they are many too. But less experienced players either stop playing or become more experienced players, so it's questionable to me whether to optimize it based on the mere fact of quantity of inexperienced players. It should be done for the people who enjoy the game IMO. Singleplayer mode is currently only supported against Petra and gaia zombie waves, no campaign mode. So it's considerable that the difficulty of the AI influences the sensitivity of the entity template / tech / aura balancing. However, if all the experienced players discover that some units are OP or useless, these units are also OP or useless against Petra bots, zombie waves and campaigns using that template, if the according AI uses the templates as effectively as possible. So there have been historic clashes between SP and MP players that develop the game. If one doesn't play online multiplayer and the AI isn't as player-terminating as competitive players, then there is more incentive to save ones time with figuring out the perfect balancing. If one wants to play this game against his online buddies, there is more incentive to invest more time on testing so that the game is actually not broken (degenerating the gameplay into snowballing of one OP unit and clicking the fastest). So mostly I think it partisanship should be tried to overcome by contributing in such a way that all stakeholder interests are represented and no fact left neglected, ... and whatever. A policy (that might exist and just hadn't been uncovered from the archives) could restrict whether or not and how far and for whom and for what purposes one has or has not to care about policies. I took steps one at a time. If we get 10 reports about unit X being too strong every day from the players, there must be something to it, especially if one can reproduce it in a test case. So I mean we don't need a policy if there are intersubjectively witnesseable facts that determine quality of life of users (combined with the proclaimed intersubjectively valid argument that SP and MP have effectively the same balancing constraints, as a competitve player or competitive AI uses the same templates regardless. Open to controversy.) Thanks for the list, reminded me of some better memories, and it provides a good example of easy research that new contributors can do!
  7. Updating the coordinates in the command in the JS file allows you or anyone you might distribute it to to perform a consecutive update to the heightmap.
  8. You propose someone to write a different design document. My point was that the ones who do the implementation should not leave things up to chances but should attempt to keep the game enjoyable (even if you don't consider it enjoyable).
  9. (Maps with two opposing sides have the same area and same maximum traderoute length ideally. Differences become very pronounced with normal and smaller mapsizes. The number of mines, trees and hunt is proportional to the area.)
  10. Translating the map means terrain is lost and has to be filled with something else. Since it uses a heightmap, the blank region was intended to be filled by the heightmap data.
  11. On the one hand one can change the mapscale, on the other hand maps that don't use heightmaps also use custom scales, on the foot there are some heightmap maps that use more proportionate scales (ratumacos). Mediterranean: There are more examples, Hellas picks a random subset that meets some requirements (between 20% and 30% water), or Jebel Barkal which loads an Atlas map (you can load the image in atlas and save as a PMP file and load that in the random map, but that means one can't recenter it afterwards), Lower Nubia combines a heightmap and a composites to get a more precise shape of the nile, Elephantine uses OpenStreetMap data (since the blue marble data is very blurry when zooming in to that level). The comments are all in the headers of the JS files.
  12. That code is posted in the mapscript. According to https://tools.wmflabs.org/geohack/geohack.php?pagename=Red_Sea&params=22_N_38_E_region:EG_type:adm1st_scale:100000000 which is linked from https://en.wikipedia.org/wiki/Red_Sea I didn't confuse latitude / longitude. Chosing a different heightmap is an iterative process, one has to gradually change decimal places until one get's the optimum.
  13. Credit goes to _kali. It's easily possible to move the heightmap: * wget https://eoimages.gsfc.nasa.gov/images/imagerecords/73000/73934/gebco_08_rev_elev_C1_grey_geo.tif * lat=22; lon=41; width=30; * gdal_translate -projwin $((lon-width/2)) $((lat+width/2)) $((lon+width/2)) $((lat-width/2)) gebco_08_rev_elev_C1_grey_geo.tif red_sea.tif * convert red_sea.tif -resize 512 -contrast-stretch 0 red_sea.png Problem is that it heavily influences balancing, all players are supposed to have roughly equal chances to victory at gamestart, but often the game has already decided after pressing the Start button. Pyrogenesis only has support for one level water plane, but in the desert some areas are dry despite being below water level (for the same reason, the Nile on Lower Nubia has few water). (Same with the Nile dams on Lower Nubia) One can add some code to modify the terrain artificially afterwards. (Fixing it in atlas means the fixes are lost if one recenters the map)
×
×
  • Create New...