hyperion

Was done. But apparently it costs too much performance doing that see https://code.wildfiregames.com/D2936 An option to removing projectiles immediately and removing corpses as soon as the falling to ground animation is played is sufficient. Some people are even willing to disable shadows which is far worse from my point of view. This is fine as a brute force method, perfectly fine to ignore the I want to see exactly 362 corpses and no more crowd. Though removing the thousands of pebbles no one sees in large scale slinger battles might make sense for everyone. Too many users would not be able to play the game anymore... It might or might not be early for requiring vulkan. However it would anyway take a year or two before 0ad would have migrated even if you started right now. If someone was willing to take up this task I'd suggest you welcome it whether ifdefed, runtime switchable or straight transition. This is a game about ancient warfare and not ancient hardware. Also there is quite a bit of work that can be done towards vulkan while still using opengl. Unit pushing (D1440) does something like that in a saner manner, but it needs a lot more work to be mergeable. Nice idea, though the units gathering in the video look hilarious.

Some ideas: Option to disable rendering of corpses and projectiles on the ground. Not rendering possibly thousands of objects likely helps quite a lot. Render very low poly replacements at a certain distance. A thousand tris for something the size of a few pixels is not worth it. Option to allow rendering at lower resolution and then scale up. Probably rather useful for 4k users. Use of vulkan instead of opengl. Decouple observers, if they can't keep up it's their problem alone. Possibly move some components to C++ to increase execution speed and to reduce interaction between native code and interpreter. The latter probably is a major bottleneck in 0ad. Sure this reduces the ease of modding to some extent. One I don't like to see personally. Let units have no obstruction so the pathfinder has it easy.

Ha, let's introduce a tech "armour polish", faking increased stats.

Yeah, good point. Maybe make it part of the bribe mechanic to get this info.

If the stats in this screenshot fully represent the unit, then the underlying model is simpler than 0ad. In that case it sure is nice to get away without click to see stats. I just think displaying half truths is worse than click to see. What we can also see here the gui is optimized for 16:9 FullHD.

The right panel is currently 10x4 icons and could be changed to auto collapse if not enough space to 4x1 each of the 4 opening a submenu - preselect, build, research, train. Not saying this is the best solution but at least the room argument would no longer work. I fully agree with you that the preselect actions should be available via gui by default in some way. About the resolution of 1024 × 768, the last time I bought one of those monitors was in the 90'. Rather than absolute pixel one should consider screen format a primary concern and have properly working scaling in place. Armour are currently 5 values - hack, pierce, crush, fire, poison Worse for attack, even without weapon switching - hack, pierce, crush, fire dmg, fire interval, fire duration, poison dmg, poison interval, poison duration, range, attack interval, counter boni This obviously won't reasonably fit. My take, instead of showing half the truth better to not show at all. For beginners I'd say those numbers are rather useless. Far better to have a page which roughly tells in prosa which unit to use for what purpose. Numbers only start to matter once you can play somewhat competitive and have a good understanding how those numbers interact, but by then you likely already know them by heart. I know there is no definitive answer how to go about it and I appreciate that you take the time thinking about how to improve the current situation which is tedious and difficult to say the least.

Why limit yourself to the current panels? Putting preselect actions into a separate one probably beats stuffing them into the right panel which is already overloaded for different purposes. As they all have a hotkey attached it might even be desirable to have a menu option to not display said panel at all. About numbers, there are to many for them to be listed all. So except for the most important and dynamic ones like resource carried the rest is probably better hidden behind a redirection like a tooltip or pop-up menu and the gained space used for other things or given back to the viewport.

I had no issue with the Romans, haven't tried with Persians. So I'd say same issue. Likely cause: non square obstruction

I can simply bind the hotkey to send SIG_STOP/SIG_CONT via window manager, so I'm fine with postponing. But then please add the screen saver inhibition thingy to the TODO list.

I see, well, pausing the simulation and explicitly pausing the game are strictly speaking not the same. Never relied on background pause, so personally don't care Well, the phone call could also be an internet call, was just making up an example here. I don't use pulse by the way.

Over the house coloured red, seems built-in screenshots feature ignores cursor. Haven't even noticed.

Hope a screenshot will do, no recorder installed on this machine.

In A23 using the hotkey pause the music was paused as well, which allowed me to for instance take a phone call or do some other work which depends on sound. A simple example could be watch a video on a different virtual desktop. "Background pause" refers to the window having lost focus? If so this IMHO should behave as I stated in the OP.

Pausing the game should mute the game. In an ideal world it also shouldn't inhibit the screen saver while paused.

With r24769 and Seleucids if I try to place a house beside another house while holding Ctrl for snapping I get the "House cannot be built on another building or resource" error. Edit: Only happens along one axis.

Just a quick glance, so might have missed some of the quirks involved. Why not use alignas instead of padding? Are there enough vector3D "alive" that an additional bool actually matters? L (length) seems to be singed, so why using zero for maybe invalid instead of <0 for invalid? You are over commenting quite a bit me thinks.

This perfectly demonstrates the issue. If it's desirable to be able to quickly take out any buildings with basically any unit, as is the case with capture-delete, the correct thing to do would be to make structures simply a lot more brittle. Capture-delete just destroys the immersion for me. Btw, ranged units not running to the front and getting in the way of sieges can be considered one of the favourable behaviour changes of this mod. Sure this is a matter of taste and priority, I don't expect everyone to agree.

Might make sense to query max samples and only present msaa options available by hardware/driver in the menu then.

There is certainly something doggy going on - card vega11, driver amdgpu, switching to msaa16 I get: WARNING: Wrong MSAA sample count: msaa16.

Another release: fix default of capturing after unloading when rally point is a building (noticed by @FeiLongbay) Add three minutes ban on deleting after capture Adds a diff of all changes on top of A23 to the archive for easier study by others capture-0.23.1.pyromod

I can reproduce the capture instead of attack after unload, obviously unload to attack buildings I only do with sieges if at all so I didn't run into this myself. If the rally point is a building the behaviour is unexpectedly strange. Guess could be considered buggy. "set-on-fire" could indeed be added as another entity/unit action. The structure then would receive fire damage over time. This would be easy in A24 as there fire damage over time is already implemented. However, I see this a complementary to the ban on outright delete a structure recently captured.

Well, a proper implementation probably should decouple capture and attack. The mod only hacks the default behaviour of attack to not be capture. But I'd certainly appreciate if developers who think this is a possible improvement in unit behaviour could state so. Then it be worthwhile to do it properly. Will package the patches with the next version of the mod. For the other issue mentioned in the initial post I have locally added an extra patch, which still needs some testing. Simply didn't had the time yet. Break the capture-delete meta Capturing should be meant for own use afterwards. Currently capturing is cheap alternative to kill/destroy an enemy entity. This only works as delete as a game mechanic is instantaneous without cost or leaving debris behind. Long-term one might want to change delete to be more like building. However this requires a lot of thought and new artwork. For structures it would work to require it to be connected to an owned territory root to prevent capture-delete in relevant cases but might prevent freeing space if the CC got destroyed or captured to make room for building a new one. However this approach doesn't extend to captured units. This patch therefore implements a 3 minute ban on deleting after an entity changes ownership.

@FeiLongbay, thanks for the feedback. pyromod is a zip file, so you can use unzip to extract it. See also https://trac.wildfiregames.com/wiki/Modding_Guide#Howtoinstallmods I agree that flaming cav sees the biggest improvement. This is out of scope of this mods initial idea, but I think it's worth looking into. The main issue might be a quite noticeable performance penalty though. Will have to test it out. Do you mean if you ungarrison a siege? I'll do that with enemy troops around. For buildings you can set a rally point (move, attack-move, attack-move-unit, capture ...). So I haven't noticed this issue yet, will see were it comes from. They do but they won't switch if they are already attacking a siege which is likely the correct behaviour.

Camels speed was around 13 and horses around 17 which "makes perfect sense". Haha. Well I stop from further harping on this "sense" thing, I think I got my point across by now. I forgot before to mention pikemen were horribly slow, harming economy and were left in the dust by rams. Well the game gets optimized for midland with temperate biome, so high stone and metal cost becomes an issue. Only food and wood is abundant there. So a merc can't cost 100 metal unless you have enough alternative units to choose from.

The number needs to be a multiple of 5 so the 20% pop bonus techs for the houses are straight forward. I agree that having to build lots of houses is annoying. With A24 you will probably have to add Britons, Gauls and Ptolemeus to Mauryan. Well, many people consider houses the primary means to build walls (rolls eyes). Doubling pop boni for houses might be a good idea or make it 10 and 15 if 20 sounds like to much for large houses.