All Activity

Just throwing one idea out there: free and instant stone mining tech upon phase up. The civ is quite stone heavy, so this could be nice. Also it could help justify going for late game compositions and not being forced to make mercs to feel competitive.

I like someof these, and am happy to discuss in more detail in historical. I do think it depends on what you are trying to get at fun/similar game play for all civs, or slightly more historical and challenging game play based on some recent readings I think carths strenghs and weakness were due to their reliance on mercanaries. Mercanaries had no loyalty to carth it self, so if they weren't geting paid or felt things were going horrible wrong in battle they would jsut desert. I dont think Will to fight should apply to merc But then of course they need to be stronger in other ways

60 seconds wasn't a narrow enough time between horn blasts? If not, then maybe 30 seconds could be good.

Hello, Frustrating aspect: The feeling of being forced to play cavalry or mercenaries to stay competitive. Gameplay experience: When playing randomly, getting Carthage can sometimes be frustrating, even though I recognize the civilization’s potential. For example, playing with archers is not very effective. Current situation: Carthaginian House: Maritime and land trade bonus (not very useful in many games) Reduced mercenary training time: This bonus can already be very interesting, as 6 civilizations have access to mercenaries. Naval town center Interesting heroes and competitive bonuses Improvement proposals: New team bonus: Skirmisher cavalry +1 speed Personal bonus: Traders: +50% HP Decreasing temple costs: 300 → 250 → 200 stone Removal of rare resource bonus (low impact) Replacing the market with a "Phoenician Trading Post" (200 wood, 100 stone, 1 building limit): This build have feature, pick one Option 1: Passively generates gold. Option 2: Applies a tax on all market trades by team players. Need determine the amount of balance good Option 3: Generates 1 metal per active merchant in the team every 60 seconds. Skirmisher cavalry differentiation: Nerf attack speed: 2 sec Increased damage: 24 -4 -meter range → Boost hit-and-run tactics New unit: Liby-Phoenician Lancer +10% gathering speed but -20% HP Various ideas: Similar to Immortals, champion units could transform into monks (monks champions), either mounted or unmounted./Temple champion unit transformation into monks/Mounted champions reduce damage taken by 5% in a small area around them (simulating a morale system)

Yesterday the game froze on foothills; it wasn't completely dead as the birds kept on chirping. After ~20 minutes of not responding I gave up and killed it. No error logs, last thing noted was something loading successfully. If I catch anything I will post it. Something more concrete: fish in land on Scythian Rivulet

If it's not too much of an ask, can account creation date become available? I think it would really help out with many problems.

We don't offer a way right now to retrieve the account creation date.

cata should be 200 hp

That was it ! Well...I had set v141xp ...but not for all wxwidgets 'project', some was using 2022, I shift-clicked on all and set the good one, after build/copy pasta etc, Atlas was builded ! Greats ! I was going so crazy that I could send my army attack the beach Okay, time to learn, do you have some tips/ documentation on how can I "efficiently" test / work on Atlas ? Actually my workflow look like : building pyrogenis, open 0 AD, open scenario editor, edit on line of code, closing Atlas, rebuilding reopen 0 AD etc etc Thanks

I would like to implement a feature which fetches the creation date of a user, alongside other profile items. Engine.GetPlayerProfile() gets me the total games played etc. I also want to know the age of this user. Can I just add another parameter to the query? How can I achieve this? My ultimate aim is to make a mod which assigns Chevrons to users based on age of accounts @Dunedan is the creation date documented at all? Would it be possible to let clients query it? Thanks

I do not think this applies to games. There's a reason games like "Cookie Clicker" exist. It's actually fun to put in "physical effort" (in the form of clicks) and get rewarded for it (in the form of a funny number going up, or winning the game). But why? Hannibal did not decimate the Romans at Cannae merely by coming up with a superb strategy. He defeated them by coming up with a great strategy and having the commanding skills to execute this strategy to its best effectiveness.

For formation banners given the size the polycount would be okay. Yeah some of Alexandermb's models have a way too high polycount. I mean the game supports setting three different meshes depending on the quality options. You can check the barrel actor for an example.

For the faction to be in a future Release, match the art-style of official factions? brush-work, that is. They do appear similar to certain Rise of the East factions...

This is the perfect opportunity for me to explain what I think this whole debate is really about. Yes, I absolutely think it's cringe if people built barracks in a line and used a macro to cause units to rapidly garrison-slide down them. But here's a quote from the 0 A.D. Vision: The concept of someone building rows of structures to abuse the garrison mechanics definitely fits the description of a "sneaky trick". The solution, therefore, is not to simply prevent players from exploting this game mechanic via moderation, but by improving the mechanic itself so that it cannot be abused in this way. The simplest way to do this is to introduce a delay after units enter a structure before they are able to leave again, and this delay must be at least the same amount of time that it would take for an infantry unit to cross the diagonal length of that structure. Getting more complex, what if there were animations for units entering structures? Here's an excerpt from a different part of the 0 A.D. Vision: (no, I won't stop quoting the Vision) This isn't currently implemented in the current Alpha version, but it can be in the future. Perhaps, instead of a unit simply walking up to a structure and then disappearing into it (the current behavior), there is an actual animation where the unit must enter from a specific side of the structure (i.e. the front), and the unit can be seen walking up the stairs, and climbing to the top of the structure, and this introduces a delay before the unit is actually considered to be "inside" the structure, and able to fire projectiles from within it. Then, when you order the unit to unload, the unit can be seen climbing down, or walking down, and this takes a few seconds, before you are once again able to order the unit to move somewhere else. I think that introducing a delay for garrisoning/ungarrisoning units from structures, especially with an animation tied to it, could really add to the depth of the gameplay, both for people with mods like ProGUI, and those without. Maybe we could go even further, by allowing enemy soldiers that want to capture a fortress able to block the entrance, so that your own units must fight their way in, and if they wanted to defend from the inside, it's kind of too late to do that. All of a sudden, garrisoning inside of a fortress is no longer a reactive behavior; suddenly, it must become a proactive behavior. You must decide quickly whether or not to order units to get inside, or take on a different defense strategy. All in all, it would eliminate the cringe strategy of using houses as roads. The main point I am trying to make here is that the kinds of gameplay design changes that eliminate the "sneaky tricks" that players can do, whether or not they can automate it, are also the same gameplay design changes that make the gameplay better, deeper, and more fun in general. The point I am trying to make is that instead of arguing over what mods should be allowed, or whether or not the GUI itself constitutes part of the game and part of the challenge, we should instead try to design the game in a way to ensure that it remains fun regardless of how players choose to interact with it. We can design our game well enough that it no longer matters whether or not someone installed ProGUI; the more fleshed-out we make our game, the less effective these mods become at enabling one player to frustrate another, and eliminating these "sneaky tricks" is a large part of that. It may be true that we cannot completely eliminate the advantage given by being able to react quicker. However, I do believe it is our stated goal to minimize this advantage as much as we can: Suppose there is a game where two players of otherwise equal skill are pitted against one another, and both are using the vanilla GUI, and while one has spent several hours looking into the various hotkeys that are provided by the vanilla GUI, and re-assigned many of them, the other player has yet to surpass the essential modifier keys, and does most things by clicking with the mouse. What this excerpt from the Vision is essentially saying is that in an ideal world, these two players should still have equal chances of winning. It does make the game easier to control once you have familiarized yourself with the more advanced hotkeys, and developed the muscle memory to use them optimally, but this is different from actually being a better player. The person stuck with basic keybinds and a mouse can still win if they have a better strategy that allows them to train a large army faster. Having a stronger economy should take more than being able to click the fastest. Now extend this to the player with advanced hotkeys paired with a different player who has a mod with even more advanced hotkeys. My point is that these hotkeys probably will provide a small advantage, but we should try to minimize this advantage as much as possible by designing the game better, to the point that more and more rated match wins are decided by something other than one person being better with the keyboard than the other person. And as I said in the last point, the changes we need to make to this end, are the same changes that will make our game more fun in general. Honestly, I find it hard to formulate an actual "counterargument" to this. My claim is that the GUI and the game are two different things, and you are essentially saying they are not, but I don't see a 'why' anywhere. -Also from the Vision. I guess what I am trying to say here is that yes, maybe you can consider the GUI "part of the game" by some metric. My point is that the GUI should not present a challenge by itself; it should not be challenging to try to control the game. Most of the challenge should come from the strategic elements of the game, from deciding what to do next, and these elements are defined completely by the simulation code. If the challenge of the game comes from trying to control it, then the game becomes frustrating and people won't find it fun. If the challenge comes from the simulation code, then by definition, that means swapping out the GUI component won't suddenly enable you to play better. These mods add features that are mostly equivalent to being able to activate multiple hotkeys at once, and while that may be useful for making the game easier to control, you still have to think about what the best strategy is, with or without the mods. If the GUI itself presents a challenge, by getting in the way of the player using it, then of course the game would seem easier and more trivial if you swapped it out, but it also means the game itself isn't really fun. If we achieve our goal of designing a vanilla GUI that is not complicated to use, then that also means the harm done by independently changing some of its behavior is also minimized. Hopefully that's not too hard to understand. You are working with the assumption that the new network model would require sending data about every game entity, on every tick. This doesn't have to be true. Let's say that player 2 is sending three cavalry units to capture the output of player 1. In your model, from the moment the units enter the range of the outpost, the host computer must start sending the position, orientation, health, current action, etc. of those cavalry units at least 5 times per second, but that's not true. All the host really needs to do is wait until the moment the cavalry units enter range to send player 1 a single packet containing the information about the three units: their status, the position they entered from, and their current velocity. After player 1 receives that packet, it has enough information to infer the status of those cavalry units for each tick. If player 1's computer knows the velocity of the units, then it can assume that the cavalry units continue on their course, and reach the outpost at a certain time, at which point the host will send another packet stating that the calvary units have begun attempting to capture the outpost. That's two packets, total, compared to the dozens of packets that would be sent under your system. If player 2 orders their cavalry to turn back and garrison inside of a temple that is outside of player 1's vision range, then the host will send a single packet at that moment, stating that the cavalry units have all turned around and are now heading in a new direction. My point is that it isn't a choice between "lockstep" networking, and sending an entire 0 A.D. map over the wire up to 40 times per second. As I said in the original post, there is no cosmic rule which states that the way we currently do networking is the only way that it is possible to do so. There isn't even a theoretical limit to the number of different ways we could implement 0 A.D. multiplayer, and I think we should focus on a networking model that puts security first, by not sending information to a player that shouldn't be visible on that player's screen. One time, I set up multiplayer 0 A.D. with myself, by launching Pyrogenesis mutiple times and connecting over localhost. I noticed that in multiplayer, there was always a noticeable delay every time I gave a command to a unit, which isn't present in singleplayer. I have yet to understand much of the technical nature behind the game in general (I wish I did), but I infer that what is happening is that once I give a command, the client process has to wait to receive confirmation from the host process before the action is actually carried out, which always introduces a noticeable input lag. Correct me if I'm wrong. Like I said, there is a possibility that we could implement the network protocol differently. Perhaps, once the user gives a command to a unit, the client does some local checks to verify that it's a valid command, and then, locally, makes the unit on screen start moving, and at the same time, a packet is sent to the host stating that a command was given and the time that it was given. The server gives confirmation back, that the unit started following the command at a certain tick, and the client updates the simulation accordingly (maybe there was a 1-tick difference due to lag; these are the microcorrections that I mentioned briefly at the top) Meanwhile, in the case that the unit that moved was visible on a different player's screen, that player recieves a packet stating that the unit changed orientation and is now moving in a different direction, and includes the exact simulation tick that the move order was given. The other player's client would update the simulation accordingly; if the server accepted the command for tick 1507, but the player 2 client was on tick 1509 when it heard of the move order, then player 2's computer would have to recalculate what happened over the course of those two ticks as a result of the move order. The user may see the unit jump a few meters in the other direction (a visible rubberbanding effect, or whatever it's called), but I don't think this is any worse than having to wait half a second for every command to register. I don't think one person having total control over the simulation is worse than every player being able to reveal the map completely. And, like I said, hosting from the computer of one of the players would probably only be done for casual games with ad-hoc networking, such as a group of guys getting together at a cafe. There is the theoretical possibility of a headless host, which makes the game totally secure by putting the trust in a neutral party, such as Wildfire Games itself. And I'm not the first person to propose this. This is adjacent to asking "who is going to pay the developers to make 0 A.D., or the artists or animators? What is the incentive for any of this?", and we all know the answer to this question. We are all volunteers who are doing this in our free time (and to be clear, I say "we" not to imply that I have any stake in the community personally, but to express the communal nature of the project itself; I could say "the devs", but that would make it feel like us casual players are the mere peasants bowing before the almighty developer gods, which just feels wrong). The actual hosting required to do this would probably be provided by someone just as passionate as I am for the project itself, and passionate and enthusiastic enough to not ask for anything in return, just like what is already the case with our developers, artists, and animators. I, for one, really wish I had the free time to actually start working on a solution to the problems I am bringing up here, in practice, but sadly, I do not. Believe me, if I had the means to personally revamp the networking code of the whole project from scratch, and provide my own servers to accomodate for the increased hosting costs, I would. But I have too many personal problems at the moment, so that's going to have to wait. It's also worth pointing out that yes, it would take a lot of work to make something like this happen, and it would definitely present some unique technical challenges along the way (what we are doing now is mere speculation in comparison), but the reward is permanentaly solving the problem of reveal-map cheating at the technical level, and I would say that's worth it. Nothing worthwhile is ever easy. I too, think I will stick to the vanilla GUI, because it is "good enough", and easy to wrap my head around (compared to dozens of custom macros and scripts). But in general, the goal of any user interface design is to minimize the amount of physical effort (clicks, taps, button pushes, keystrokes, pointing, etc.) that it takes to make the computer do what you want. That's what these mods are ultimately trying to do, and if it turns out that the use of these mods trivializes the whole game for the person using them, then I would consider that a problem with the 0 A.D. gameplay loop, not the mods themselves. I already said that I don't call the cheating problem "vacuous" to mean that there are no cheaters, which I obviously don't know (except, if I am to take The CJ's statement at face value, we may be going somewhere). That's not what I mean at all! What I mean by "vacuous" is that there's a technical solution which instantly eliminates the cheater problem, so there's no need to point fingers at each other, or worry if the game you were playing had a cheater in it. Maybe there is, for the time being, but I'm not worried about the whole community being dissolved because there are too many cheaters, because I think the community is pretty clear on what technical interventions can be done to turn the cheater problem into a complete non-issue. ProGUI's restart-autoqueue feature probably works by constantly checking if a recently-stopped autoqueue can be restarted, based on resource counts, and autonomously sends the commands to restart it if so. This doesn't need to touch the simulation directly in order to work as advertised. Maybe it could be helpful to think about the simulation/GUI distinction in philosophical terms rather than technical terms. The simulation contains the positions of units, individual players' resource counts, and stuff like that, as well as the logic that defines how these values are able to change over time based on outside input. The interface contains ways to interact with those values, and provide input to the simulation, by means of a keyboard and mouse, or other input method. In short, I don't think the auto-restart auto-queue feature is a cheat, and I don't think it should be considered a direct modification to the simulation code. Nothing about it makes it more significant than any other feature of these GUI mods that provides any sort of automation (i.e. unit/structure orders being given by the GUI itself, with no player input required).

GUI mods which do not change simulation are little more than tweaking graphics options in the settings panel. 0AD's exposed customisation options are rather limited, but most features of the GUI mods e.g. ModernGUI would be provided by default in other games. ProGUI's automation features are no longer GUI mods. It makes changes to simulation. ProGUI is a combined package of a GUI mod and an autoqueue mod. People debate about the autoqueue part and not the panels. Note that all mod-level information reveal cheats have been patched since A27. It is no longer possible to make a cheat mod (pure js level) that reveals information, because the engine commands have been insulated. If you want to cheat, you would have to edit the engine and hopefully don't get a fatal OOS. Cheats are not as OP as you think. They are too distracting to use as your screen gets cluttered by too much information. It distracts you from your micro. Reveal map hack in A26 required you to constantly switch back and forth - less apm available for actual playing. Reveal chat baited its users into sending resources to the enemy. Seeing the trash talk in spec chat is really distracting. That's why nobody consistently used cheat methods in spite of them being so easily accessible, in A26. In conclusion, Pure GUI mods are fine but packing in some simulation changes will be questionable.

Update: Autociv 27.0.3 has been released: https://github.com/nanihadesuka/autociv/releases Features: Additional counters for total mobilisable military, melee, range, KD ratio A page in options to adjust update frequency and the counters that you want to see

np, thanks for your answer. Primarily use I designed it for was as formation banner like in this picture, so once for every formation. Secondary use could be for a standard bearer. There are two carnyx (the trumpets) for the gaul trumpeter, which both have around 1.500 tris, so I figured to aim for a similar polycount. Don't get what you mean with the last sentence?

Currently you can do - civ_infantry e.g han_infantry (everyone can train han infantry by capturing this building - {civ}_infantry gets replaced at run time by the owner civ if such a unit exists for them - {native}_infantry like 1) but dynamic useful if you have three embassies templates with different civs for instance.

Is that the biggest obstacle? Honestly, I think all that needs to happen is to come up with a consistent scheme to determine what units are available from captured buildings.

Technical borders: Any mod which only changes art and audio folders are completely safe and non-cheating. Most mods that change GUI are safe and non-cheating, unless they reveal information about the enemy, which is no longer possible. The reveal chat vulnerability has been patched and no single change to gui folder can enable you to access forbidden information in A27. Real cheat mods would have to touch the simulation folder. But this comes with high risk of fatal OOS @WiseKind I appreciate your effort in writing such a long and meticulous essay

Be more specific please.

just change captured buildings behavior. I swear, the biggest obstacle I can see to 0ad progression is bogus features that won't ever get corrected because some random dev likes them in spite of all reason.

Hey sorry for the delayed answer. The polycount limitations highly depend on the number of units with those things. You can check out the number of tris in the editor, (disable shadows in atlas first) but i feel like it should be 400-500 considering unit models without props are around 1000. Lods are an option though and we could have a higher quality version for high quality model level. Does that make sense?