hyperion

First of all, thanks for working on this. I guess there will be a noticeable difference in playability for people with weaker hardware. One thing I noticed in the video is you exclude projectiles from this "disappear early" treatment. Projectiles should have a similar impact due to the large number and are less noticeable than corpses. So have less visual impact if they disappear. As for the main question, I'd go with on/off. While this random (intermediate) disappearance is indeed quite odd looking that isn't the only reason. Just playing the death animation without a decaying corpse has the advantage of removing most of the gorge and I suspect there are people who would choose this option for this reason instead of performance. At least you can advertise it as such. There could also be sort of a best of both, ie. the corpses only enter the FIFO after the death animation was played fully. PS: the link asks me to login to phab.

https://trac.wildfiregames.com/wiki/BuildAndDeploymentEnvironment#Futuredesign There is git lfs and when switching to git you rewrite history anyway, so stripping all build artefacts can be done right then. The reminder is hardly an issue for git. But yeah it's some work but long term I see only benefits.

I play since a13, back then to my liking only two major features were missing to make it a complete game, one is the hotkey editor, the other campaign mode. Important is that they are available. Just like hotkey editor needs more love I don't doubt the same will be the case for campaigns. Actually what happened to the git migration that was decided upon many years ago?

Well, how is the name of a24 related to a24? For a23 it's even obvious how it's not related. As for a25 nothing will trump campaign mode.

Not sure this needs fixing, a reasonably known but hardly used easteregg.

There is no point in waiting for months, ideally commit r24939 would have already contained the new name. Then you should have a poll for a26 instead

I have no strong opinion on whether Roman camp should produce sieges or not, all I'm saying is only game play should matter in such a decision on not history/realism. As for the free houses, it's a shame, this is a real unique trait gone with no replacement in sight.

Maybe you are in the same team with the AI, then you obviously win on start.

Yes I agree that the most logical place to produce sieges would be the Roman army camp which is placed in enemy territory. But that one can't produce them any longer either.

The video is rather funny but I guess this is a bug rather than a feature. I'm referring to garrisoning and un-garrisoning on the other side, if you chain a couple buildings you can transport your troops at incredible speed across the map.

So lets take the changes to fortress then. They weren't just garrisoned when the enemy was already at the walls. So they obviously provided living space, as such dropping pop bonus is historically wrong. They were places were soldiers trained by virtue of being garrisoned long term as such removing unit production is wrong. Having a forge / workshop within the walls was probably common as such removing sieges and tech research seems historically wrong. The argument of historically accurate I see used when doing one thing and when doing the opposite alike. Game mechanics really should be about game mechanics only. Well, I appreciate this historically accurate when it comes to unit/structure visual design, naming, voice acting and in future for campaign background.

Walls, free houses, etc are major differences in civs while unique techs are at best minor differences. I'm also in the camp of major differences are preferable over minor ones. As for justification, what else other than it's more fun is needed. The argument of realism/make sense is crappy in my book as the game is to far from realism to begin with due to it's very nature. Vision range, building a city where only a couple hundred meters of surroundings are known, shooting through obstacles and many more come to mind. We even have sci-fi elements like teleportation, so really anything can be done as long as it's fun to play.

Zero day bump request are discouraged as it may causes unnecessary work for triage and maintainers. If your distro still doesn't have it updated by now filing a bump request is fair game. Make sure there isn't a bug filed already. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983408

So how are you gonna render it in blender? Adding such an album to the shader doesn't scale. There are hundreds of materials used.

Ageing is an over-definition/redundant, can be expressed by changing albedo, is metal, roughness, etc.

There is no difference in that both can be used to depict materials realistically, but the difference in implementation and ability is obviously more than just semantics. I wouldn't start assigning random interpretations to channels but stand on the shoulders of giants like Disney, Adobe, etc. Do like the others do. https://www.khronos.org/blog/art-pipeline-for-gltf Describes a set of textures and assignment of channels under "texture requirements" The set is obviously sufficient to depict realistic stone as can be seen in https://www.turbosquid.com/Search/Index.cfm?file_type=1022&keyword=stone&media_typeid=2

Ah, but that's not "transparency"; it's "translucency". But I get what you mean. If I grab a piece of tinted glass in front of my face and DON'T change the angle, I get constant transparency rate, and therefore something similar to Alpha. But in any case, what I meant is that Alpha is useless in 3D graphics unless you want to model a teleporter. Khronos calls it transmission, https://github.com/KhronosGroup/glTF/blob/master/extensions/2.0/Khronos/KHR_materials_transmission/README.md

Still get the same error.

ERROR: Failed to compile shader 'shaders/glsl/model_common.vs': 0:138(2): error: `v_half' undeclared 0:138(21): error: `sunVec' undeclared 0:138(21): error: operands to arithmetic operators must be numeric 0:138(11): error: no matching function for call to `normalize(error)'; candidates are: 0:138(11): error: float normalize(float) 0:138(11): error: vec2 normalize(vec2) 0:138(11): error: vec3 normalize(vec3) 0:138(11): error: vec4 normalize(vec4)

How? It's static. To me all of that is necessary to describe a material; I don't see where there is a "choice" to make. quick google: https://forums.unrealengine.com/development-discussion/rendering/14157-why-did-u4-use-roughness-metallic-vs-specular-glossiness basically what can be taken from there metal/roughness model: taken from Disney more intuitve saves two channels doesn't permit physically impossible materials

Just had a quick look at the patch uploaded to phab. If you want ao to always range from 0-1 as mentioned in TODO 1 for any given map you might want to provide a script around imagemagick so you and other users can convert their assets to test this case as well. No need for the shader to take care of it. ERROR: Failed to link program 'shaders/glsl/model_common.vs'+'shaders/glsl/model_common.fs': error: fragment shader varying v_half not written by vertex shader

Lots of text, so I will only pick a few points out. AO baking is also a hack, an even older one at that. There is a reason why ssao was developed and why there is even hardware support for it. I agree this is orthogonal to a new shader/stack project and can be tackled later by someone if they feel like it without interfering here. So leaving it out for now seems reasonable. If you hold a leaf towards the sun some light leaks trough, so "transparency" isn't just about glass. Whether to use alpha channel or something else is another question. --- So I did a bit of research, there are basically two workflows for pbr. So the first thing to do is to figure which to pick for 0ad. One is specular/gloss, the other metal/roughness. The latter seems to dominate and the former is sort of considered old school. Converting between them is reasonably possible and 3d software sellers seem to support both. I favour metal/roughness for the simple reason that it seems more common in industry and more intuitive for non physicists. I have no strong opinion but this is something that should be discussed with core developers first before jumping into implementing the shader / specifying the stack. Next is what channels/information is needed. AO map seems gone in your list. A player_colour bit. If I'm not mistaken alpha is currently used for this. You mention glass I mentioned a leaf, there are fantasy mods and you talked about a space mod. So the specification for the stack should handle this sort of materials, whether to implement them now, later or never is not that relevant. Materials that emit light, lava for instance or fluorescent paint/engine on a spaceship. Clear coating? Others? Encoding/bit-depth: If there is an industry standard for which channels get packaged together and their order as well as their depth this should be picked. Requires some research but will certainly help with tooling / interoperability. UV: Probably should only ever support 1

Supposedly they are player_colour, maybe shouldn't be touched.

Replacing rivers with streets makes this sort of a different map. More like yet another variation of mainland. The farmland in front of red seems to be a mound. Usually the darker colours are at the lower parts signifying wet while the higher parts already dried after some rain. I really like the trees in all your screenshots.

First of all I'm not part of the project and don't represent it so you can just ignore me all together if you want. Secondly if you already know that you fixed the issue that I might have encountered no need to get upset as you obviously agree with me that there were and still might be pending issues. I have other things to do so reaction time is bound to be slow, if you want me to always use your latest changes clone the git repo and push a branch to github or wherever so I can add your repo as a remote. Then there is no need to copy unversioned files from different threads witch might or might not be part of the same effort around and no need to notify me that there are changes in the first place. Also with proper commit messages I already know what got changed since the last test and I can reference a commit hash when I comment. All I can say is the direction is worthwhile however the version I looked at clearly isn't there yet. That there is a need to touch assets is obviously just a guess, I'm happy if you prove me wrong, but if you have to touch them it's a lot of work. With a new stack right after this all might be in vain. This is also not just about vanilla but also all assets in mods, so even if you fix everything in vanilla others still have to fix the rest. Collaboration is always more about communication than coding, if you are completely averse to this you better stop earlier than later. This has nothing to do with brown nosing, bashing or the like but is just the nature of it. As for a new stack, me thinks it's a good thing. If undertaken don't expect it to land within days. Planing, discussion, implementation and finally reviewing will take a lot of time. This is far from a one-liner after all and involves the interests of many. Perfectionism is a prime source of stress. Nothing will ever be perfect. Anyway take care of your health, that's most important.