historic_bruno

Fixed renderpath looks much better now This is a bit weird, actors aren't being shaded in LOS, but that may have been a problem before? And for lack of a better place to mention this, the "basic_trans_parallax_spec.xml" material references an alternate material "basic_trans_spec.xml" which doesn't exist.

I was thinking earlier about GLSL and ARB. Doesn't it seem more wasteful to duplicate all the same features for two different shaders than to support them for only one type of shader and still have a decent fallback for old hardware? Just think if a bug is found in one implementation of windy trees or parallax (as an example) it has to be fixed in the other and if a parameter changes in one, it has to be changed in the other. Seems like potentially a lot of maintenance going forward. At least with the fixed renderpath we can mostly ignore all the new advanced rendering stuff we add which is purely eye candy, and as long as we don't break it we're fine.

Alternative POV: consider these issues before breaking a currently supported platform, not after they are broken, and especially not ~a week before a new release It's worth discussing at some point, but keep in mind that up to now, supporting even old hardware has been much more important to 0 A.D. than flashy new graphics features.

Some of the in-game sounds are quite loud already, maybe music needs to be boosted slightly, or which sounds are you thinking are too quiet?

Hi, what were you doing when this error occurred? Was it during startup, resizing, switching fullscreen, etc. The more info you provide the better

While looking at the strange use of CStrW in CSoundData, I noticed that apparently m_FileName is never assigned to, yet GetFileName() is used in ReleaseSoundData(), so it seems that's an oversight and possibly a memory leak if it never cleans up the sound data. Obviously a silent failure somewhere, which is annoying We don't check the return value of OpenOggNonstream() so that's bad, it could fail for one of many reasons.

Yeah, fixed renderpath can be used when the person's hardware has a buggy shader implementation, to at least make the game playable without crashing. We already detect a few such cases in hwdetect.js: Mesa DRI R1/2/300 drivers, GeForce FX, and SiS Mirage 3. I'm sure there are others we don't know about yet, so it's nice to keep the option available. We're doing testing today in staff multiplayer matches, if we don't find any more release blockers, it's safe to assume the final build and packaging will occur within days.

You would think, but really it's about context and advertising. If you're good at advertising, you can sell almost anything to anyone. Personally I have seen people sell some of my free works in the past which were not GPL or even open source and explicitly forbade reselling in the license, going for upwards of $10 for a digital copy, simply because people found that ***hole before they found me offering the same thing for free. In some markets there is actually a reward for selling other people's work even in violation of license, because the marketplace earns a percentage of the sale (e.g. eBay, Amazon, etc) and the profit can be used in turn for advertising and enhanced listings which further supports the site, and also search results tend to favor pricier items (for this reason), so there is very little incentive for them to do anything about it - everyone benefits it seems, except the original author. Also in my experience, there is a price people will pay because it seems reasonable for the quality of the product or how it's presented, they'll never think that it could be free?! let alone less expensive. People in the FOSS community think differently than the "outside" world.

Check the weekly reports in the Announcements / News forum. Those are basically all A11 previews.

Can you also provide the terminal output from the game's startup?

Yes (This would qualify as a regression especially since it was part of fixing a case that almost no one will use - GLSL)

I have that as well on Windows, you have to check the logs, it only seems to occur on shutdown. Maybe it's calling OpenAL functions after it has been shutdown (notice it occurs in the destructor), the opposite of the problem we had before.

About this one: the cause seems to be that it's referencing a non-existent third UV set: <input semantic="TEXCOORD" source="#Cube_161-mesh-map-0" offset="2" set="0"/> <input semantic="TEXCOORD" source="#Cube_161-mesh-map-1" offset="2" set="1"/> <input semantic="TEXCOORD" source="#Cube_161-mesh-map-2" offset="2" set="2"/> where Cube_161-mesh-map-2 doesn't seem to exist.

Updated COLLADA / DAE files with converter warnings and errors (warning => probably will convert and appear in-game, error => probably won't): ERROR: art/animation/biped/inf_2_hand_sword_attack_a.dae: Didn't find any objects in the scene ERROR: art/animation/biped/inf_2_hand_sword_attack_a.dae: Couldn't find object to convert ERROR: art/animation/biped/inf_spear_attack_a.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/biped/inf_spear_attack_a.dae: Couldn't find object to convert Converting model C:\Users\Ben\devel\ps\binaries\data\mods\something\art\animation\biped\inf_spear_attack_b.dae ERROR: art/animation/biped/inf_spear_attack_b.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/biped/inf_spear_attack_b.dae: Couldn't find object to convert ERROR: art/animation/biped/inf_spear_attack_c.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/biped/inf_spear_attack_c.dae: Couldn't find object to convert ERROR: art/animation/biped/inf_spear_attack_d.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/biped/inf_spear_attack_d.dae: Couldn't find object to convert ERROR: art/animation/biped/inf_spear_attack_e.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/biped/inf_spear_attack_e.dae: Couldn't find object to convert ERROR: art/meshes/gaia/tree_apple_top_e.dae: Assertion not satisfied (line 569): failed requirement "mesh has single set of polygons" ERROR: art/meshes/gaia/tree_apple_top_f.dae: Assertion not satisfied (line 569): failed requirement "mesh has single set of polygons" ERROR: art/meshes/gaia/tree_apple_top_g.dae: Assertion not satisfied (line 569): failed requirement "mesh has single set of polygons" ERROR: art/meshes/gaia/tree_apple_top_h.dae: Assertion not satisfied (line 569): failed requirement "mesh has single set of polygons" WARNING: art/meshes/gaia/tree_apple_trunk_c.dae: FCollada 105: Polygons is empty. ERROR: art/meshes/gaia/tree_apple_trunk_c.dae: No polygon <p>/<vcount> element found in geometry. WARNING: art/meshes/gaia/tree_apple_trunk_d.dae: FCollada 105: Polygons is empty. ERROR: art/meshes/gaia/tree_apple_trunk_d.dae: No polygon <p>/<vcount> element found in geometry. ERROR: art/meshes/skeletal/deer_mesh_skeleton.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/meshes/skeletal/deer_mesh_skeleton.dae: Couldn't find object to convert ERROR: art/meshes/structural/iber_boat_fishing.dae: Assertion not satisfied (line 568): failed requirement "mesh is made of triangles" WARNING: art/meshes/structural/rome_temple_big.dae: FCollada 100: Unknown polygons set input. ERROR: art/animation/infantry/spear/idle/hoplite_idle_1.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/infantry/spear/idle/hoplite_idle_1.dae: Couldn't find object to convert ERROR: art/animation/infantry/sword/idle/isw_idle_02_neck.dae: Unrecognised object type ERROR: art/animation/infantry/sword/idle/isw_idle_b_01.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/infantry/sword/idle/isw_idle_b_01.dae: Couldn't find object to convert WARNING: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: FCollada 69: Empty animation clip. WARNING: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: FCollada 69: Empty animation clip. WARNING: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: FCollada 69: Empty animation clip. WARNING: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: FCollada 69: Empty animation clip. WARNING: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: FCollada 69: Empty animation clip. ERROR: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: Found too many possible objects to convert - try adding the 'export' property to disambiguate one ERROR: art/animation/infantry/sword/move/run/isw_s_def_em_off.dae: Couldn't find object to convert

Are we even using self-light? If not, I would just disable it for all materials and make people create a new material if they want self lighting. Seems less likely to cause confusion.

Thanks, that's done it!

They were left out by mistake, it should be fixed now

Not for me, sorry The SoD initially is totally black and I can't see any textures underneath, but once I use reveal map it is only very dark but not fully black.

There are other solutions: use different sized icons (smaller when there are more unique choices) or allow them to overlap sometimes to fit more in the same space.

Nice - I think that's the right direction My first thought when I saw the mat on the roof was that's a sleeping or resting area, all it's missing is an awning or something for shade Maybe since there's a walled in space now you could add a few plants or a "garden" area, nothing too lush as there's hardly any rainfall, more of a natural space You could even prop some existing livestock actor(s) in a corner. Some sources I read suggested house roofs were most often thatched not stone, but I'm not sure about the case of multiple stories. Looking at our Carthaginian house variants, they appear to be thatched on the highest flat part of the roof.

You'll like Alpha 11 then Welcome!

This has long been an issue I've noticed, the SoD is not completely black after toggling the reveal map option, which I figure is OK since that option shouldn't be used normally I can still reproduce it as of r12560. My monitor is very bright so it may be that I notice this and others do not, or it may be specific to my graphics card...

Works like a charm, tested with and without audio build, with and without archived data. I say commit it when you get the chance

Thanks, I tried the new patch. It's still missing a return statement in OggStreamImpl::ResetFile which is a build error in MSVC I saw two errors on startup: The second error should be left as a debug_printf or similar since it's not an error and need not be displayed. The first error seems a result of calling AL_CHECK before OpenAL is initialized (not a real error). Then I tried compiling --without-audio. lib/external_libraries/openal.h is included outside CONFIG2_AUDIO in several places: OggData.h, SoundData.h, CSoundBase.h, and ISoundItem.h, which cause build errors since the OpenAL library has been excluded from the build. Probably it can be cleaned up a bit by moving all includes except config2.h inside the CONFIG2_AUDIO check. After fixing those errors, audio was indeed disabled and I had no runtime errors Minor issue: warning about unused variable doEnable in CSoundManager::SetEnabled - this might be fixed by handled the !CONFIG2_AUDIO case and inserting something like UNUSED2(doEnabled); to make the warning go away.

I'd also like to point out that I have a somewhat new but not top-of-the-line graphics card and it easily handles all the new graphics features without much impact on performance. Still they will be disabled by default in A11, as it's experimental and we don't yet know which hardware best supports which options. The real issue with performance is not graphics related, but definitely pathfinding and AIs (this is easily verified by using the profiler in game - F11). That said, I've played several multiplayer matches lately with up to 6 players and performance was surprisingly good (all humans, no AIs). Think of it like this; we're moving toward a completed game by adding necessary features, it would be somewhat counterproductive if we only focused on performance issues, because adding new stuff could introduce new performance issues, the game might never be finished. We currently put a lot of effort into finishing art and programming tasks, a similar amount of effort into bug fixes, and the leftover is performance issues. Not to mention that at least on the AI and pathfinding side of things we're currently waiting for 1-2 people to finish their work so it's hard for anyone else to assist