Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 2024-03-11 in all areas

  1. @Feldfeld do you have a github where you are working on feldmap? id be happy to try and get the other badosu maps working with your balancers for some future release.
    3 points
  2. I don't have a github repo for it. I could make one if you really need it but otherwise I think you can also work without version control and send me a feldmap with the changes.
    2 points
  3. Come on...Also, see below. You talk on behalf of others, and I say what would be likely if the decision would be made with no status quo. These are very different. The concept doesn't work if you think rush balance was fine before the mod. Full stop. It's inspiration is a false premise. Thats not an issue though. Give me an issue with the way it is currently.
    1 point
  4. I think you are making this decision for a lot of people. You are taking me out of context. I said these things before the mod was out. Now that it is out, players understand it. This one? In which only 10 people voted? It was 6-4 non-random. The only written complaints I have seen that didn't come from haters were yours. I would hardly call that a fact. If it was fine before, why don't you advocate for a full revert? After all, you suggest that If that is the case, why do you suggest to further change the system ... Let me make the rest of this reply about why going halfway as you suggest won't work as well as one might expect: Not an elegant solution: As you suggest, there would have to be two distinct buildingAIs, one with random arrows and targeting, the other with non-random arrows and targeting. Either this, or a new class for non-random buildings that gets read by buildingAI and then activates a non-random version of firearrows(). How to balance random and targeted arrows: Allowing a building to be random when it becomes non random upon targeting is bound to fail: If non-random arrows are stronger as you say, players would benefit from constantly targeting manually. You would have to ensure both the targeted arrows and the random arrows are balanced, which would (obviously) need to be handled differently. Inconsistencies: Asymmetry between units is fine and we call it differentiation. When mechanics are so massively different when players expect consistency, we have a problem. You call for differences between targeted and un-targeted arrows, as well as further differences between CCs/Forts and towers. I think that would be a confusing mess. ->Please tell me some issues with 26.6 building arrows that are not due to arrow count balance.<- What makes you say this? I saw complaints during week 1, but now I see none in the lobby. Surely this means there is no problem, right? Jokes aside, I don't declare no complaints to mean there is no issue, that is why I plan to rebalance the arrows.
    1 point
  5. I don't think anything has changed. It has been a known problem for a long time. It is just being reported here now. To the extent the mod did cause more occurrences, I think it is because the new mod makes some games last longer/more units to be produced/etc. (i.e., the mod is causing the game conditions under which the error occurs instead of the mod itself causing errors)
    1 point
  6. @FeldfeldNice man! Thank you. This mod is important for competitive games. Metal and other things must be balanced too... but yeah, it's not simple I know...
    1 point
  7. any updates on the mac logs/replays/mods location for a27?
    1 point
  8. Ok, then ill keep that. Only thing left now is to get the hang with Phabricator .
    1 point
  9. Pr for Macidonia and Secluid houses. (They had very similar houses, so they're sharing a rewritten version of the Athenian house) https://github.com/TheShadowOfHassen/0-ad-history-encyclopedia-mod/pull/126
    1 point
  10. Version 1.0.0 has been submitted to mod.io and is awaiting signature. Please do not manually download the update from mod.io with intent to play it in multiplayer as long as it is not signed. This would confuse many players. Please wait for the signature to play it! This update introduces wood balance. As long as there is enough space around the player's base, they will be given 3 forests in p1 territory. The total amount of wood in these forests is equal (in expectation, and with fairly small variance) among players, but there can be variance between individual forests. The shape of the forests remains pretty random so there can be small imbalances here but it shouldn't matter much. I made it so that forests look the same as before. Depending on the situation the new forests may contain more trees than before and I haven't yet harmonized it with the rest of the map, but this should be barely noticeable. I invite you to try different biomes now! They are a lot more playable. I didn't include berry tree balance yet, but I made it so they spawn a little further away from the player, so less chance you get a "one for all" farmstead at the beginning. Note that I mainly tested the map with 1v1 small size and 4v4 medium size settings, though I did some runs with extreme settings as well. This update makes Mainland Balanced incompatible with previous version's Mainland Balanced. Yet I still make the choice to disallow the incompatible mod check, for the same reasons I gave previously in this thread. As a small mitigation I made it so Mainland Balanced gets a new mappreview image, so if players with outdated version join a game with the up to date version, they will see an error related to the mappreview file. If a player reports such an error in the game, please say there is a new feldmap version and players who haven't done so yet should update it! (Please note however that players up-to-date that join an host with outdated version will not notice anything until game starts) Sorry, that's not for this version yet . Unless I make an exception for pizza settings, it would have to wait for at least a 2.x.x zone of control mechanic.
    1 point
  11. Y'all act like this hasn't been solved in like 100 other games, the most applicable being AOE2, which has non-random fire and does not "break" the game.
    1 point
  12. Might keep in mind: https://code.wildfiregames.com/D1819.
    1 point
  13. It would be good if we can control the defensive buildings' arrows to shoot at a particular target, similar to controlling infantry archers.
    1 point
  14. Agree on everthing, although overlapping forts/cc are a bit OP me thinks. interesting, stances for building-AI would make it more transparent and user-friendly.
    1 point
  15. Notwithstanding what I said above, I think it would be nice if towers and other defensive buildings had a preference for closer units. It doesn't make sense how towers are just as likely to randomly shoot arrows at faraway, hard to hit moving units as they are to shoot arrows at units trying to capture the tower/other defensive buildings. I wouldn't want it to be as simply as "targeting the closest unit" but I would like something where towers are like 3x as likely to target units within 10m than targets 50m away. But such a system gets complicated fast and I don't think we have code for that.
    1 point
×
×
  • Create New...