elexis

I'm sure we can obtain a great database from matches this way, but I have the suspicion noone uses the replays for the purposes of moderation, or at all. @Imarok the most recent idea of the rating fakery fix was that WFG hosts all rated 1v1s, disqualifies players after being disconnected for longer than N minutes, records the replay, but doesn't actually simulate the game, unless the reported hash values mismatch?

I said something wrong, the PMP file only contains the terrain, the random map support would need support loading the XML file for that mentioned approach. Might be a good tool to have. One of the problems with the more generic approach is that these VisualActors don't have obstructions nor footprints. Otherwise they'd be so large that we could continue to use the mapgrid with fixed tilesizes of 1. Perhaps that could be used as a base for implementing the lower resoluted grid. In the first pass the random map is created as usual, then the 4*4 higher resoluted, bad performant, grid is initiatalized and only used for VisualActors. That way one could save some memory and performance. On the other hand, maps need to create the random maps in a specific order, first the terrain choices that consume the most area, then the paths, and then filling the rest around the paths. So that would invalidate the approach to put all visual actors last, if the paths are visualactors. Hardcoding the visualactor size isn't out of the ordinary, since random maps hardcode the tile distances (>= obstruction sizes) all the time. The more difficult task is what to do after having obtained that information. A similar problem occured in Jebel Barkal where the buildings inside the city should be rotated so as to face the path. (Looks more natural and units are spawned on the path, less often in between the buildings). But it was an uncomfortably complex problem that would consume more than one day, not few lines of code and then would only be solved for that one map unless one can abstract the code to reuse it on other maps in similar situations. I had actually written an algorithm for it, but it was too slow, something like 10 seconds, so I had to ditch it. The same problem is faced when we want to create paths that are much smaller than tilesize of 1. For example if you want to have a path that is 0.5 tiles wide, a tree 0.2 and at 0.8, and then create a waving path, not a straight line. Consider this screenshot, the tiny little fences, the perfectly enclosed wheat, the little path parallel to the fence. https://wildfiregames.com/forum/index.php?/topic/24645-specialized-building-decals/&do=findComment&comment=359393 It's solveable, but it's hard. And if it would be solved, it would give a huge benefit. Imagine our maps would look as good as on that screenshot. Other than the implementation being challenging, the question is also figuring out how the cities were planned. The one on LordGoods screenshots looks much more natural than the one on jebel or oppidum. Saw this documentary recently. That guy had shown that historic cities didn't grow by extension over time but were planned on a drawing board with a compass to create harmonic geometry in the city. So I guess I need to ditch the idea of hoping to get away with the existing PathPlacers and not using a simple deformed checkboard as a cityplan. (Even if one would create the city in atlas.) To also post something on topic: https://trac.wildfiregames.com/ticket/1306

Perhaps there is a point that players at least have to show a replay to support but not prove the authenticity of their report. But if one as a moderator already knows that one doesn't have the capacity to follow most rating reports, perhaps one can save the players time and avoid any false expectation of results from uploading replays by clarifying that whenever asking players to upload replays.

Random maps support loading PMP files, so one can create that scene in atlas and let teh random map place some of these. That, or hardcoding sizes would be one way to achieve the screenshot with the least effort on random maps. Certainly you made me explore more possibilites how to implement that.

If every try results in a failure, it would be a failure to continue trying the same thing. The step of adapting the dependent variables is missing to expect something other than a confirmation of previous measurements. So I personally don't encourage people to upload more patches if we don't have the capacity to review them, especially if the people already uploaded a number of unreviewed patches. Been there, done that not getting any reviews. If is noone donating their service but people who can provide the service, the question is how to convince them to provide the service. While contributors have been following the Phabricator guideline to upload patches, almost noone went further than that and asked individual developers personally and somewhat persistently whether they can commit a patch, and why that patch is really important for 0 A.D. to have. Reviewing a patch because one wants to please an external contributor motivates some, but if you can show that a patch is important for every player (for example players suffering mental damage when encountering gamebreaking bugs after having spent an hour to build their base), then the chances to get the patch committed are increased, based on the actions of the external contributor more than the member. Been there, done that. Ideally the workflow is: fail, retry, succeed a little bit, retry, succeed more. Seeking out members who don't review patches but are entitled to doesn't imply unkindness. If someone wishes for a commit but doesn't get it, the question is not to upload more patches but how to get to that commit with the given people who have commit access and haven't vanished entirely yet. So maybe it would be better to recommend people to upload their patches _and_ try to find a reviewer than only recommending the former. The latter is a communication problem, so it is bilateral, i.e. a variable that can be modified by both participants.

How many replays did you watch? Appropriately many? So you're saying we need the replay not to watch it, but to rule out that people report games that never happened?

Sounds like the former game was still listed in the lobby after the host ended and they have started a new game that was shown in a different item in the list. Edit: If you're sure that you selected the right game, then it may be that you could only join the game of the person who hosted first. The connectivity depends on the host (STUN protocol doesn't work for everybody)

@Hannibal_Barca Do we watch these replays?

How did you get the impression that it's the statics update that drops the FPS? I think the summary page is not updated when the page is closed, so there shouldn't be any FPS drop. Do you happen to use fgod mod?

Screenshots can be faked, replays don't contain the information if someone was banned or disconnected, aside watching replays is tedious. When confronting people who were reported, it usually becomes clear after few sentences whether the player participates in good faith. If he doesn't he will usually provide ample reason to be moderated. I think the proposal was that the community give a reputation to players, similar like buyers on amazon or ebay can leave comments about the quality of the ones offering products. It wouldn't affect the rating score, but indicate to players whether the players are toxic or welcoming. Perhaps players find a way to use that system against each other too though.

More wondering about the feature design than the source.

Are the algorithm and code to that pathplacer a trade secret?

The paths were created in atlas or with code? Cant read One doesn't really know which playerslot will determine which playerposition, whether removing the 2nd or 4th slot would turn out to be a good idea. There was one or more tickets describing a feature where players can select the starting position they're assigned to (and how players could chose a group-placement pattern for random maps).

Would require some UI to configure that, but idea is good enough for a trac ticket. If you write one, people will remember it beyond the scope of this thread. Create a map in atlas and allow the player to chose gamesettings, especially civs. Random maps are written with code (thus impossible to create for many), Scenario maps have fixed gamesettings. Didn't we have a patch that adds this exlpanation as a tooltip? Maps look as good as people make them, regardless whether it's in atlas or with code. The random maps have become progressively better and more complex over time. It's expressed in the lines of code: Mainland 200 lines, Red Sea 388, Danubius 800, Jebel Barkal 1500, Oppidum 1800. The big selling point to random maps have is that they generate the terrain and entities after the playerchosen gamesettings, number of players, biome, difficulty, resource selection, ... whereas scenario maps are always the same thing every single time. The atlas map types dictate what map the player can experience, but the random map is adapting to the players choice. The randomness aspect is not so dominant, it's more "procedural mapgeneration" than "random map generation". One can use procedural maps also to load an premade atlas map in a random map and just put random forests and mines on it with code. But we need an entirely new software create random maps that are as detailed as LordGoods assemblies. The random maps opreate on a grid that is few men wide. We would need to increase the resolution of the grid by a factor of 4 or more. But that would make the code probably 16 times slower or worse. Challenge accepted though to create an as good random map to compete with LordGoods screenshots, but it will be hard to figure out a performant system and code to create the complex actor patterns.

∃ ticket The question is what the use of the starting units of an "unassigned" player is. The players who report it see 8 starting units and 1 CC idling the entire game a. And that on all maps. But skirmish maps serve the same purpose as scenario maps, just come with the civ-replacement feature, and the purpose of a scenario map is to come with an map created in atlas. Consider someone would create a map that comes with large prebuilt cities. If the civ replacement (SkirmishReplacer) would delete all buildings, it might not just nuke the 8 starting units and starting CC, but possibly half of the map. So perhaps the map should be able to specify whether it allows nuking playerslots or not. That could be rephrased as a playernumber dropdown. The only counterplayer to maps restricting gamesettings is that players prefer to have their settings persisted when they browse through the maplist. In singleplayer the issue doesn't impact so much, but in multiplayer it's quite drastic. One clicks on host, X players join, then players negotiate the gamesettings step by step. While it would be handy for the developer to first select a map before players can join, players prefer to negotiate the map after having joined and after having made several wishes already. So resetting the gamesettings too often will make the gamesetup stage much more timeconsuming. But persisting settings where possible, but secretly changing some of the settings without the players noticing when switching the map is also very unexpected. So it's a dilemma. The only resolution I could imagine to that is the gamesetup displays a history of which settings precisely changed. So if the host scrolled through 30 maps but then one changes the victory condition from "conquest" to "none", or replaces an "unassigned" playerslot with an AI, then all players might be informed if it's presented well AND all gamesettings would be persisted where possible during mapchanges. Then one could allow skirmish maps to offer "unassigned" if and only if the map maker is ok with the starting player entities to be deleted. As mentioned, ticket somewhere.

The current code expects that a GUI page that is opened with a "callback" argument to be closed with PopGuiPageCB, not PopGuiPage. I don't recall well, but I think the PopGuiPageCB variant clears the callback argument and the PopGuiPage might retain it, which might lead to behavior unexpected by the author. D1684 merges the two methods.

Some examples of this being a repetition of history mentioned in: https://wildfiregames.com/forum/index.php?/topic/25427-monetization/page/3/&tab=comments#comment-370792 2001: 2009: 2016: I found another example at a long staff thread from 2007: Or from 2008 in this thread: In 2004 there were recruitment changes, in 2009/2010 one of the reasons for making the game open source is to gain more contributors after development was stalled. So the doomsday scenario is apparently used inflationary, and that 0 A.D. development is stalled by default unless someone goes ahead and performs every necessary step to change that. For team members that means either overcoming laziness, disputes, or whatever other factors demotivate one. For external contributors that means trying to find ways to convince staff members to commit the patches and persuading staff to grant commit access.

So it calls some JS code from one GUI page that refers to a GUI object in another GUI page. You can only refer to "gamelist" in lobby.js. If that "gamelist" reference is actually defined in lobby.js, I think D1701 could fix that error. I suspect this happens: User opens lobby User joins game Some button triggering your feature Feature closing the page Function opening a new page Function JS code still running in the former GUI page but you wrote the code to run in the opened page Or something like that Would have to look at the code for more details. You could try to move the JS code to the other GUI page and/or that patch.

I'd love to say we should work more on darknets to make corporate censorship impossible. But I see the internet drifting more into the state that china has, where you're only allowed to visit sites sanctioned by the government and get a negative score in the social credit system if you do something that is legal but not desired. People like PhyZic always try to convince me that the people can change the world, but evidently there is no feedback channel, no means of influencing the government. Article 13 is just another perfect example of this. Hundred thousands of people showing up on demonstrations, experts showing that this can't even be implemented and will have detrimental effect on the internet. Any responses, changes in the proposals? Nil. All they did was to change the title of the thing once if I recall correctly? If people rejected it, just repackage it and repeat proposing the same thing as long until it passes. The famous Voss face speaks louder than any words what mechanisms are at play at the heads of governments (both figuratively and literally).

sentences communication help because dunno what timeout

Oh that Heal range tech is a tech pair, got it. I thought the right tech is unlocked by the left tech. Perhaps one could add labels for that. Also the icons are either the same or similar, making it a bit more confusing what is what. So I see two distinct use cases served by this dialog: allows the player to compare the choices of a tech-pair on a single screen allows the player to click on techs that are unlocked by this tech and techs that are required by this tech Please complete the list if there is more. After that we can see how this information could be integrated in the best case.

We could fix the issue that we have multiple reports per day and we can make it easier to report these. We can do both, but one of them would be logical to do first. Keep those fingers crossed, one day we will beat the endboss rating fakery.

There is wiki/GameDataPaths, but that doesn't mention the install location. I've never used the windows installer, doesn't that show the default program folder? If reinstallation doesn't fix it whatever you're trying to fix, you may also want to consider your config files. Just make sure to not lose your lobby account in user.cfg, if you have one. (And replays might be worth to preserve.)

Da da da D1674, #4250 @Itms the question in that revision proposal was whether Dennis actually tests for this case, but looking at the history of zh.public-gui-other.po, it seems like these autobuild commits are not tested at all?

Like Nostradamus?