User Details
- User Since
- Aug 21 2021, 5:41 PM (139 w, 2 d)
Fri, Apr 19
Mon, Apr 8
Sun, Apr 7
Guess some of those let could be const instead.
Sun, Mar 31
Sat, Mar 30
Wed, Mar 27
Mar 20 2024
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 ...
Mar 19 2024
Mar 18 2024
Mar 17 2024
Quick review
Mar 14 2024
Mar 9 2024
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.
Mar 6 2024
*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?
Feb 25 2024
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.
Feb 23 2024
@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.
Feb 22 2024
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
Feb 19 2024
Feb 18 2024
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.
Feb 17 2024
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.
Feb 16 2024
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
Feb 11 2024
Feb 10 2024
Feb 9 2024
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.
Jan 20 2024
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 ;)
Jan 12 2024
make the textures less blurry
Jan 6 2024
Dec 31 2023
Dec 29 2023
Dec 10 2023
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?
Dec 4 2023
Should be var -> let, const
Nov 22 2023
Nov 16 2023
Nov 15 2023
Seems not easy to describe that function, no wonder the original comment was lousy ...
Nov 14 2023
Nov 7 2023
I generally like it and agree with you.
Oct 28 2023
Oct 26 2023
Oct 24 2023
Oct 22 2023
Guess the question was what you think of bundling all "globals" under a single one (CApplication).
Oct 15 2023
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?
Oct 11 2023
Oct 9 2023
Oct 8 2023
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 ...
Oct 7 2023
Oct 6 2023
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.
Sep 28 2023
Sep 27 2023
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.
Sep 18 2023
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.
Sep 12 2023
Aug 27 2023
Instead of changing bounding box I'd say just use the appropriate style which looks to be "ModernLeftTopLabelText"
Aug 22 2023
Can't upload the video of the flickering grass here, so attached it to the forum post in the description.
Aug 21 2023
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.
Aug 20 2023
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.
Aug 8 2023
Aug 5 2023
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.
Aug 3 2023
Thanks for the patch, glad someone who can reproduce the issues picking this up.
Jul 17 2023
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.
Jul 16 2023
Jul 11 2023
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.