Great project! And thank you for providing all these files! It inspired me to have a stab at it as well. I redesigned the legs to address the structural issues and did some other minor improvements. Here are some pictures of my version:

Chickens are also not free

@Caliber said:

@nuggets In this test on structurs I used 9 UEF land HQs with 16000k health each the chicken storm did exactly 100,000 damage on structers in this test, so half damage to structures which is still roughly 1.5 free nukes

A nuke would destroy all of this and even more if you placed more buildings.

Dualgap in matchmaker is a nonstarter because it's 6v6 and would have too many connection problems

Yes, that is how gpg designed it

I don't consider this to be an issue that needs fixing

Maudlin already explained the process and that it is not bannable unless it involved rating manipulation. And judging from the OP it doesn't look like this is the case.

Do you not read the discord announcements? There are regular announcements when there are significant changes. Just because we don't broadcast every 5 minutes that we are aware of the situation and are investigating does not mean that nobody does anything.
Nobody knows for sure if things will improve anytime soon. Predictions about the future are hard.

Thank you for that mod! Don't worry about the technical issues, it's fine enough for testing.

I thought some more about the Aeon factories and I think I just dislike changing the design of a factory where it is not needed. The idea is to basically keep the original factory models as support factories. I see that you connected the previously floating arcs, which is a nice change, but raising the platform is not really needed. It significantly changes the overal design and it's a change purely based on personal taste. It also creates the issue that the structures in the back have to be even higher to support the arc shields without units clipping into it.
I do like that you moved the structures in the back further out, this is a good change, it reduces clipping with units and makes the factory look a bit bigger without changing the feel of the design.

I have some more thoughts about the HQ: I generally like the extra elements and animations you added. As I said, I think the shields (purple) should be 1/4 to 1/3 smaller. The pillars (orange) are very nicely designed. I think I would like it better if they supported the raising arc in the front instead of these pure black things (red). I'd remove the extra terraces in the back (green) imo they make it look too bulky.

I'm not yet sold on the new Aeon land factories. Especially the HQ looks too bulky. To me it feels like a UEF engineer's attempt at making an Aeon building. It has this massive, bulky aesthetic. I'm also not sure if I like the raised platforms, although I also have to say that the complete flatness from before looks a bit weird as well.

Having said that, I do like the general design ideas you have. For example, the white shields in the corners are very nice, although I would scale them down a bit, because right now the low texture resolution is quite noticable.
I am sure that with some more minor adjustments we can have a great result.

Could you change your mod to make the original models available as well? Just as another building would be enough, it can even be non-functional. It would make comparisons between the old and new much easier.

It would certainly be interesting to find out why your internet went down completely. Maybe you can find some sort of logs in your router?

It looks like the matchmaker could fulfill most of your needs. Have you tried that?

Nice work you are doing here! I'll have to check out your mod to take an even closer look in the game

TMM already allows this

GDPR allows keeping specific data to protect the interests of the organization, even in the case of a deletion request.

These are exiting times! Now that some long-standing missing pieces of the editor are implemented, we are finally able to release version 1.0 of the editor. The most significant additions are

• Fully configurable water and lighting settings.
• Support for the new terrain shaders that are now available in the game.

You can read more about how the new shaders work, along with some pictures, here: https://wiki.faforever.com/Development/Shaders/terrain-shaders

New Features

• Added support for new shaders recently added to the game (#47, #51, #60, #61, #65, #66, #68, #71)
  • Removed the TTerrainXp shader toggle in the Texture tab
  • Added a text box in the Map tab to input the shader name instead
  • Implemented the new shaders introduced in the latest game patch
  • Added buttons in Textures > Tools to generate the required textures for the new shaders. Under the hood this integrates the Neroxis Tool Suite, a CLI program written in Java. A Java environment is required, but if you have the FAF client installed, you can simply use that one.
  • Added an option to disable the map info texture in the upper slot (via the v button)
  • The specular color UI in the light settings now changes based on the selected shader
  • Many more UI improvements in the texture layer tab to better support different shaders
• Improved lighting settings (#52, #56, #71)
  • Changed sun angle terminology from RA and DA to Azimuth and Elevation Angle
  • Added environment texture path (This texture is only visible on reflections of units, not on the map)
  • Various other minor UI improvements
• Improved water settings (#52, #56, #71)
  • Removed water parameters that had no in-game effect
  • Added toggle to copy sun color and angle from light settings to get fitting sun reflections on the water
  • Added toggle for advanced water absorption (this will recalculate the light settings in the background)
    Advanced absorption behaves more like real-world light absorption, allowing deep water to visibly obscure units and terrain.
  • Added texture paths for water ramp and skycube
  • Added UI controls for ocean waves
  • Fixed water coloration bleeding onto shores
  • Various other minor UI improvements
• Improved default values when creating a new map (#59)
• Improved Resource Browser UI (#62)
  • Added alpha channel preview
  • Added mipmap previews at levels 2, 4, and 6
  • Display texture resolution
    These changes only affect the layer textures. The resource browser is still the same for decals and props.
• You can now import stratum masks in PNG format (#63)
• Made FAF directory configurable (#45)
  Previously, the editor assumed the FAF data directory was at a fixed location. It now supports custom paths, as configured in the FAF client.

Bugfixes

• Fixed the slope overlay (#54)
• Improved behaviour of input fields (#55)
  Basically all input fields were configured in a way that you had to press enter to assign the value. Confusingly, they did not actually assign the value when clicking away, but didn't discard the edits you made in the field either. So it was very hard to understand what was going on. Now all fields assign the value on pressing enter or when clicking elsewhere.
• Textures in the resource browser and the layer tab are not upside down anymore (#56, #62)
• Fixed multiline map description text breaking the scenario file (#67)
• Fixed issues with the linear brush option and rename it to Scale target to 0.5 to 1 range (#67)
• Fixed mipmap rendering (#71)
  When using textures of different resolutions in the Layers tab, they have to be all scaled to the same size internally because they are stored in an array texture. This scaling would lead to a recalculation of mipmaps, so the blurred mipmaps would not be visible anymore, leading to a different look than in the game. Mipmaps are now preserved properly.

Other

• Slider values are no longer clamped. You can now input any value in the text box above a slider. (#47)
• Default maximum of texture scale sliders is now 20 to make the sliders feasible to use (#51)
• Order textures alphabetically before creating the texture buttons for the resource browser (contributed by sting) (#49)
• Removed normal map check (#57)
  The "Can't assign albedo as normal map" check when assigning texture channelssometimes produced false positives and blocked adding special textures for advanced shaders.
• Remove the two buttons that you could use to generate a random heightmap. (#60)
  The used Neroxis version was way outdated and we don't allow uploading maps based on the map generator to the FAF map vault anyway.
• Improved version check behavior (#70)
• Terrain now retains more details when zoomed out, making it more consistent with the in-game view (#71)
• The editor should now pause rendering when it is in the background, reducing resource usage (#71)

You can download the editor here: https://github.com/FAForever/FAForeverMapEditor/releases/tag/v1.0
As there have been extensive changes, it is likely that some new bugs have surfaced. Please report them on the FAF forum or open an issue here in github.

With gratitude to all those who took the time to report issues with the release candidates, and a special thank you to kent-sole who showed me around in the Unity editor and answered my questions. Without him all this work would not have been possible.

Happy mapmaking!

BlackYps

@Nuggets said in Change the handling of Reports - When is a report valid?:

The ctrl-k rule is just one part of a bigger problem. Its the enforcement of rules in games where no participant asked them to be enforced. I'm not trying to say you should just exploit or whatever in your average teamgame. But what I am trying to say is that anything that happens (lets take my example) in a 1v1 game should not be held accountable to some rule where BOTH / ALL players in that game know about it AND are fine with it.

I think it has been well established now that if someone uses exploits in a streamed game, even if everybody in the game is fine with it, the done harm is the spread of exploit knowledge, because the game was literally streamed to an audience. I think everything about this scenario has been said already. Is there any other case where external reports happened that led to a ban?

Hi Zebranog, I am the one that did the recent changes.

why did the old versions of the editor stop working?

They should still work. What is your issue?

the new versions of the editor at first glance are worse than the old ones, what has changed?

I had to rework basically all of the map rendering to fix some long-standing issues where the map looked different in the editor compared to the game. It appears that in this process some things broke.

for some reason they changed the color, it became more difficult to see some small holes on the map, the division into squares is also now not precise, for some reason they removed where the conditional mex is one square

I don't understand what this means.

the function where you check a box and get additional layers for texture has disappeared

Yes, that is part of the rework. There will be a release of the 1.0 version of the map editor in a few days. That will also feature a more extensive changelog and will fix the bug with the colors of the slope overlay.

(and a bunch of other little things that I'm too lazy to write )

Please don't be too lazy to report bugs. If nobody reports them, then they will stay forever.
I recommend that you wait some days for the release, try it out, and then report any bugs that have not been fixed already.

@IndexLibrorum said in Change the handling of Reports - When is a report valid?:

You describe the exact approach we currently use to cover non-participant reports. Because we cannot cover each hypothetical, we've consistently phrased it as "we do not generally accept reports from people not participating in the game". Even with this type of phrasing we already frequently get attempts at rule-lawyering (for this and similar rules), where people argue that "well, it's not exactly against the rules as written, so you can't ban me", which is why we have to resort to these more general phrasings. But the situation you describe is the exact protocol we now adhere to.

I feel that it would make sense to spell out the reasoning of rules more explicitly in the rule page. Currently we have the rules that explain what is allowed or forbidden and we have moderators stepping around specific questions by saying "we don't generally do X", but if we leave the discourse at that it keeps being frustrating for both sides. As a player you don't get a clearcut answer, only vague statements that don't help you to gauge when you risk a ban. As a moderator you don't want to be too broad with your statements because some smartass will abuse the statement and find behaviour that should be punished but that would be against the wording of the moderator.

If we instead spell out the reasonings and goals in the rule page, then it becomes clearer for everyone. We could add statements like "A report from a person not in the game will only be considered if it explains how the behaviour in the game is harmful for the community at large. Otherwise it will be discarded." This would also make it clearer what reasoning the mod team uses to interpret the rules.

@Nuggets said in Change the handling of Reports - When is a report valid?:

The fact that something is bannable in games where "no one asked" (as in: a closed community (like my example earlier), a 1v1 between 2 players and so on) is just crazy to me.

I think it's important to distinguish games that were streamed and games that were really private. I can get behind the idea of not wanting to have the knowledge spread how exploits work in detail. And on top of that, people will inevitably imitate what they see streamers do, especially if it's unusual stuff. They might not know that it is an exploit, do it in a game, get banned and then be pissed, because they perceive it was ok when the streamer did it.
So when the game is streamed it's really not a "no one asked" situation, because it has ripples into the wider community. The easy way out is to just not stream games where you want to do dumb shit that is against the rules.

I do agree though that it doesn't feel like a good situation that the current rules are that every game is considered public because a replay file exists. The answer that practically there is a really, really low chance of getting reported by someone not involved in the game, is not really satisfying in my opinion. Personally, I would say that games that were not streamed or remarkable in some other way (like being a tournament game) should not be reportable by external people. Or, better worded: there must be an identifiable harm, that the behaviour in this game did to the community (for example rating manipulation or spreading exploit knowledge in a stream), to make a report by an external person valid.