Forums

You can add the -editor command line argument Regarding Atlas some work has been done by @trompetin17 to get rid of it and instead do everything inside the game.

That would be a question for @real_tabasco_sauce for the main game or @wowgetoffyourcellphone for DE.

! this is totally different from the hash check stutter. edit: might just be the camera + the usual stutter, its hard to say.

Personally, I see the mechanical challenge of real-time strategy games as a necessary evil. To help illustrate what I mean by this, I will share a snippet from my story in getting good at this game. When I look at my old replays to find out just how stupid I used to be when playing against the Very Easy Petra Bot (I've come a long way since then), I could make the correlation that my APM (I'm assuming this stands for "actions per minute") was lower back then (which was in large part because I spent large portions of time sitting there like I didn't know how to play, because I didn't), but I also see myself doing super cringe stuff that any decent player would immediately call out, like trying to destroy an enemy building with projectiles, or capturing a fully-garrisoned tower with only 6 units (It didn't work, and all of the units just stood there, trying to capture, until they all died, having accomplished nothing). When you play 0 A.D., you are responsible for controlling hundreds of in-game characters simultaneously, compared to the one character you control in most genres of video game. It's unavoidable that such gameplay can feel "cluttered", with many things going on at once. But, as I said, this is a necessary evil, and the game wouldn't necessarily be worse if someone made an overhaul of the GUI that suddenly reduced the need for fast typing, even if such fast typing has grown to characterize the RTS genre as a whole. Many features that have been added to the vanilla GUI have been in the direction of reducing the number of clicks required to make something happen. And that makes sense; why on earth would you introduce a new feature to the GUI that makes it harder to control? If, for the sake of argument, we say that any given feature of this kind were implemented in vanilla, making it available to all players at once, it would necessarily make the game better; that is what I mean when I say that the mechanical challenge of 0 A.D. is a necessary evil. Another example of a change that has made the game better for everyone is something I have noticed occasionally: when you order a unit to garrison inside a ship, the unit will move toward that ship, but the ship will also move close to the units to help save time, and once all units are picked up, the boat will automatically move to its original position. I think the game would just be more frustrating to control if this didn't exist. If the game didn't move the boats for me by default, but someone else decided to add in the extra time and keystrokes to manually move the boat back and forth as the units were attempting to garrison (or used a mod to do it for them), then they would have an advantage; you can say that this amounts to an increase in the learning curve and skill ceiling of 0 A.D., and it very much is in some sense, but the game is worse for it. I would still like to make the claim that this feature that you are all bringing up, the auto-restarting auto-queue, IS in fact a GUI level change. All that the mod would need to do is keep tabs on any auto-queues that were recently stopped due to insufficient resources, and then constantly check the resource counts to see if those queues can be restarted. The only precedent set is that the mod is issuing a command to the simulation all on its own, which is something that the vanilla GUI doesn't do. However, I would also like to point out that I think 0 A.D. generally keeps a poor separation between the game itself and the interaction with the game, on a technical level. I suspect (though haven't confirmed yet), that the logic that causes the boat to move back and forth to pick up units, is done entirely in the simulation code; the vanilla GUI doesn't automatically calculate the optimal piece of shoreline where the units should meet, issuing a move order in advance. But to me, whether or not this feature exists/should exist is a matter of interface usability and convenience. I think the current separation between GUI and simcode is currently based on each click done by the GUI representing one command sent to the simulation, which then does the rest of the work. In other words, the click to action ratio is 1:1 in vanilla, but mods can skew this by adding macros and automation. This is why I said before that it can be helpful to think about the interface/simulation distinction in more philosophical terms, rather than going based on the current technical implementation (which, as we should all keep in mind, is subject to change).

yes I am aware for the JS side, it works fine, my question was more about the c++ code Actually I can work on the atlas / Scenario editor, it's just I had to close the app, rebuild the solution (on "selecting" "pyrogenesis") and reopen the scenario edit passing through the 0 AD menu each time I want to test/see my change, is there a better way to work on the scenario editor ?

ok nice cool, i didn't know. If there's a wish to implement roman standard bearers (Signifer, Aquilifer or vexillarius) I would be happy to make meshes with less tris. Here are some references

@SneakEP is becoming op at commentary!   The stutter and camera shakes are kinda EXTREME thoughts.... RIP.. Could also be used to illustrate an issue/motivate the a27 relaunch.