Jump to content

real_tabasco_sauce

Community Members
  • Posts

    1.801
  • Joined

  • Last visited

  • Days Won

    38

Everything posted by real_tabasco_sauce

  1. Nobody ever said anything about assuming history. Even if we did, I don't personally see anything wrong with that. This is a videogame, not a historical simulation, which would be very boring and unbalanced. Now here is the situation: In gameplay, a mesoamerican civ is in close proximity to civs with horses. It would be a nice feature that the civ can utilize the horses after capture. What is so unrealistic about this? It is a convenient and interesting gameplay mechanic. Now, if this is deemed inaccurate, there are still means to compensate for the lack of cavalry, but I still see no issue with training cav from captured stables, which would be a rarity in most games. Yes, but it is still metal, and it could be used for trade/currency, which can explain metal costs for things that are not directly made of metal. Alternatively, other precious items like gemstones could be used as more abstract stand-ins for metal costs. The mayans wrote with glyphs, with the earliest known example apparently from 300 bc. I am not familiar with mayan oral history but this also constitutes history, at least for many native American societies.
  2. I would say there is certainly enough historical knowledge, it just has to be researched. We don't need to know exactly how many troops were at X battle at Y time, just that fighting occurred. Weaponry is well understood. I am not sure about the particular civs we are talking about, but it is often the case that real historical events are recorded in folklore Cavalry can be trained with a limit from captured stables. It is a straightforward and logical mechanic. Economy can be fairly simple but strong with less emphasis on metal (on that note, perhaps a civ bonus could be less metal cost for blacksmith techs, but increased research time. Another option would be replace metal costs here with stone). To say they used no metal is wrong, there seems to be plenty of metal usage, just not casting iron swords and the like as seen in Eurasian and African civs.
  3. Not to make this a community mod discussion, but I don't think the community mod should be a balanced version of the game for competitive games. This would solidify the existing division it has created in the community. I think the mod is better off as a testing ground for balance changes and some content additions (ie centurions). In an alternative plan to @Yekaterina's, new civs could be added to a release (hopefully in a fairly well balanced state, Han was an example although their balance is still questioned by some). After release, community mod efforts could include live balance patches for the new civs. In a26, there were no balance patches to Han, only a bugfix, however one was attempted for crossbows.
  4. well it is one globe you are right that it would have been quite a trip. I don't think the historical accuracy of any two civ's realistically fighting each other is fit for a videogame. After all we do want more content right? Plus, if more than one American civ is added, it could be conceivable or even historically verifiable that they fought each other. I think this is a great way to proceed.
  5. I like the overall layout a lot and I think it adopts a more modern style of menu design. Do you know how well the placement of "Learn to play, AI and Lan, Multiplayer" works with the existing backgrounds? Not sure if those buttons would awkwardly block parts of the background or not (i.e. beheading a hoplite in the spartan background). Perhaps there is an optimized location that works well enough with all the backgrounds?
  6. I think Lusitanis, and some American civ(s) should fit with this group. It would be nice to have a civ to go with the Iberians, kind of how the Britons and Gauls are a pair. As for the Maya, the current mayan content (of which there appears to be a lot) could be branched into a pair of similar civs not unlike the greek city-states, or remain one representative civ.
  7. For the record, I didn't know we could choose more than one option, so I probably would have vote for Agni as well.
  8. yeah I did it manually in game, but you could also do it manually in the user.cfg or maybe local.cfg. If you see hotkeys set in default.cfg that are not in user.cfg or ur local.cfg then you can add the lines to those file with new values.
  9. @Mentula are you familiar with a user.cfg option to increase mouse scroll speed (or panning speed)? I know this can be changed in game via a hotkey, but the change does not persist, so it would be nice to set this in the user config.
  10. It shouldn't be all that tedious. I have done a lot of hotkey switching recently and it worked out well. You can just choose one unused key (I chose super, which is command on mac). Alternatively you could boot something like "follow" off of f so it is readily accessible to your left hand.
  11. Yes, and for some civs, like I mentioned earlier, they align so that the upgrade is directly below each corresponding unit.
  12. Yeah thats what I have done here, except they are in the barracks/stable. In the forge, these would be very crowded, while in production buildings, they are less crowded and their association with each unit class is clear.
  13. Yep! It's all working flawlessly. Thanks for making a bundle @Stan`!
  14. I tried this version on mac with moltenVK. Nothing seemed out of the ordinary until I turned texture texture quality to high. At hight texture quality, it does something like this: (the video is from an earlier test I did) ultra_high_shadows.mp4 After lowering textures back to medium/low, the glitched textures remain. There is screen tearing when panning while using default settings. Someone told me it's not possible, but turning on vsync fixes them perfectly and results in very smooth panning. I would say vulcan gives me an average of 10 to 15 more fps, which is impactful, but more importantly I do not get stutters or frame rate drops that I noticed frequently before.
  15. In my opinion, this a little too dumbed down, I appreciate more nuanced prices that we currently have, and I think 3 resources in a technology can be ok, depending. If all siege units were wood metal, it would be a little too easy to quickly switch from using rams to catapults.
  16. you could just copy the first few hundred lines to a file and upload that.
  17. What were u playing? a26? the development version? Using a mod? I had my mainlog balloon some when testing the vulcan backend on mac without the spirv mod. This was accompanied by a small army of pyrogenesis processes that ate up a ton of RAM. My mainlog only got up to like 10mb but if you have a high end computer I could see it going far past that.
  18. I see what you mean, but it would also be weird to have prices too divided. (metal for techs, stone for buildings, food/wood for units would be the other extreme). The main thing with these upgrades is that they shouldn't be too easy or hard to get compared to forge techs, and they should be accessible alongside forge techs. If they cost too much wood/metal, then they become mutually exclusive with forge techs. Thats why a portion of it is food. I think if one of the three should be dropped, it should be wood, what do you think? Something like this: tier 1: 75 food, 125 metal tier 2: 150 food, 250 metal
  19. yeah I mentioned that earlier, but I guess it was buried in my rather long post. I'd say overall its something we should try again for a27. Not sure @Stan` if it should be a new "main" branch. Would the old a26 version then just be a branch of main? Maybe it should be a separate project?
  20. I see. I would say most players saw it as a success, probably because of the faster turnaround on new content. With regards to splitting the community, I think this could be improved going forward. The primary reason to play the community mod (at least early on) was because of its bugfix for the Han farming techs. Because of this, the community mod became the default version of the game for a large group of players. So, subsequent versions were heavily vetted with voting to ensure only guaranteed improvements were merged. What resulted was in my eyes, a much less ambitious version compared to the possibilities the community mod provides. My thoughts are if the mod adopts a more experimental approach, like a community test environment, the majority of games will take place on a27, with those curious to try out new content playing occasionally on the mod. With this more experimental approach, both players and contributors should be more welcoming to ambitious content, which may be imbalanced, or otherwise sub-optimal. The "risk" of playing the mod would be that some things may be bad changes and some may be great changes, and to avoid this risk, I imagine players would prefer vanilla 0ad rather than playing the community mod alone.
  21. Again, any feedback on prices? Maybe this part doesn't matter so much at the moment, perhaps we could just adjust prices as needed for balance.
  22. Hi @Stan`, @wraitii, What will the plan be for updating the community mod with the a27 simulation files? I presume that wall change is one of the last changes to these files, so conceivably the repository could be setup for a27 even before the actual release right? This way I could start putting some ideas together — Melee damage increase, han crossbow nerf, unit specific upgrades, siege tower capture attack, maurya hero aura, crush armor adjustment. I could also get @borg-'s sparta ideas in the community mod.
×
×
  • Create New...