vladislavbelov

Just for clarification: Alpha 27 isn't released yet, we have only release candidates Have you tried the ones mentioned in the first post? And which Apple platform do you have and which macOS version?

Because we use it for GUI where the Z axis is inverted (and never thought to use it somewhere else before refactorings).

m_Camera.SetOrthoProjection(m_ViewFar, m_ViewNear, 256.f); might also work. Yes, it's a start. Then we need: Add a separate camera controller to be able to configure the orthogonal mode properly Add an option in GUI Adjust zooming code with visible bounds to fit/to be similar to the perspective mode Choose camera position to have proper sounds on all zooms Check reflections and refractions Check shadows (w/ and w/o cover the whole map mode) Test regular and big screenshots and adjust their code if it doesn't work Think what do we need to do in Atlas (autoswitch to the perspective mode or something else) Test for z-fighting for all backends (OpenGL, OpenGL ARB, Vulcan)

They're errors. So it won't compile if versions are mismatched. But indeed different versions (especially major) might potentially cause OOS.

We have a ticket for that: https://trac.wildfiregames.com/ticket/3653. I believe it's doable, it just needs a pair of free C++ hands. It's not really a problem for our engine. We can automatically switch them for cutscenes. We have a separate method to set an ortho projection (a classic isometric view is a special case of an orthographic projection).

No, it's not intentional. It seems like consequences of trying to fix notifications or maybe space related problem. I hope trac will be back soon. And we'll definitely make a post in case of any major change to our services (like shutdown or address change).

Could you enable VSync or set FPS throttling in menus/in games to a value not more than 60 in graphics options?

Could you disable them to test? Do you remember how it started? (Maybe after system update or another installation) Could you post logs for that run with edited user.cfg?

Is it a system hourglass cursor or in-game one? Do you have any mod installed? Could you record a short video? Another way to possibly solve it is to change the type of the cursor. For that you need to add the following line cursorbackend = "system" to your user.cfg (you can find a path to it here: https://trac.wildfiregames.com/wiki/GameDataPaths)

It seems a bit less readable to me and it'll be inconsistent anyway as we can't use such approach everywhere. But I don't mind in that particular case.

Yeah, that'd be good. Unfortunately it's in a low priority right know. But! I wrote a script to do simple batch updates. So if you have Python 3 installed (or you're able to), you can use it (don't forget to backup your map files before running the script and resave the map from Atlas to format the file correctly after the changes by the script): python3 path/to/entities.py path/to/map.xml --pattern your/tree/name --list --rotate random entities.py You might run the script without the rotate argument just to test the list of matched entities.

IIRC we should log such cases, maybe it's in log files. The game uses normal and specular textures together, so we don't support separate materials anymore (that's the way to go PBR). But you always can set a default texture to norm or spec. I can recommend to avoid too sharp normal textures (when neighbor pixels have opposite values, in other words normals look in opposite directions). See also technical art requirements (made by me, converted to wiki format by Stan): https://trac.wildfiregames.com/wiki/TechnicalArtRequirements

Just in case make sure you're using OpenGL or Vulkan backend and Shader effects set at least to 3.

It seems different from the original post. Could you share a full log (with the Collada compilation error)?

Thank you!

Could you share your OS and compiler version? That shouldn't affect the compilation process, since it depends on a platform not CI infrastructure itself.

Could you also attach your warnings and errors?

That might indeed happen because of low amount of free memory. Could you also try to update your videocard drivers and switch to OpenGL ARB backend?

Which version of the game are you using? Post-processing stage might be too late for you do cel shading. Because ideally it requires normal and light information. So adjusting model and terrain shaders might give a better result (though it's more complex than post-processing). Also keep in mind that we now support Vulkan, it means GLSL shaders won't work there, they require precompilation (if you'd like to support Vulkan backend ping me).

It depends on a map size. I think the easiest way (without looking to the code) is to place 4 entities on an empty map with your size (their sum divided by 4 would be the center): Another way to get a coordinate of some point is to place a camera there and print its current position: Misc hacks > JS console > Enter warn(uneval(Engine.GetCameraPosition()));

In that case the error might happen because of stack overflow/out of memory. If you replace it by a loop (with the same number of steps like for the recursion) in theory it shouldn't fail.

Indeed, maybe we need a tool to cleanup such entities. Just high values aren't enough because maps are circular. So ideally you need to find coordinates of a map center and remove all entities which are further than a map radius (maybe with some bias). (0, 0) isn't a map center but the one of its corners.

Do you have steps to reproduce?

You're welcome Post the results

We have the same assertion when there're entities placed too close to a map border, particularly their shape intersects the border. Known bug: https://trac.wildfiregames.com/ticket/6486 Thank you, we'll use it for 6486 when there'll be a fix. Maybe when you deleted all entities some of them remained behind/close to a map border.