Jump to content

real_tabasco_sauce

Community Members
 View Profile  See their activity

  • Posts

    1.797

  • Joined

  • Last visited

  • Days Won

    37

 Content Type 

Everything posted by real_tabasco_sauce

  1. real_tabasco_sauce
    I see the complaint, but I have to say, wouldn't it be nice if the melee version was more useful? In that case, it would be fine to start them as spearmen. This would be an easy change, but I am keen to see if the melee buff brings any improvement to the situation first.
  2. real_tabasco_sauce
    from gameplay experience, civilizations are fine to have different selections of units. I consider it an important part of civilization balance and differentiation from which strategies may be developed. I think the ranking of those civs depends largely on the player you ask, with higher skilled players probably agreeing somewhat on the top 3 to 5 civs. That is, in the community mod. If you ignore the community mod, its pretty clear that ptol dominate. The Seleucids are very well rounded. I can say for sure that most players would very much dislike all civs getting all the core units.
  3. real_tabasco_sauce
    well between (y+window height) and (y- window height), two factors of window height have been subtracted. So any range bonus from the second approach would be too small (15 meters below ground). Anyway, I think the issue can be better addressed superficially: Where is the "average range bonus" calculated for the tooltip? it seems to me, a much better range overlay would just be adding this value (already calculated in real time) to the range for making the range overlay. In the placement tooltip, one could add this value (evaluated for flat conditions, 13) to basic range and subtract it from the calculated average elevation bonus. Then in the tooltip for the template, one could add 13 instead of keeping 13 in parentheses. The only issue with this approach is that the range overlay is still not the non-circular true range, but it is close and should be less computationally costly (using already calculated values).
  4. real_tabasco_sauce
    In this case, I wouldn't say they are "jobless." For one, remember it is still an important "job" to go harass the enemy and cause damage. This is done currently, but it's widely considered that their economic value generally surpasses their immediate fighting value. The idea here is to bring down the economic value of CS however much is appropriate while adding an additional eco unit.
  5. real_tabasco_sauce
    Hmm yeah that also sounds good. I guess what I said earlier was more to introduce the "laborer" to all civs, and then one could differentiate on the cost, availability and properties of them for different civs. for example, sparta could train neodamodes spearmen instead of laborers for the same price after researching the unique reform upgrade. (maybe carthage could get some cheaper laborers for a metal cost from markets) perhaps I could cook up a couple ideas in the community mod sometime. @wowgetoffyourcellphone would I be able to use your male villagers from the two gendered citizens mod?
  6. real_tabasco_sauce
    its fine if you won't help. But there is definitely a point.
  7. real_tabasco_sauce
    Should just be y, not (y-window height) In any case, you shouldn't even need to reconsider the actual targetIsInParabolicRange function. I am not suggesting this either. the only things to change are the tooltips and more importantly the range overlay. I'd say the range overlay doesn't have to be the actual range, which appears to be costly, but maybe just basic range+ average bonus range. This will be right most of the time instead of being wrong 100% of the time. If using average bonus range is also unfavorable, then one could even just use the parabolic range evaluated for perfectly flat conditions (13). Then for the tooltip: range+13 bonus range -13, this does hold true for all average ranges.
  8. real_tabasco_sauce
    Well the idea was to make modding more accessible to everyone, and towards a centralized test environment where balance changes and minor content additions can be play tested on the fly, all in 1 mod. having them all already in gitlab makes it easier for everyone to try making changes of their own. Ideally, your gui mod should be fine in a27 if most players are using vanilla 0ad as I expect. Right now, because of a couple of bug fixes for Han, the community mod is much more mainstream than I think it should be.
  9. real_tabasco_sauce
    Well, one of my ideas for future community mod development will involve BuildingAI.js, which is in components. That being said, either 1. the unused components files could be removed from the community mod. 2. You could try to add this to the community mod for a27 Are you making the mod for a26 or a27? At this point I would recommend making it a27 compatible, since the release is "coming soon", and since there is unlikely to be another community mod update until after a27.
  10. real_tabasco_sauce
    Well, if u have a population of women and men (50:50) it would make sense that among the men, the "laborers" are of lower status than those trained to fight as soldiers. U don't have to call the unit a slave, which could be too specific for some civs anyway.
  11. real_tabasco_sauce
    to be super generic and straightforward you could do this: woman unit (unchanged) - gather rates better for food laborer (male model, costs more than woman due to opportunity cost compared to CS) - gather rates decent for food, but best for wood, stone, metal. CS - gather rates halved. then, all you would have to do is pick the right cost for the "laborer" (a generic term which would nicely encompass terms that might be more controversial). Then on top of that, you could use this for a civ bonus (start with 2 laborers instead of 2 ranged units). I'd say this would require the fewest changes to the game (besides just buffing women gather rates.) The only issue that remains is the controversy of encoding gender roles, which is generally historical, but some might take offense. This way you also don't have 4 visuals for eco units (as in 2 gender mod + DE)
  12. real_tabasco_sauce
    Epic start to a nomad game from spartan_299
  13. real_tabasco_sauce
    @hyperion you think i don't understand parabolas? That's a pretty cringe thing to say. In the above, green is the real range of the tower. Below, you can see the average bonus range is 13. How would it be ANY different to say instead: "basic range: 73" "average range bonus: 0", with the 13 meters already taken into account? I am not saying this is a catastrophic bug, but arguing to maintain the status quo is pretty embarrassing.
  14. real_tabasco_sauce
    right, but my point is instead of starting at +13, start at 0, with 13 already accounted for by the towers range. ie 73 (+2), 73(-6).
  15. real_tabasco_sauce
    @alre the point is in this picture. Towers have a range of 60 meters, but this range is actually 73 meters because the additional range due to window height is treated as elevation bonus. Because of this, tower range overlays are incorrect, with more range than visually indicated. It would be much more intuitive to include these 13 meters of range as part of the tower's innate characteristics, so that the final range remains 60. This way, additional bonus range would be 100% due to elevation. I actually couldn't find where bonus range is in the templates. Is it because of the 15m y origin of the arrow?
  16. real_tabasco_sauce
    Yes it did. Of course, the main objective with early raids is to find easy kills, so this is relatively unaffected. However, they are now more easily stopped with melee units. In addition, sword and spear cavalry will now be more viable units for raiding, whereas currently a spearcav takes a long time to kill even 1 woman.
  17. real_tabasco_sauce
    Is my advice not relevant? no, it definitely is. This is how I tested the melee rebalancing mod. I wonder if they thought your comment was a joke because "change perspective" sounds like imagining you are the enemy.
  18. real_tabasco_sauce
    yeah it makes no sense to me to distinguish the height of the window as part of the "elevation" bonus. It is more of an inherent property of the tower, and any "elevation" bonus should be actually due to elevation. Coincidentally, I just had players asking me if the tower range is accurate.
  19. real_tabasco_sauce
    I don't think it's a bug. For 1, I am using macOS, so I doubt its that . A game FPS of 8 seems to agree with the %CPU usage. Hopefully this will be a little better in a27.
  20. real_tabasco_sauce
    yes, it makes playing quite a struggle.
  21. real_tabasco_sauce
  22. real_tabasco_sauce
    well if it should stay the same, at least the range overlays should be accurate to 73 meters and not 60 meters.
  23. real_tabasco_sauce
    Yeah, it seems like it would be more simple to include the 13m as part of the towers 60m range, then any additional range is actually due to elevation.
  24. real_tabasco_sauce
    I guess I didn't realize every tower is +13 by default. I guess the issue then is that the range overlay doesn't take this additional range into account.
  25. real_tabasco_sauce
    ^accurate depiction of my laptop giving up after micro-ing a 30 minute battle (no units have died yet).
×
×
  • Create New...