OrbWeaver

There's no need to feel bad about that. We all have different energy levels and amounts of available free time. I find it helpful to set realistic targets, rather than taking on a massive project and then giving up because it seems so overwhelming. For example, I aim to spend one or two evenings a week working on something mod-related, even if it's just adding a small section to the DR manual, doing some minor C++ refactoring that hopefully moves towards fixing a bug, or cleaning up one of the Blender export scripts. You'd be surprised how quickly a small thing each week adds up to something more meaningful over time, and is infinitely better than doing nothing at all. Likewise, as a mapper you might be able to contribute small regular tasks like helping to design a prefab or model for someone else's map, rather than taking on a large mapping project from scratch by yourself.

Let's not go overboard. It's nice if the mod gets a mention in the gaming press, but that isn't a reason to bow down and kiss the feet of the media. That sort of thing is likely to alienate some of the potential playerbase (they will perceive it as "media whoring", "selling out" etc). Of course there's nothing wrong with engaging with their community in a friendly (and non-spammy way), helping people with installation issues or particular missions. But I wouldn't vote for blatant marketing-related things like putting commercial banners in the game.

Presumably this part is the problem? If the lighting interaction shader cannot be compiled, a black screen is likely to result.

Not nitpicking at all. Correctly adjusting volume levels is important but often neglected, even in commercial games (in Dungeons and Dragons Online there are certain quests with background music which is deafening and renders the game sounds inaudible, making me wonder if the developers ever actually test their own game). It's very easy to introduce a cool new sound or piece of music but make it too loud, because subjectively "loud sounds better" to most listeners. Waveform normalisation doesn't solve this problem, because many sounds need to play at different volumes, and peak amplitude doesn't entirely determine subjective loudness in any case. If background music plays at the same RMS power as guard shouts, then the music will sound too loud and the player will struggle to hear the guard shouts at all. I don't think new cvars are needed, just some sensible tweaks to the volume offsets in the sound data files. If particular sounds are too loud, this can be tweaked by adding small volume reductions (e.g. steps of -2 dB) in the sound shader until the subjective volume levels seem more similar. One thing I learned in music production is how much you can progressively lower the volume of a sound while it still remains completely audible (because human hearing is non-linear), but it fits so much better in the mix once it's reduced to a similar level as surrounding sounds.

It wasn't released in the last few weeks, but Left 4 Dead 2 was criticised as "racist" because a few of the zombies were black (despite the story being that the whole population had been infected, which obviously would include people of all races). The "last few weeks" thing refers to the frenzy of censorship and corporate virtue-signalling that has occurred across various types of media since the start of the BLM protests, including the removal of Magic cards, the renaming of Git branches, and the deletion of decades-old TV series. I don't know if it has yet affected video games, but given that it is affecting all kinds of other media I doubt that video games are somehow going to be immune.

Yep, that's the ridiculous irony. If your zombie game doesn't include any black people, it's "whitewashing". If it does include them, but some of them are enemies or get shot, that's just plain "racism". I suppose at this point the only acceptable racial composition is to make every protagonist an immortal black person who never gets injured while shooting a load of all-white zombies, but I doubt even this will manage to avoid treading on some woke landmine. Maybe allowing white gamers to play a black protagonist is "cultural appropriation" or "blacking up", so we need to make sure the game is only purchased by people of color while all the white gamers are on their knees at the back of the gaming store whipping themselves with chains?

I'd like to agree with you, but sadly the events of the past few weeks have shown that censorship is still as rampant as ever, it's just that it comes from different people and relates to different things. Sure, the days of the evangelical Christian Right shutting down games for offending Jebus are long gone. But just try making a couple of those dangerous zombies black or female and watch the controversy roll in, possibly even resulting in your game being memory-holed by publishers and replaced with craven, grovelling apologies.

Really? That sounds like a bug. It certainly should be possible to modulate the diffusemap with vertexColor, and the result should look similar in game to how it does in the DR renderer. Modulating the specular map is certainly possible, but this should only affect the color of the specular highlight, not the overall color of the model which is determined by the diffusemap stage. Actually that is useful information, thanks. The error is from OpenGL when we try to call glCompressedTexImage2D, which returns an invalid format. I thought maybe this was because there was a problem with my graphics drivers not supporting the required DXT formats, but if the data is actually uncompressed and we are trying to call the function to upload a compressed image, this might well be the cause of the problem.

diffusemap textures/darkmod/vertexcolors_break_shading/placeholder2 { blend specularmap map textures/darkmod/vertexcolors_break_shading/placeholder2 vertexColor } For some reason your material is only blending vertex colors with the specular map, which is why you don't see it in the renderer. If you want to see the vertex colors you need to blend them with the diffuse map, e.g. { blend diffusemap map textures/darkmod/vertexcolors_break_shading/placeholder2 vertexColor } { blend specularmap map textures/darkmod/vertexcolors_break_shading/placeholder2 vertexColor } If I change this I can then see the vertex colors, although for some reason DarkRadiant does not want to load the "placeholder" DDS file so the wall and floor textures are missing.

DR will not show vertex colors in fullbright preview mode, but it should should vertex colors in lighting mode if the material has an appropriate vertex color stage. This is certainly working for me when I am testing vertex color export from the ASE and LWO exporters. If this isn't working for you, could you please confirm which version of DR you are using and if possible provide an example model along with its MTR file which demonstrates the problem?

I don't think the engine is supporting it — the weighted normals are calculated by a modifier in Blender which is applied before export, resulting in (presumably) modified explicit normal vectors baked into the ASE file.

Based on this evidence, I would guess that the problem is something to do with uninitialised values in the code which loads model files. Perhaps some variables are being re-used without being properly cleared, resulting in leftover vertex color data influencing normal vectors.

Does it make a difference which modifiers you use in Blender? If you skip Weighted Normals and just use regular smoothing or the Autosmooth functionality, do you get different results after exporting? I wonder if those weighted normals somehow aren't making it correctly into the ASE file.

It's definitely not a DR problem — DR does not write or in any way modify materials or model vertex colors. The screenshots are from in game, so it must be an aspect of the way the game engine renders vertex colors. It's possible that DR might render vertex colors incorrectly (although I'm not aware of any specific issues) but this would not affect the appearance in game. Blending between two textures is the most common use-case for vertex colors, but it is definitely not the only possible one. Using vertex colors to modify the visible color of a mesh is a perfectly legitimate technique and this should work correctly. I'm guessing the problem is caused by something in the more recent versions of the graphical shaders used by the engine, but one of our graphical developers would need to investigate further.

It's just politics. It's entirely outside the control of game developers. Nobody cares about shooting and death in video games as long as the targets are all acceptable: enemy combatants, Nazis, zombies, degenerate criminals, mutant aliens. Only when the violence starts to affect unacceptable targets (e.g. women or protected minorities) does anyone have a problem with it. On the other hand, introducing sex into video games is going to get your product slapped with the most restrictive adult rating, labelled a "porn simulator", possibly dropped by vendors or gaming stores, and attract criticism from across the political spectrum — the Right will declare that it is immoral and decadent, the Left will protest that it is sexist and degrading to women. You can hardly blame game developers for not wanting to bring that storm down on their own heads.