sternstaub

we are lucky to have the option of flatpak (or to change linux distro; 0ad worth it... i thinkkk...) This makes me wonder: was 0ad and pyrogenesis not supposed to be seperated one day? this could ease building process, right ?

Nice, looking forward to see it

We don't have a ammunition system (yet) so this might be more work. Or maybe use the wood resource carry of the units? Finally a purpose for units carrying piles of logs into battle! Ammo cart could be a two-sided storage for wood in this case, where they can either put wood in or take it out (remove res). Ranged fighting was costly, after all, and that is the main reason why they are currently OP in an unrealistic way. They have infinite arrows. This solution might be tricky with the mounted cavalry tho. Could make it depend on unit level. Experienced units swap faster. I like how you think It would probably feel even smoother if units had some kind of charge damage / stun if they run or even ride into battle. Probably should only be possible for battalions to ease computing.

Thank you! I was not familar with Delanda Est so far.

Concerning the change of game behaviour, i find the macro topic interesting aswell, probably for similiar reasons. It appears evident that with a growing civilization, you would have more units to control, thus requiring you to apply other means of organization. Other things, like economy and troop supply chains, become more important. It even appears reasonable to me to add a new zoom layer on phase III, so that you could zoom out further, having symbols for your most important troops. A bit like a "fullscreen glorified minimap". Player would zoom full out, then a bit further, and game might toggle view, showing control groups etc. . It might even reduce the renderer usage, because with a fixed "civilization / imperial perspective", the DoF and distance LOD should probably behave in a more predictable way. But that goes too far, and are loose thoughts only. Still, i totally like the idea of learning someting from American Conquest here. Speaking of late game economy and micro intensity: Controlling citizen troops as a pure combat batallion is ineffective in 0ad because you lose workers. It has been written many times. Someone suggested an interesting solution for that as well. It was about having garrison effects for buildings, f.e. shorter unit production time. I would like to connect these ideas conceptually here. What if you could garrison a batallion into a fortress, and then the fortress could spawn troops (faster with bigger garrison). Would also make unit behaviour more predictable in simulation, potentially performance increase. Phase III elite troops could have a faster training rate than cheap citizen soldiers maybe. Also, since the garrisoned troops are training new units, they could be locked during the queue, but gain a few XP for it. Over the time, you might lose many cheap forces as meat shield, but meanwhile would form a small elite force. It could be interesting. Also might be very helpful to have freshly spawned units from a building appendeded to an assigned batallion / control group as a setting.

(please be aware that this quote refers to a 2017 thread) ...while this is true and soldiers should not be standing around in a formation, i still feel like there should be a higher utility value to them. At the time, they feel like more of a hindrance; it can become very confusing in late game to keep track of all control groups and additionally managing their formations, expecially with the persistent lag problem with many armies. Plus, it can cost DPS and, summa summarum, is not worth the effort. And it indeed feels like there are no players who are seriously utilizing formations, unless units are simply standing around. One problem i see here is: Using formations can indeed make sense some times, but they would not be useful for every move. So, for example, i expect an incoming cavalry attack, and thus want to place all spearmen i have to form a broad, but thin line just to stop the advance, while keeping for example swordcav ready in a flank (f.e. triangular attack formation) to inflict the main pain. But as soon as the battle starts, i would not want the units to seek formation, run around and look for a nice lined-up spot - only maybe for regroup -, but rather to attack, attack, attack; dps, dps, dps! Concerning the matter, this remembered me of an oldie RTS i played ages ago, and how they solved it. Maybe someone knows it, it's name is "American Conquest". It also had a feature to organize soldiers in formations. You did not click (movement command) to put the units in a formation, but right-click, then draw the mouse. Even when a group had a formation set, a simple right-click would just be a regular movement order. The game did then render a preview for how the units would "place themselves" on release of the mouse button.This command could be cancelled by left-clicking the mouse. But besides from separating regular movement commands from formation / battle commands, this has also the nice effect that the facing direction of soldier formations can be easily aligned. This would probably not too hard to implement, and i want to take a look at this at proper time. But first, it would be interesting to know what you think about the formations in the game. Do you use them? Have you thought of using them, but found them to be a hindrance to your gameplay? Or do you generally not give thoughts to these things?

This problem is probably different from mine, since i am using neither ubuntu nor wayland. Anyway, thanks for sharing the solution for other people who need it.

After rebooting, it worked. Changing the path of local.cfg must have fixed it. Why the reboot was neccessary, i don't know.

For the time being, i set it to windowed mode by default. In my a27 build, the problem seems to be fixed.

Are you sure it's not "spirv"? I deleted all custom config and set the user.cfg to rendererbackend = "glsl". The game started thereafter. Then i went to graphics settings and changed backend on drop down menu to "vulkan". The user.cfg now also says rendererbackend = "vulkan". After i restart, that happens: log afterwards (now not so big anymore, last lines): Now i set it to "spirv" in the user.cfg, as it says in the source code, and the game starts. It has some weird graphic distortion in the first seconds, but then seems to work. The DropDown Menu is empty now: I reset to vulkan, user.cfg again says rendererbackend = "vulkan", and the same thing as above happens. I see that, if i put it on "opengl" ingame, that the user.cfg says "gl", not the thing that i entered above. But i wonder: if i place an inapplicable value in the config, then why does the game not say "Can't find a usable technique"? Because i have not provided the configuration for a valid technique, after all. But instead it simply starts. Probably some issue with the vulkan installation (although i am quite sure to have installed all the packages). Anyways, this is unrelated to the topic. Is there a general thread for technical problems on the forums? Did not encounter one so far ^^ However, after putting this in here and i start the game, it shows: EDIT: vulkan problem fixed for me.

Guter Hinweis Then it might be interesting for some people if the density of these checks could be reduced in game settings until the problem is solved. That way the host would have an option to sacrifice security for responsiveness, for example if you want to play higher troop amounts. Questions would be: is this implementable, is it desirable and is it responsible to assume that players know what the option does? //EDIT: hope this does not go too off-topic here.

Step 1: Step 2: - start pyrogenesis and await error window - press "debugger" - await another error window - press "debugger" again Step 3: Browser crashes after these lines: edit: vulkan problem is fixed for me. still would suggest to not have the game generate 50 GiB of a logfile.

I will certainly do that. But how should i attach a 50GB log?

My mouse cursor is in a wrong position when i start the game. For me, it is fixed by entering and exiting fullscreen once (Alt+Enter)

It was too big to open and i deleted it because there were only 500MB disk space left, sorry But i recall that it was about the shader backend. There was a wrong value for it in the config and i tried starting the game several times. It was set to "vulkan" instead of "spirv". Probably i set it to "vulkan" myself. Maybe that was the reason. Oh, and on the error window, i pressed "debug" once or twice ^^' .

That sounds like a valid explanation. I indeed tested a27. Good to know tho that it becomes a balloon, thanks for the information .

Hello friends, is it normal for the logfile to exceed 10GB in size within a short playing time?

Also a nice place to live in, really And to study data science.

Still too many questions for any choice. common problem. fear of enjoying too much later.

"Fischernetze" ist der Name der I Tech für Fischerboote. Hellgrüne Punkte auf der Minimap sind Nahrungsressourcen, sprich: Beeren und Fisch. Ingame kenntlich gemacht durch Möwen, die darüber kreisen.

You don't. But is is not neccessarily required to simulate a whole planet at once. The thing about video games is that they are actually a delusion. Maybe change the question. Not "how to simulate a whole planet?", but "how to make the players brain adopt the idea of commanding troops on a planet?". There would basically be no practical need to render 100% of a large-scale map. Trees within the FoW for example - who cares? They only must be graphically rendered when cam is near, and value only must be computed while being farmed by civil units. Which brings me to ask, could PG do chunk rendering? And if not, would it per design be rather simple or rather hard to implement? Do all maps have to be circular?

Well, being locked would eventually lead to problems in most cases. Tho, i understand your point and do not seek to contradict. From what i can tell by now, in multiplayer the simulation is done on each client and then compared every n milliseconds. It actually feels like that when i am playing the game, as if the simulation would do a brief freeze every half a second or so, then go on, then freeze etc. I think that the synchronization of clients would be a good occasion to implement multithreading, wouldn't it? It is not crucial for the simulations of all clients to be 100% certainly* the same, as long as the clients can be expected to behave in the same way (we are talking about multiplayer integrity checks here, big/hot topic on it's own for a moddable game). Meaning that maybe not all checks should be done during the running game, and if so, then probably asyncronous, using free system resources. Maybe - i do know neither the computing effort neccessary for such task, nor am i familiar with the enigne design yet -, the game replay might be serialized by host on free cores, so that there would be a static reference for all clients to correct sim state, or to check whether the sim state was correct 1 minute ago. But possibly, that is not a good approach. Let me give a scenario. Let's assume that all of our clients are in gamestate X, and that their simulation will start according to state X, that their units will behave accoring to gamestate X. Meaning, all players apply the same logic to the same values starting on the same map. From this starting point, given that all the players commands are shared on network, the game should be reconstructible for each client in the same way. This would mean: if it is now ensured™ that all the clients behave in the same way, and that each client started using the same terrain, entities etc., then this could lessen the data exchange amount required between the clients, right? Ideally the datasets which must be accurately synchronized for each players main thread would then mainly consist of the commands given by the players, instead of constantly checking the whole simulation. If this would actually work well, it had another implication concerning deviations between clients. Because, if the clients all behave in the same way, the verification of simulation states, meaning the actual ingame synchronization between clients, (-> multi player integrity check) would eventually become a check which only seldomly throws an OutOfSync Error, would it not?** And if that is so, then there should probably be main thread synching between the client as soon as there was some asynchronity detected by the - asynchronously running - integrity checks during the game. The clients could then be put on pause and getting a loading bar for the synchronization task or something. In handling this OutOfSync error, we would then do stuff to ensure that our game returns to gamestate X, or give the host the ability of canceling the game if there is a malicious behaviour suspection. An Error is something that should not occur, after all. Probably the main question here is: how do we ensure that multiple clients playing together are simulation-wise in an equal state (not graphics-wise, nor sound-wise, but rather data- and scriptwise)? Can the certain checks be obsoleted by client-code design? Another question in this context: What if someone gets the game code, changes it in a cheaty way, just pretended to be a normal client (version etc.) and then connected to a multiplayer game? Would his differing game state be recognized beforehand, or would the game just start and then keep throwing the OutOfSync? Because that would be quite inefficient, i think. === * Please interpret the term properly here; they should be ideally 100% the same, but it is not neccessary to do this check in realtime/main thread. So, technically, all clients in a game could have had 100% equal simulations, but they did not actually check that during all of the game, but rather assumed it because they would have taken some security measures beforehand, ensuring that equal simulation starts->outcomes, equal json and xml, equal binary behaviour could be assumed. **I've encountered about 2 or 3 OutOfSync errors so far. Assuming that there is 1 check per second, applied to 10 hours of playtime, that would be... a little percentage of the checks being "positive

I am searching in the code, but have no clue in which cpp that functionality is implemented. Maybe someone could give a hint while i keep searching?

Thank you There are some spots which should block pathfinding, i tried to make these spots recognizable with different textures, like cliffs. If that is what you mean. Yup, i have also encountered these problems with the AI. I could create a Singleplayer-version of the map (as scenario, not skirmish) with AI players that are already settled. Also, a 4 or 6 player version would definitley make sense. Also i have to say that it is probably poorly balanced, because i have not played the game long enough to know proper balancing. There really is abundance in some places (abundance of ore in the mountains is intended). With 5 players, maybe this could bring some dynamic with trace?

Maybe make stone walls stronger against siege weapons while making gates weak?