In D5256#223673, @Vantha wrote:

When the AINames are empty or don't exist, the game already throws errors before the step of choosing the names.

Guess some of those let could be const instead.

However clients have no idea which user issued which command which might be ok-ish or not, you don't need it for basic gameplay but per user stats are of reach for instance.

Thinking a bit more about player spoofing, it probably is a bad idea in the first place and extending the command protocol to have both a "user" and "player" id would probably make implementing co-op play a lot cleaner. Sure it's not the intended scope of this patch ...

Quick review

In D5222#223496, @phosit wrote:

In D5222#223495, @sera wrote:

In D5222#223494, @phosit wrote:

IMO The behavior of the server shouldn't dependent on the simulation's init-atributes. Instead the controller should explicitly control the server.

allowCheats is an init-attribute, at least that's my take.

Is that also the case if we call it allowPlayerSpoofing?

In D5222#223494, @phosit wrote:

IMO The behavior of the server shouldn't dependent on the simulation's init-atributes. Instead the controller should explicitly control the server.

That all maps must be migrated more or less immediately to use the new way is a given and doesn't depend on whether to leave a compatibility layer behind.

In D5220#223420, @phosit wrote:

In D5220#223418, @sera wrote:

So what is the plan?

My plan is to

1. Learn rmgen
2. Document the flaws
3. Come up with a solution
4. Convince other devs

xD

In D5220#223417, @phosit wrote:

In D5220#223414, @sera wrote:

Also now that you drive generation from cpp why the need to call export map from js?

You mean calling g_Map.MakeExportable() from C++?
That's a good idea. Do you have a better name for MakeExportable? "finalize" or something...

*shrug, also would be more obvious an improvement if the old way is removed.

Checking the code in pyrogenesis the global object is indeed available under the name "global" in js running in pyrogenesis, my bad, I got tricked to believe you added a property global to the global object :)

Also now that you drive generation from cpp why the need to call export map from js?

global is as good a name as rootedvalue or habakuk.

why not Engine.map?

Ok, now that we have established that for sufficiently small deviation in radius this approach is acceptable let's continue getting the patch into shape.

In D5247#223303, @Feldfeld wrote:

Depending on how it's done it could have an impact for competitive gameplay.

@Baelish , not sure I follow you. To find a solution one must exist, the code you touch doesn't guarantee such at all. What the ticket suggest is to make the radius variable to some extent to increase the probability such a solution exist in the first place. Ofc there is a tradeoff that now possible minor imbalance is introduced, like one players chickens are on average one tile further away than the other players or the like. The change from random angle to iterative angle in practice should be less impactful.

Thanks for the rational, tho the idea was to update the summary at the top of this web page. The summary is what the commit message should be based on.

I did not remove old parts, so i took them as comments

In D5246#223204, @marder wrote:

at least from a simple test (just object creation and setting a value) the performance looks equal. Not sure what happens in complex scenarios tho.

I suggest to add a shaders not found error message and maybe give a hint as for the possible cause and solution, otherwise LGTM apart from the obvious linter warning.

In D5242#223125, @vladislavbelov wrote:

In D5242#223121, @sera wrote:

About atlas, wx itself uses gl but that doesn't mean you can't use vulkan for the viewport, anyway mostly a non issue and certainly low prio.

Vulkan can't access the viewport without interacting with wx.

If selecting vulkan can break the game then it shouldn't be exposed in the gui in the first place, even less be recommended. At least as long as reinstalling can't fix the issue. So before a release this needs to be addressed anyway.

Vulkan being _highly recommended_ but not the default is a contradiction, the note about drivers could be read as don't try unless you are sure it works because you will lock yourself out if not. Graceful degradation from vulkan to gl if something goes wrong is a must have.

In D5242#223095, @Stan wrote:

Which is really a pain

Well, I'd say gl is supposed to be labeled legacy. So I'd use stronger language and move vulkan to the top of the list and make it default in default.cfg

In D5240#222967, @Stan wrote:

How about using ProjectionType from source/graphics
/Camera.h ?

In D5240#222955, @Boston_Brooks wrote:

where there should be references to perspective/orthogonal.

Haven't tested so just some comments based on a quick review. First is you are switching between perspective and orthographic projection, not between 2D and 3D (ie if in orthographic mode you can still 3D navigate the viewport, right?), so names should reflect that. Secondly, if you want to log output use the logger infrastructure provided by pyrogenesis, tho I guess the printf are just for the sake of development and therefore should be removed.

we could adopt the upstream fix instead found at https://github.com/premake/premake-core/pull/2117, but this one looks ok as well.

Binary patches are a real pain to test so I skip doing that, always ;)

make the textures less blurry

wrt deepfreeze

In D5218#221736, @vladislavbelov wrote:

In D5218#221718, @sera wrote:

ERROR: Failed to compile shader 'shaders/glsl/compute_downscale.cs':
0:27(31): error: no function with name 'texture2D'
0:27(2): error: no matching function for call to `imageStore(image2D, ivec2, error)'; candidates are:

Should be fixed with the last update. To reproduce (I wasn't able locally) you need to choose OpenGL backend (restart after that), enable post processing, set scale to 200%.

But might have been using opengl, maybe related to enabling postprocessing or some part thereof.

ERROR: Failed to compile shader 'shaders/glsl/compute_downscale.cs':
0:27(31): error: no function with name 'texture2D'
0:27(2): error: no matching function for call to `imageStore(image2D, ivec2, error)'; candidates are:
0:27(2): error:    void imageStore(image1D, int, vec4)
0:27(2): error:    void imageStore(image2D, ivec2, vec4)
0:27(2): error:    void imageStore(image3D, ivec3, vec4)
0:27(2): error:    void imageStore(image2DRect, ivec2, vec4)
0:27(2): error:    void imageStore(imageCube, ivec3, vec4)
0:27(2): error:    void imageStore(imageBuffer, int, vec4)
0:27(2): error:    void imageStore(image1DArray, ivec2, vec4)
0:27(2): error:    void imageStore(image2DArray, ivec3, vec4)
0:27(2): error:    void imageStore(imageCubeArray, ivec3, vec4)
0:27(2): error:    void imageStore(image2DMS, ivec2, int, vec4)
0:27(2): error:    void imageStore(image2DMSArray, ivec3, int, vec4)
0:27(2): error:    void imageStore(iimage1D, int, ivec4)
0:27(2): error:    void imageStore(iimage2D, ivec2, ivec4)
0:27(2): error:    void imageStore(iimage3D, ivec3, ivec4)
0:27(2): error:    void imageStore(iimage2DRect, ivec2, ivec4)
0:27(2): error:    void imageStore(iimageCube, ivec3, ivec4)
0:27(2): error:    void imageStore(iimageBuffer, int, ivec4)
0:27(2): error:    void imageStore(iimage1DArray, ivec2, ivec4)
0:27(2): error:    void imageStore(iimage2DArray, ivec3, ivec4)
0:27(2): error:    void imageStore(iimageCubeArray, ivec3, ivec4)
0:27(2): error:    void imageStore(iimage2DMS, ivec2, int, ivec4)
0:27(2): error:    void imageStore(iimage2DMSArray, ivec3, int, ivec4)
0:27(2): error:    void imageStore(uimage1D, int, uvec4)
0:27(2): error:    void imageStore(uimage2D, ivec2, uvec4)
0:27(2): error:    void imageStore(uimage3D, ivec3, uvec4)
0:27(2): error:    void imageStore(uimage2DRect, ivec2, uvec4)
0:27(2): error:    void imageStore(uimageCube, ivec3, uvec4)
0:27(2): error:    void imageStore(uimageBuffer, int, uvec4)
0:27(2): error:    void imageStore(uimage1DArray, ivec2, uvec4)
0:27(2): error:    void imageStore(uimage2DArray, ivec3, uvec4)
0:27(2): error:    void imageStore(uimageCubeArray, ivec3, uvec4)
0:27(2): error:    void imageStore(uimage2DMS, ivec2, int, uvec4)
0:27(2): error:    void imageStore(uimage2DMSArray, ivec3, int, uvec4)

After fiddling a while with this new feature and checking the console after I saw the above, but can't figure out how to reproduce it :)

LGTM if you fix the linter warnings.

How is it supposed to interact with gui.scale?

Should be var -> let, const

In D5189#220745, @phosit wrote:

In D5189#220712, @sera wrote:

Seems not easy to describe that function, no wonder the original comment was lousy ...

Propably I should describe it more vivid. Like "The predicate shall return wheiter to expand the wave around that tile." and "The first argument is where the wave came from".

Seems not easy to describe that function, no wonder the original comment was lousy ...

I generally like it and agree with you.

In D5167#219996, @phosit wrote:

The logger (file) should not know how it's tested. Code only used in tests should be in a test specivic file.

In D5167#219914, @phosit wrote:

In D5167#219802, @sera wrote:

Also might actually be nice to use an StdoutLogger [...] using the same mechanism.

Yes but it's in conflict with the guideline of using initialization over assignement.
Now g_Logger could be a std::reference_wrapper when we implement your idea that's not possible anymore.

In D5167#219874, @phosit wrote:

@sera I named it EngineLogger instead of DefaultLogger ;)

In D5167#219779, @phosit wrote:

In D5167#219748, @sera wrote:

About the patch I'd appreciate if there wasn't the asymmetry in default logger vs TestLogger and TestStdoutLogger, all should be handled the same.

What do you mean by that exactly: "One is declared inside the CLogger and the other in the global namespace", "One is placed inside the object the other on the heap" or "One uses the default constructor and the other provide a stream."? (I guess it's not the last one.)

Guess the question was what you think of bundling all "globals" under a single one (CApplication).

Remove 2 globals, well, the summary / commit message should state which. Also you seem to pass a parameter g_IsController, shouldn't the prefix be dropped now?

In D5154#219286, @phosit wrote:

Some libraries call such a class finally: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Re-finally

In D5154#219247, @phosit wrote:

I agree that something like:

Profiler2::LivetimeGuard guard;

is better

Instead of a generic OnScopeExit having classes like WinInit and EarlyInit would be cleaner me thinks. The comment in profilerShutdown "// Shut down profiler initialised by EarlyInit" is a hint that this design isn't that clean after all.

Indeed I got misled by the check for the builder component and checked while having a player id to confirm my suspicion ...

In D5151#219176, @phosit wrote:

In D5151#219170, @sera wrote:

A gaia unit that wasn't owned by a player won't show the builder panel.

No, Units who spawn as gaia also show the builder panel.

A gaia unit that wasn't owned by a player won't show the builder panel. Seems like a case of resigning not doing proper cleanup.

It makes sense that dependencies on disabled should be a thing, just wonder what the spec should be. I mean we might also need something like var>=5 or var!=testing_mode and many others further down the road. So it might make sense to think a bit more about the spec. !var could also be var=false for instance.

I'd say a map should try to preserve the feel across the different sizes. That isn't the same as blatantly scaling, in fact constructing counter examples isn't all that hard (eg, think of vertical range of ranged units). Also you already violate this supposed rule with your fix. I'd say a map author should go with the most sensible choice case by case.

Instead of changing bounding box I'd say just use the appropriate style which looks to be "ModernLeftTopLabelText"

Can't upload the video of the flickering grass here, so attached it to the forum post in the description.

Leaving crt be is certainly the right thing to do, this change also makes it easier to port pyrogenesis to compilers which don't support pragma comment linker. Haven't updated the mingw port in a while so can't test this handily but looks good to me.

In D5106#217020, @vladislavbelov wrote:

In D5106#217019, @sera wrote:

If the textures are bogus and need fixing in the future anyway I'd say this patch shouldn't be committed. Sure it doesn't look all that nice but it's not bad enough to have to cover up the issue and possibly avoid having it fixed properly.

Generally I agree. Currently we're discussing with @wowgetoffyourcellphone what we can do from the art side. The only problem I'm worrying about is that updating content might be a slow process and we won't have time before the next release.

If the textures are bogus and need fixing in the future anyway I'd say this patch shouldn't be committed. Sure it doesn't look all that nice but it's not bad enough to have to cover up the issue and possibly avoid having it fixed properly.

In D5094#216608, @Freagarach wrote:

Nice feature!
We may need to take into account that this leaks information to enemies.

If you are comfortable in patching out Werror then go ahead, otherwise the patch LGTM, tho can't test it as I don't have a mac.

Thanks for the patch, glad someone who can reproduce the issues picking this up.

You should also add multipliers for hack and crush so it does what the description says else if in future someone changes damage type or adds a new cav unit this likely will be missed and cause a bug.

Id vs ID, not sure what is the intended style but if you change it you might also have to change PlayerID and maybe others along it.

In D4646#215178, @phosit wrote:

Didn't thaught about that. There are multiple approaches. That should be discussed somewhere else.

In D4646#215161, @phosit wrote:

IMO game specivic command line args should be "parsed" in the mod.