vladislavbelov

The most interesting thing is that scaling is already done on the GPU side (as we use a complete transform matrix) So we need to calculate that matrix properly on the CPU side to account a possible scale. Exactly. The problem is that we only have "that kind of active artists". There is no art reviewer who'd say how art should be done properly in terms of performance. And I don't have time to finish my "Techinical Art Guidelines". Spoiler to it:

No, we don't have any kind of scaling yet.

It's not a good approach for GPU, as it means more data to store and process in comparison with what we have now.

It's reasonable to translate resource names in that messages. I don't know why it's not translated. But Silier sent a link to a related file which is a good point to start, shouldn't be hard to figure out.

I think I wasn't clear. In the first sentence I was talking about scaling a model on a way to converting from 3D model through DAE to PMD (our binary format to store a model/mesh). It's true and that's why we don't have scaling on the mentioned step. It's simpler to have a link on wiki how to do that step for different editors than implementing and supporting that step in our engine. My second sentence was about runtime scale. When you already have a single PMD of a tree and you want to place it on a random map with different sizes.

I think that kind of feature should be on the side of a 3D modeling software, because it might be more flexible there. That seems the most reasonable usage for that kind of scale.

Hi! It's a known problem. It needs a horizontal scroll support inside our engine. We don't have it yet. If the window has a height less than 768 then it's the expected behaviour. Because currently 768 is the minimal supported height.

Did it change the behaviour? Also you could open profiler (F11) to see amount of uploaded textures memory when the bug appears.

Do the user has system_info/userreport from A25? The user could add the following lines to the user.cfg: forceglversion = "true" forceglprofile = "compatibility" forceglmajorversion = "2" forceglminorversion = "1" If it doesn't work might try lower versions: forceglversion = "true" forceglprofile = "compatibility" forceglmajorversion = "2" forceglminorversion = "0" And: forceglversion = "true" forceglprofile = "compatibility" forceglmajorversion = "1" forceglminorversion = "5" We're still able to run OpenGL before 2.1 by using ARB shaders (if it has appropriate extensions), but it's deprecated in A26.

Wasn't the suggestion about the runtime scaling when you can override the scale by editing an actor XML?

Have you tried the texture quality option to low?

HI! IIRC there was some work about adding aarch to A26, but don't know its status. Maybe @Stan` has more information.

HI! According to https://repology.org/project/0ad/versions it seems Debian bookworm was already updated, but previous not. Not sure about plans for that, maybe @Stan` can help. Regarding older builds, you can find mostly all previous builds (including Linux, macOS and Windows) here: https://releases.wildfiregames.com/

Hi! Thanks for the report! My first thought is an out of video memory (because of new art). But not sure. Could you enable debug checks via adding the following lines to your user.cfg and reproduce the bug? renderer.backend.debugcontext = "true" renderer.backend.debugmessages = "true" renderer.backend.debuglabels = "true" renderer.backend.debugscopedlabels = "true" Also could try to decrease the textures quality in options to low?

What does happen to your minimap? Does it happen in the game without mods?

You're right, it should be false.

The issue should be fixed in https://code.wildfiregames.com/D4820.

I don't remember that feature.

Hi! Does your workaround fixes the right edge problem? Currently it sounds more like a SDL issue (the open-source library we use to interact with an OS), so it means it's harder to fix by ourselves. But you also can try disable borderless fullscreen by adding borderless.fullscreen = false to your config file. Could you also share your userreport.txt from the logs folder?

Make sure than the downloaded file has a correct hash sum/minisig. You might find them here: https://releases.wildfiregames.com/ Also check this thread:

It might make sense to clean them up but not manually. I think a possible solution is to create a pre-commit hook to filter/disallow such information.

https://trac.wildfiregames.com/ticket/1889 Adding another way to open an external resource is another possible security violation. So it should be considered carefully. Also it requires a not easy modification of the gui engine.

Hi! It's not intended, but some export tools doesn't have an option to avoid such includes or people don't know how to use it.

Could you upload crashlog and crashdump? Also do you have mainlog from that run?

It's not the bug, search is a resource consuming operation. Reducing the delay to 1 second for all doesn't sound good. In theory we could reduce to 1 second (or 2 seconds) only for registered users without posting limits. @implodedok