strat0spheric

now i have a flatpak-installation yes. but i compiled from source first directly after release and had it all running. I removed all after experiencing the low fps and lag and tried flatpak ... works - but no noticeable difference in performance between the 2.

mxlinux .. based on debian bookworm

i just watched the replay of a 4v4 with really low fps as mentioned in previous post. For me gui sim update during late game was mostly around 15 with certain periods above 100 msec/frame with sim update between 150 and 300 msec/frame. But overall mostly gui_su is iaround 10% of sim update.

i guess you don't mean me in this context Because i am definetly against the automation - but what i meant to say is that fairness in terms of equal conditions for everyone is the most important aspect for me. I prefer definetly to juggle all balls.

@Atrik I want to add to my posts that i really don't want to discredit your work and effort for the ProGUI in general. As far as i have read about it you introduce some interesting and useful features that might also be considerable for an implementation in the vanilla version, e.g. showing idle barracks or buildings (I mean vanilla already shows idle units). A lot of respect for that. All the improvements of a GUI that are not really automating tasks, are not of my concern. I also don't want to throw the autotrainer and startup-script in the same basket with the cheats, that reveal the map or reveal enemy stats and chat. This is also another level, imo. But still automation makes a difference and does change the required attention and concentration and multitasking. This is what many players judge as unfair. If automating the unit production would be part of vanilla, and hence used by all players there would be even conditions as well. I could also live with that - because it would also reestablish fair competition. I expect of a multiplayer game, that skill decides. You can compare your performance with others, learn from replays, improve your eco-management and hopefully improve your gameplay and lvl. So that rating at the end means a thing. What could i learn from replays of a player using automation or how could i compare my skill level with yours if i wanna stick with the vanilla? Surely, atm this is my problem and i can avoid it if i don't play with people who use the autotrainer (still this is not visible to me before a game)... but basically i would prefer if there would exist a common understanding and gaming culture. I know i am only talking about a feeling here, which might be considered naive. But, just given the fact that there is a rating system (even if it is definetly not perfect), leads me to the assumption that the developers intended to provide it to make a fair comparison of skill levels possible. If we had dedicated servers, the providers could define their own rules of gameplay for their server and ban certain tools. But we don't have that, nor do we obviously have means of simple detection for cheats in general. So imo it would be favourable that for now it is visible for everyone what WFG considers as unfair and/or cheating, which includes answering the question if they tolerate autotrainers and startupscripts or not. I just miss the orientation here and it is obvious that others have the same issue, because the point 8. of the TOS is obviously too vague to give a clear guidance. It could be added, that "when not explicitly mutually agreed on..." But i guess, after this endless discussion, which turns out to change nothing that i have to call my games tg(vanilla), as @TheCJ recommended and trust that people switch the autotrainer and the startup script off when we play together.

Yesterday i had 3 4v4 games. All of them ended up at around min 13 or 14, when the battle started with 1! fps for me and the rest of the players. Thats basically not playable. I would have been happy about 10 fps. Since a27 this is always the case. I had at least around 6 to 8 fps in a26 in comparable situations. PC: Razer blade stealth laptop on i7. Here is my commands.txt of one of the games yesterdaycommands.txt Edit: i have to figure out the profiler thing ...tbc

@Meister thank you for this honest explanation of your experience !

yeah, true. This is also making a difference. But maybe not that much of an impact as the autotrainer.

...to be more precise: you should call it "autotrainer welcome" because this part of ProGUI is what is relevant. Not the GUI improvements

np, @Atrik for sure you are not hiding it because everyone who read the forum knows it I didn't mean that. But i mean it is absolutely not clear who in the community else uses it. To exaggerate a bit: At the end i might be the only one who doesn't use it and doesn'T even know

I agree on the 1st suggestion as a direct measure but on the 2nd i have my doubts this will be ever done... As i mentioned. This requires the self-awareness that there is an issue. That is true, but i still don't know who uses it and i don't want to ask everybody. As this question would have to be raised every now and then as there are always new players starting to use it. It is only you and 1 more i know of that are using it.

.. this is definetly not the case

hi Atrik, wdym with creating SmurfS? I hosted many games and i am not aware of the mods players use. I don't even know how i could be. This is beyond my technical skills. I am sorry. I dunno how everything i said is interpreted as a lie, Atrik. What exactly do you think i lied about ? I think there is no need to get personal.

Unfortunately, the playerbase doesn't seem to bother or is not informed enough. I personally don't undertand why this topic is not getting more attention. The thing is atm i don't see many options from a player perspective to deal with the problem. I mean a player could add a flag "noProGui / autotrainer users" to the games he hosts. But how could he make sure that this rule is followed, when you cant determine the mods used by a player? Or, could this problem be approached from the other direction? If the ProGui-community would be more self-aware about the advantage they possess and honestly express the use of it (e.g. adding a ProGui flag to their username)? I mean using it is one side of the problem, but disguising it is the other side. But, what would happen to the community in these cases? Would it split the community ? In my opinion, the discussion in this thread leads to 2 other measures that address the developers and the "WFG-authorities": 1. Provide a technical solution that shows the used mods of a player in the lobby and more important: 2. Define more clearly what is considered "unfair advantage" according to the TOS and add this definition below the welcome message in the multiplayer lobby (just where there is already written: "It is a violation of the terms of use..."! (At least the word auto-trainer should be listed there) -> remove the grey area and the room for interpretation If there is no consensus on the 2nd point. This will never be solved. ... and all the RangerK's and Dakaras and myself and so on will be left frustrated and at a certain point leave the game or use the sh** themselves...

my post wasn't meant to be a reply to your specific post, but to all the others who obviously use autotrainers and stuff and don't call it an advantage. Which is ridiculous cause that's the reason they use it. To gain this specific advantage. Andyes this is not a), as stated above. But surely a graphic enhancement of the ui and some nice shortcuts and seeing allied stats as with the normal autociv when used as intended is not really giving you an advantage in the gameplay.

crazy that people possessing and using a tool that gives an advantage over others without the tool can't name it as it is ..... parallel universe ? a) what counts as fair: same conditions for all parties what counts as unfair: not a) ! it is so simple.

Hello, i compiled 0ad a27 from source on my linux machine. It basically worked but as there is a flatpak available now i would like to use that one to see if the performance might be better. ... but ... i don't know how to uninstall the compiled version. Could someone give me a hint on how to do that, so that i have all unnecessary dependencies also removed. I didn't find any uninstall instructions so far. Thanks

Hello ! I am posting this for Chesnutter, cause he asked me to I think these are great and probably ambitious ideas for improvement of the game.... (i hope this is the right place for it .. if not please move it) Hey, I’m a Roman history fan so my knowledge and focus is on them more than other ancient civs. I think these would make playing as and against the Romans more authentic, fun and challenging. Bear in mind I have no coding experience but here are my ideas. So, Roman engineer (unit) builds trenches, traps and roads. OR it could be just the basic infantry unit. Historically, Roman soldiers were part fighter and part builder. I think a greater emphasis in 0ad of this would make it more real. Trenches (with spiky stakes or simply a deep empty moat (with/without water): - Doesn’t prevent enemy infantry movement across but slows them down a lot (80% speed reduction) - Doesn’t damage infantry unless spikes/stakes tech upgrade (like a gate in a wooden wall however you could double click to select all trenches in view to upgrade them to have stakes all at the same time - Requires a lot of wood. - Cheap and fast to build compared to walls but in some ways less effective. Available in phase one, degrades over time(?). Built like a wall across an area. Good against early cav rushes. Prevents cav and siege from crossing. 2. Traps/pits « lilies »: - heavily damages and slows down enemy infantry and cav, but doesn’t damage rams. - Expensive to build. - Built along an area (shown as a bunch of small holes with spikes in them) - Barely visible for a realistic element of surprise. Maybe once enemy units have been damaged they become viable to the enemy (like trenches degrades over time). Would this be hard to code? 3. Roads - speed up movement of units (allied AND enemy). - Available in phase one though maybe cost prohibitive unless teammates contribute resources - which I think would be cool, increasing teamwork and community interaction (which is what I like about gaming). - Built out on the terrain and any units moving on it move 20-25-30% faster. - Requires wood and a lot of stone. - Built mostly straight to make it user-friendly (curved or zigzag roads wouldn’t be playable). - Shift right click to make the units go from point A to point B (so they walk along the road). - Or it could work a bit like a hero/monk where when they are near the road they move faster (but less visually appealing IMO). Does this make sense from a user POV? - Roads could be built through forests, bogs, hills, rivers etc... just like the Romans did it. I don't think roads would make the romans OP because the cost would be fronted by the user building it but it could also be used against him. *Roads are one of the things that made it possible for Rome to conquer the known world (and for them to be conquered themselves by « barbarians” in the 200-400s AD), so I specifically like this idea. 4. (Non-Roman) Need to be stronger against Siege. Wooden walls should be cheaper to build and faster. To make possible what Caeser did in his Gallic wars. Ie Alesia. OTHER GENERAL IDEAS to increase historical accuracy and more interesting game play. Range bonus for troops/siege on hills. Attack + defense/health bonus for troops hills. More implementation for defensive formations (like Romans) but that players actually want to use. Slow attrition for armies not in allied/home territory. Attrition for armies/troops in the sun VS healing rate for troops in the shade/forests. Defensive bonus for troops fighting on edge of forest (to imitate guerrilla tactics). 0zon “Cost surface” ideas + some input from me. “With a cost surface function recalculating range or walking speed etc. based on attributes such as slope, altitude or landuse type (forest, meadow etc.) some of the ideas could be maybe technically implemented..…” - 0zon Reduced speed walking up hills. Reduced speed walking through forests/bogs/sandy areas. Increased speed for troops on flat/non hilly ground (specifically for cav). Rams can only move on flat open terrain. Increased fertility/food gains on flat grassy areas (for farms). Increased building costs on non-flat lands. Forests that regrow. Rams get attack bonus when garrisoned. Allied temple’s aura also heals troops. An idea from LeiftheLucky (I think) Ranged units have only a certain amount of ammo and then they have to use melee or/and go back to allied territory/cc/barracks/garrison to replenish stock. Keep up the good work and THANK YOU! Chesnutter on 0ad Edited several times for spelling and formatting

(just to throw a brainstorming thought in here without knowing if this is possible or feasible) create hardware hashkey linked with password hash upon registration? if hardware hash already registered with different login... no hosting or no new account can be created. But this is probably problematic for new installations on new machines and of course only doable if full privacy is guaranteed.

sharing links to cheats ... this sole action stands alone .... no matter what else. whoever does it doesn't care about the reputation of the game or that new players and the community play clean... The resulting doubts among players about the other players do affect the community... i must say... i am pretty close to stop playing this game unless i see that measures against cheating or spreading cheats are implemented that actually work or at least the effort is visible to the community. An it all starts with clearly condemning the use and spread of cheats of all community members and especially the Heads of this. Tolerance is not appropriate in this case. ... Reading other posts about the topic of cheating leaves the impression that everything in this community is tolerated ... clear expressions and an establishement of an anti.cheat culture are not emerging ... really sad ( i know that surely someone will reply to this.. that it cant be addressed because there is no consensus about what is cheating.. xyxsdhjjkhfusj.... and this is the core of the problem!) This might be considered off topic. But I don't care about which are the multiple accounts of Yekaterina or the personal issues he had in the past with others. This doesn't affect me as a current player .. but spreading links to cheats does...

Please... act!. Write down the rules for what is the code of conduct and what is considered cheating. Just do it!!! Guerringuerrin has already drafted something. Use it and publish it. Cant be that difficult. And if you wanna change something afterwards then do it afterwards.... This topic needs a solution .... It cant be that hard to get these few lines out...pleeeeaaasssseeee. I want some orientation as a player ! I am sure you would make many players instantly happy..

If an option for hosts would be implemented, that enables or restricts the participation with the controversial mods... no assumptions would be required anymore, as you will have numbers and figures about how many use this option... this would give a clear picture about what the players prefer and raise awareness as well

Hi everyone. i have no development experience and i admit i can't understand all the technical issues mentioned in the post. I just like to play the game ....but I expect a multiplayer game to be a competitive little "race" where skill and strategy should decide the outcome. Every player imo must have the same basic technical prerequisites to ensure that skill decides .... If ProGUI (... the name is misleading btw as the mod obviously is much more than a GUI - i didnt know that a long time) is adding some considerable advantage, then it is not a fair basis for the competition. It is like you would have some motorcycles taking part at the Tour de France ... If people like motorycles....fine, they can compete with other motorcyclists.... but imo not with the byciclists...(and call it a cycle race) I do understand that things are a bit different in an open source computer game. And some consider the development and use of automation and the "little" extras more as a kind of car tuning in formula1 ... but i think for a multiplayer game this should be absolutely limited and transparent. If all in the game use it it would be fair.... if none in the game use it it is fair... nothing much inbetween imo. (I mean the automation stuff - not the GUI part) Overall, i think solving the issues raised in this topic is very important for the community and the attractivity of 0ad, not only for the experienced players. If new players know that there are cheats which can't be prevented, or efforts to do so are not visible, they might be deterred to start the journey of 0ad. So i am happy that this is beeing discussed here and hopefully be solved somehow. As i said i am not much inside the technical aspects, but i like the suggestions of @Alnur earlier in this post, to synchronize and overwrite mods before gamestart as it seems to guarantee everyone is playing with the same technical prerequisites. And if this is an optional setting ... also fine. So I coud host a game with my kind of "punkbuster" activated and other hosts who don't care could just deactivate it ... (Would be interesting to see how many activate it, btw)

Thank you all for the responses. I think there are some good suggestions on solving this maybe in future releases. The idea, that a CC in nomad mode is built instantly without the ability to be blocked by an enemy unit would definitely solve the problem. Making it invisible is maybe not really working, as it might be clear where the CC is going to be built by observing the units. In this case, as i described the situation only 1 cav following my units was enough to observe my target location and block building by putting this cav on top of the site. I did not delete the CC, because of 2 reasons: 1. there was only this spot available, as all other closer areas were forest - rebuilding somewhere else would have led to find completely new area -> too much time. 2. i was afraid to loose resources by deletion and not beeing able to rebuild. (according to @real_tabasco_sauce - this would not been the case. From the discussion can i take away, that at least some would agree, that blocking CC construction of an enemy is not a valid technique and unfair gameplay? So until this issue is solved technically a code of conduct for a host of a game might be just kick the player who blocks construction until construction of the CC (even on other location ) can be started. Another solution as @AInur posted would be not to play Nomad mode.... but tbh... nomad mode on ambush map is really fun sometimes... i would miss it.

Hello Forum, i want to report this issue with a known bug, that can be used or "misused" as a technique to prevent opponent from building his CC under nomad game with ceasefire. As i know that in 0ad this bug can happen by chance with own units on any building, it can even be exploited in the aforementioned condition. I guess it is not an easy task to solve the bug, but i would like to discuss this issue as i have the opinion that it is unfair gameplay to use this bug strategically in the minutes of ceasefire in a nomad game. Preventing the construction of an opponents CC in the minutes of ceasefire leads to an unfair advantage for the game. What are your opinions on that?