hyperion

Beware the latest release isn't master, the latest commit to master looks like the fix for this issue.

That explains it, thanks. I'm patient, no worry.

To my knowledge it's gpl compatible with optional non-free components that require comping yourself if you want support for them. Horse head and mane doing different things, or capes going rampant. Haven't noticed this in-game yet. There are quite a few things I'm willing to do after the switch to git or any vcs respecting authorship

Depends on what you call video support Currently there is exactly one user able to create videos, namely Stan, so this fails my definition of video recording support. While not critical I guess there would be users of this feature. Don't know about vlc but a very simple sdl video player using ffmpeg is probably no more than 200 lines of code and a well featured one is available under lgpl 2.1 at https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffplay.c I use the actor viewer as preview, so I currently need it. And I guess artist creating actors have use for it as well. Anyway the cost of "creating" it seems negligible to me. That reminds me that animations seem to be buggy in actor viewer.

I build against 3.2 and it works well. Yes, see Ideas: A feature that went missing over time is video, camera path is still there but it seems useless this days, would be nice if that could be added back again. A minor fix could be make the window icon available for non windows, throws a warning at startup every launch. An actor preview instead of an actor path only in the sidebar Edit: The window icon issue is actor editor only

Rams, balistae, elses, are already decently large units for game play so I'd decrease them all by another factor of 2 or so in size. Anyway reworking ships is much appreciated.

This one for nodjs Well, some 15 years ago javascript was slow as hell ... So no surprise we have different choices this days. As the simulation under current constraints needs to be single threaded javascript is an option. Again, I can only make an educated guess and you will have to consult specialist in this field but I think it might be well worth it.

Obviously something went wrong as https://gitlab.com/0ad/0ad-community-mod-a26/-/blob/main/community-mod/mod.json still says 0.26.2 <- @Stan` Anyway the list of commits you can see here https://gitlab.com/0ad/0ad-community-mod-a26/-/commits/main

Many messages probably originate in javascript and are consumed in javascript and so wouldn't have to leave javascript space at all. Maybe moving the dispatcher to javascript might be an option if expensive components can't be moved to c++. Just a guess but the cost of communication between c++ and javascript might outweigh the extra cost of using javascript. Maybe something like nodjs event emitter and libuv could be used as inspiration. This thread is a bit of a headache, first it looks like "let's sprinkle mutex in case we need it some day". Then it shifts to headless, which at it's easiest could be a null render backend and a driver (possibly some tcp socket protocol) and has nothing to do with threading per se. Then I see some hint of a server client setup where you don't send commands but state transitions or error corrections, which would possibly allow for much more aggressive parallelization. I'm lost at that point.

Plenty good enough to show the approach, thanks. Does the scaling at load time and I guess @vladislavbelov favorite is the randomized scaling to ensure there are no two same models. Reading between the lines I guess @vladislavbelov would want the scaling be done on the gpu tho. A good point brought up is how scale inheritance should be figured out as well.

There is zero additional overhead compared to using blender to scale the model, only less sources in the repo. Given the use cases in this thread there is no need to use the same model at different scale at the same time, but I see your concern that when you don't have to go through a lot of pain to scale a model "some random artist" will find it a good idea to have the same model be used at dozen scales at the same time.

So adding scale means we could deduplicate some assets? Well, you can generate different pmd/psa per scale, that's what I meant with build time / static scaling. Whether this is the most suitable way to go about it is another question. Not accessible

Not sure but I think opengl 2.1 is now a requirement, so hardware older than ~2005 won't do anymore but maybe it's just the drivers which are to old or incomplete.

There is no scaling via actor xml as of yet, right? As for the feature, I guess he wants to scale per entity (main actor and props alike), how to do it is up for debate. The main use of such a feature I see that one could model with a realistic scale or for example shrink the current ships for testing.

Guess adding scale wouldn't add any runtime cost as the models get converted to psa/pmd during build. Can't find a ticket on trac for it, so if you have use for this feature I suggest to open a bug.

Maybe "Player Placement": "AI: Petra Bot (hard, aggressive, ...)" would make more sense?

Scenarios are poor man campaigns from long ago, now that we have campaigns support they should be converted or deleted.

Well, as before, only Windows 7 and later are supported and they all have the same defaults for where to place app data.

Hand drawn icons are miles ahead of renders in terms of aesthetics.

All supported Windows versions have the same paths, at least by default.

The only way to get 64-bit support fast is to replace the 32-bit version, even that is probably more than a day of work, but more or less straight forward. What I did is cross compile 0ad which is somewhat troublesome, my changes are from replacing buildsystem, fixing deps or even replace them, fixing cross compile bugs and more. Reviewing means accept the changes and committing them. The developer on which shoulder this would likely fall is busy adding Vulkan support and still has font rendering on his plate which are in my opinion much more important. Also I prefer to wait for the git migration which is in the works. The takeaway from my work is that there is little in the way of a straight replacement, all else is somewhat cumbersome.

2000, xp, vista are all older than 7, so it's just Windows

Erm, Windows 7 SP something is the minimum requirement.

It doesn't work exactly well with random maps, also for me those pics only serve the purpose of looking good and to immediately recognize the map. Maybe some people are indeed interested in more info, but then a sample minimap render might be more useful and can be optionally viewable with some trigger.

Apparently the rational is in http://www.wildfiregames.com/forum/index.php?showtopic=1125 but it's private (gotta love proper documentation).