Darkplaces Error Reporting Thread

[LordValsary]

Update the drivers brought improvement

Hello !

As I wrote I had nothing but problems with textures, models of weapons.
Update the drivers brought improvement.

https://www.dropbox.com/s/toh3oa97qkr3l7u/a.jpg?dl=0
https://www.dropbox.com/s/a5jlqjmnjfd95mx/b.jpg?dl=0
https://www.dropbox.com/s/c0tj4rpii98vvng/c.jpg?dl=0
https://www.dropbox.com/s/iwinwz50m32diqo/d.jpg?dl=0
https://www.dropbox.com/s/grl2k6j96hqrg0q/e.jpg?dl=0

I use mostly classical models with textures HD - maybe this is the reason.
Anyway...I'm happy now everything looks great!
Many thanks for the tip.

[talisa]

you're welcome! glad i was able to help with your problem


so on nvidia drivers v347.09 all models look ok?
if so, its good to know there's a newer driver-version again whcih doesnt have the texture-bug with MD3-models

[LordValsary]

updated the nvidia drivers

Thanks for the reply.
I updated the nvidia drivers to version 347.09
Now everything looks ok.

[talisa]

@lordvalsary
thats not a darkplaces bug, that is a known bug with recent Nvidia drivers and MD3

revert your GPU drivers to version 320.49 and all models will look fine


.


the particle-thing is related the the DP build.
darkplaces builds from before 2014 handled particles differently then the newer 2014 builds

for older DP builds you will need to set 'darkplaces_build' to 0
for newer DP builds from 2014 you must set this setting to 1

[LordValsary]

problem with texturing models

Hello!
Sorry for my poor English.
I have a problem with texturing models of weapons. Sometimes loading correctly but mostly bad.

https://www.dropbox.com/s/2bchyn62jlajlth/wep1.jpg?dl=0
https://www.dropbox.com/s/4p27ofv24obdo0k/wep2.jpg?dl=0
https://www.dropbox.com/s/r07lwq78eosrrdl/wep3.jpg?dl=0

I use the last stable version DarkPlaces engine Windows 64 OpenGL build 20140513
and i tried also DarkPlaces engine Windows OpenGL build 20140513 darkplaces executables for Windows-32bit.
Small-mod-compilation 5.11 - with defaults settings.
I'm using Windows 7 64 bit, my video card : GeForce GT 540M 1GB (laptop).

I do not know what is badly tried different things, for example - Epsilon mod v2.52 based on small-mod-compilation v3.80 and DarkPlaces 2011 works well.
I used earlier compilation: darkplaces engine 2012-12-22 with texturing is ok but I then errors with special effects 5.11 SMC

https://www.dropbox.com/s/10sbkn7ajgetnsc/fx.jpg?dl=0

Are these lines in the smc_config.cfg file (SMC 5.11 with DarkPlaces 20140513 ) are correct ?

sv_gameplayfix_upwardvelocityclearsongroundflag "1"
sv_gameplayfix_setmodelrealbox "1"
sv_gameplayfix_droptofloorstartsolid "1"
"r_useportalculling" "1"
set darkplaces_build 1
set player_reflection_fix 1

Regards.

[Seven]

Hello Pringles Man,

There is no DP related bug here.
If you look into the available Rogue devkit, and we all believe that its source is correct, it tells you the following:

Wrath is inflicting 80 radius damage when he dies.
Super_Wrath (aka Overlord) is not inflicting any damage when he dies.

Regards.

[talisa]

hmm.... i just checked with original dos-quake using dosbox,
and the overlord's explosion also doesnt do any damage in original dos-quake.

so if it's supposed to do damage it was always bugged even in dos-quake.

[Pringles Man]

Interesting. I remember playing the original DoE without any modifications way back in the day, and the overlord did in fact deal damage on death. MP2 is a very buggy expansion for reasons I still can't imagine to this day. But anyway, I paid a visit to the Quake Wiki's article on the overlord, and here's what it says:

"Attack Damage

(6-9) Wrath ball
(21-29) Axe and Mace
(60) Death Explosion"

I may be wrong still, but this is still something interesting I stumbled upon in that respect.

[talisa]

@pringles
about doing damage:
it doesnt do any damage either in stock quake.
i tested it with fitzquake engine with stock quake and it didnt hurt me then either
so this is no bug, its not supposed to hurt the player


about sound:
i tested and it does in stock quake with 2014DP build, so its not engine-related.

i did however notice that when playing with the SMC there indeed was no sound when the overlord exploded.
you should report this bug to seven and post about the bug in the official SMC-thread: http://quakeone.com/forums/quake-mod...mpilation.html

[Pringles Man]

On the subject of DoE bugs, the super wrath/overlord doesn't deal any damage when his body explodes, nor does the explosion play any sound. Don't know if this is a recent DP engine bug, but it is a bug nonetheless.

[talisa]

thanx for the QC-fix seven

you made mistake though in the ent-file for R2M7.
you made the 3 buzzsaws move simulataneously back and forth
did a quick edit to the ent-file so that the buzzsaws once again move in the pattern they should be moving in

.

thanx again lots for the QC-fix for this issue
really bugged me that the buzzsaws were broken before


EDIT: whoops, added the wrong ent-file to post. fixed now!

[Seven]

.

[talisa]

erlier while testing a buzzsaw model i am making for ROGUE. i stumbled across a bug

in any builds after the 20130304beta1 build the buzzsaws in the second mission-pack are broken.
they dont move back and forth across the path set for them but instead stay at the start-position, and the animation of the model appears broken too.

ive already tried enabling all of the 'sv_gameplayfix' vars that have been disabled in the newer2014 builds, but the buzzsaws were still broken

any builds later then 20130304:
[ame]http://www.youtube.com/watch?v=yn0A9aQ7MRo[/ame]


builds from 20130304 and before:
[ame]http://www.youtube.com/watch?v=29r8g_doX2U[/ame]

.

in addition to this post ive also sent an email to lordhavoc himself about the issue.
hope he will fix this bug soon!

[Seven]

Hello anyeos,

Thank you for your additional description, now I have understood the issue.

Yes, as soon as you make the diffuse texture transparent (also only a small part of it), the "opaque" parts/areas of it will become slightly transparent in-game too.

I am not an experienced person, but I think there are at least 2 solutions for this:

1.) Use a .md3 model, with 2 different model parts/textures
One will be the model part which shall be totally opaque (with its own texture)
The other will be the transparent one (with its own texture)

2.) Use any .mdx model format you want + a shader.
You can for example use the original .mdl model and make your replacement texture for it partialy transparent.
Then add a shader which only draws the parts of the diffuse textures, with a certain value of transparency or less/more.

Something like this:

progs/soldier.mdl_0
{
     // cull disable		// add this if you want to look "INSIDE" the soldier (with his back skin drawn !!)
        {
                map progs/soldier.mdl_0.tga
		alphafunc GE128
	        rgbGen vertex
        }
dpshadow
}

GE128 means that only parts of the texture with greater alpha values will be drawn.
There is also LT128 which draws only smaller alpha values.

Be aware, that a hard limit means, there is now 'fluent' alpha possible (for example from fully opaque to fully transparent). For this you must use alpha blending.

Nice Q3A shader descriptions can be found here or here for example. There are of course also others.

Best of luck,
Seven



PS: I made some quick screenshots with the above mentioned and this test skin:
(I simply made a hole into the soldiers chest)



Without shader (complete texture becomes slightly transparent):



With shader:



With shader + cull disabled keyword (you can see the "inside" (= backside) of the model through the hole):






Be also aware, that as soon as a texture is transparent, its model will not cast shadows anymore ! You have to use the dpshadow keyword to cast shadows again:

[anyeos]

Thank you very much for your help but I discovered the "error".
It happens when I use alpha in the skin.

For example: We have a torch model, so the fire must be some translucent but the rest of the torch is opaque. Well, when I use alpha channel in the skin, the fire shows correctly (I use gimp for example to make it translucent), but the opaque torch (full solid color) in some angles draw the backside over the frontside (like EF_DOUBLESIDED).

I guess it happens only when some alpha is present outside the mapped (UV mapped) areas. So I must use always opaque background for the unmapped areas? I guess.

I am not sure right now if it is present always using the alpha channel regardles of anything else or if it is pressent only when I put by mistake some alpha in the unmapped areas of the skin.

But what is clear is that it is related with the alpha channel of the skin.

And not, I am not talking about the normal map, I am talking about the standard (diffuse I guess) skin, no glow, no gloss, no normal, nothing more.

I talk about the normals of the triangles, that I guess are used to determine the side that must be drawn/shown to the viewer.

But the "bug" is like putting the effect EF_DOUBLESIDED. That maybe give you a better idea.