Jump to content

real_tabasco_sauce

Community Members
  • Posts

    1.786
  • Joined

  • Last visited

  • Days Won

    37

Everything posted by real_tabasco_sauce

  1. Yeah thats a good idea. Something globally defensive for buildings. I think it would be cool to make the recruitment speed a lot faster, like 50% faster but only for champions and mercenaries. Excluding economic units justifies the much faster train time, and also distinguishes it from other train time hero, which is 20% faster with indibil.
  2. Awesome work! I really like the look of these buildings now. potential hero bonuses: 1. Teres I: I don't have a great idea for this guy. 2. Sitalces: This guy seemed to have led some successful invasions, including one into macedon, with a large army from various different regions. How about: +10 pop space, infantry -25% food cost, and cavalry +15% move speed, +10% damage within 45m. 3. Kotys: Seemed to be a great negotiator, always had allies for war. This could be another ally bonus hero, with perhaps speed being prioritized.
  3. I think it will be more hard to create intresting, balanced games as player levels would be much more different if 16 players would need to be chosen Oh, i see, in my experience there are not many players online at 8am CEST There are plenty of high level players at this time (americas), but this is getting very late at night. You would see most of them an hour or 2 before 8am CEST.
  4. Hmm it might be nice, but I think only for unit behavior. It would be bad if I actually click all my archers to shoot 1 unit and some of my archers to shoot a different unit. Even so, I think the unit ai should be simple and predictable, so that player inputs are more responsible for optimizing fights. IMO dancing is really not a problem at the moment.
  5. Is it anything like this? https://trac.wildfiregames.com/ticket/6649 Aha, i guess so lol
  6. If you want to alleviate "turtleing", which does exist and can be a little annoying although not hugely problematic, directly address the problem: slightly increase ram hack armor. change building arrows behavior and/or damage. just addressing the symptoms as you have suggested would result in inconsistencies and further problems.
  7. eles are now an area of effect unit (in part) Catapults used to do plenty of splash damage, but this became a little too op in cases, so it was removed. I would support a very tiny splash radius so that catas can kill units that are very close/overlapping. (especially since they are nerfed now with a range of 85 meters.) bolt shooters are cool, with linear splash and everything, but they are difficult to balance, with a very strong snowball with increasing numbers. I feel dread just recalling the brief "bolt meta". if they are to be buffed, it should be only by decreasing the damage dropoff for linear splash, so that their effectiveness is improved only conditionally. The condition being how bunched up the enemy is.
  8. I think there are not enough champions to do this. I think we could do this with Sparta as you proposed a while ago, and if it turns out well, it could either remain civ specific or become more of a mainstream mechanic.
  9. use version two. Its not easy to get proper play testing together, so thats why it will hopefully be a community mod change.
  10. I did this, but with 0.75, which handily maintains the current total damage by combined armies. https://gitlab.com/real_tabasco_sauce/0-a-d-community-mod-unit-specific-upgrades/-/compare/main...melee_buff?from_project_id=36954588&straight=false
  11. It works for m1 as far as I understand, so some difference between the two could be the cause. I can't really help you, but you will need to provide the log files from when the error happened. Find them in Library/Application\ Support/0ad/logs/
  12. @Player of 0AD, Well its not really a pure buff, but a rebalance: reduce melee armor. infantry melee units slightly faster. increase melee damage. decrease ranged damage. If you are worried about a change in the meta, that is expected. However, this is just for the community mod for playtesting.
  13. Oh, sorry. I am afraid this was a bit of a tangent. This is where it came from. When I say calculated in real time, I mean the "average elevation bonus". This appears to be calculated during placement of the tower: So is this maybe done in GUI?
  14. U mean the melee buff or the making the immortals default to archer form?
  15. 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.
  16. 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.
  17. 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).
  18. 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.
  19. 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?
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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)
×
×
  • Create New...