vladislavbelov

I meant functionality (that process these strings), sorry. By hand checking we may loose many corner cases. We don't want to run it for each commit, only for translation updates. So the performance difference is incomparable with the code problems:

For full check. I.e. script doesn't guarantee existed symbols, you need to rewrite script for each change in the engine, it will test only small subset of functions. And as I said it's a bigger work to write a validate script with right logic than the page generator script.

I think it requires more work (need to write JS to call C++) and has less checks, because no rendering there.

There is a little hack, we can just run a special generated page, that contains all translated text. It guarantees that all texts will be tested with the real engine.

I agree to use POT textures, until we have a better solution.

OpenGL supports such textures since 2.0: https://www.khronos.org/opengl/wiki/NPOT_Texture. I think we need to have NPOT textures for UI, but then pack them into POT atlas. It should be faster and work better. It'd be good to implement after the GUI refactoring.

As I mentioned problem is not in the texture resolution, but in number of mipmaps. Also we have not only .png textures.

Ok, I'll try to reproduce it tomorrow for Ubuntu 16.04.

Could post your OS version, the game version and steps to reproduce the issue?

Does the modio installation work for you? Does the game print something in the console?

I wrote it and it shouldn't call the archive builder (there's a chance, that VFS has a strange behaviour, but it's small), it works with a temporary folder.

Understood. It's the distortion: https://en.wikipedia.org/wiki/Perspective_projection_distortion. It can be fixed/corrected with special projection matrices (it may looks like a panorama with it) or postprocessing corrections.

It shouldn't differ from the manual installation AFAIK. Because the mod installer extracts only the mod.json and copies the whole zip file.

Hi @thekolian1996. The problem is in the translation string, it contains "[" and "]". They are special characters and should be escaped with the slash "\" one. The solution is the translation fixing: https://www.transifex.com/wildfire-games/0ad/language/uk/. I think we need to ping translators and add a check in the translation script. @elexis?

There is a little difference: .pyromod has an additional behaivour. It's associated with the game, zip - not. Only drag&drop works for the zip. And it's not allowed to put .pyromod inside mod folders yet (but it'd be good to have such possibility). So .pyromod is not equal to .zip.

Yes, it copies the mod in the right place.

For pyromod you don't need to know paths, just drag&drop a pyromod file on the game icon or double click on the pyromod file.

The reason is the static element layout:

Yes, @elexis already mentioned this problem, I'm working on it. Look at handleInputAfterGui function in input.js and updateCinemaPath function in session.js.

I think the reason why we need it - increasing realism of the game picture. We don't add effects for effects. If you want to make it very noticeable, you can add it for any graphic benchmark. Currently penumbra effect is too blurry in comparison with real life IMO.

Yes, you can How long is it loading for you? The brush seems not hard to implement. Let's see after the FF.

Why? I'm working mostly on Atlas, Graphics, GUI and Renderer components. It's not so much I think Also my CS works are about a procedurally generated content and big landscape rendering.

Probably it should go together with the "Weather" option. Yeah, obstacles should be far away to have such blurry shadows. Or a pretty cloudy weather. We have @wraitii and Phillip. I'm not active currently in the renderer (I hope I will), but I review patches for it. So all graphic improvements are welcome

It's the common problem for GUI, because we don't have dynamic layout yet (without JS). But I hope, we'll have some basic things for A24.

Ok, let's see inplace. I agree to avoid such things. As I said, structs are mostly used as PODs, but it has different usings, that allow you to write less code and less make errors. Constructors and methods calls Sometimes you need to pass many params to constructors or methods, and pass them directly may lead to errors and a unreadable code. Without struct: class TextureManager { public: TextureManager(size_t cacheSize, bool preallocatedCache, bool generateMipmaps, ...); }; // It's pretty easy to forget and swap bools here. // And the call is pretty big. You need to add comment to everyone, // but it will break after an order change in the constructor without // compilation errors. ... = std::make_shared<TextureManager>(10 * MiB, true, false, ...); With struct: class TextureManager { public: struct InitParams { size_t cacheSize; bool preallocatedCache; bool generateMipmaps; ... }; TextureManager(const InitParams&); }; // It's easy to catch missed params. TextureManager::InitParams params; params.cacheSize = 10 * MiB; params.preallocatedCache = true; params.generateMipmaps = false; ... ... = std::make_shared<TextureManager>(params); And much bigger production example: https://cs.chromium.org/chromium/src/ui/views/widget/widget.h?sq=package:chromium&l=149. Function results and grouped members Sometimes function should return more than value, popular way is add ref/pointer params (it's pretty fast, but more symbols and the same problem with number of params). But with struct it can be solved shorter. I.e. std::pair is struct. Without structs you need to write a getter for each property, and sometimes these properties don't need to be access and store separately. Example: our Material class. With struct it allows to use only one std::vector to contain params. And there is no needs to use classes, because the data is pretty simple.