hyperion

Acceleration I'd say should be an artist only property, make things looking and feeling good is the only legitimate purpose in my book.

The only sensible thing is to remove the diminishing returns for all civs, @maroder had such a plan, a hidden bonus to a hidden feature doesn't make sense at all. Just because a parameter exits doesn't mean it has to be tweaked. Increase gather rate for a civ if you want a farming bonus.

This is a typical road "texture", guess this would be plausible as well. The slabs to the left by the columns would also be a fine texture for the plaza and what I had in mind.

Guess dirt would be fine as well, just that this texture feels somehow wrong to me.

Instead of a "mod" repo a branch in a 0ad fork would probably be better for later merge. A script to create a mod from a branch is trivial to write.

No one would use Windows then. Sure functionality wise the UI isn't a master piece but I wouldn't call it broken. PS: A designer told me that the first 8 seconds are the most important. Leaving the start page in that time is close to impossible on first visit. Personally I also go for functionality, that why I stick to config files.

it's not about functionality but styling, the current UI fits the 90'

@wowgetoffyourcellphone me thinks perfectly square tiles are a better fit for Greek architecture, the issue with the original model was missing tiles (to make it more visually interesting, I have my gripes with that idea) and somewhat skewed symmetry. Anyway, me thinks they would have never used randomly sized slabs here.

Some random points: Start page has 4 different hover effects and there are more variants in other places red old style buttons need to go tooltip background transparency (only used sometimes) may lead to hard to read tooltips radio button are of the old theme, same for drop down arrow ai options icon color button borders come in variants some enabled buttons lack hover there is an issue when expanding the menu in-game full screen pages like match-setup shouldn't have inset window borders/decorations As for incomplete, well, the in-game game controls are untouched as of yet. While there are many small issues, overall I feel like the direction is right so I hope you won't give up on it as this is an aspect that I think is in dire need of some love.

I guess the issue is the UI, shiny is a major improvement, sadly it's inconsistent and incomplete as of yet. Edit: ply0ad.com also has outdated feel

And those that are viable are mostly the same for all civs ...

The in range depends also on height, changing that would make it cheaper and allow to use let's say l1-norm to filter possible targets first

Obviously all civs need catas if fortifications should have any decent role in this game, which IMHO they should.

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