TDM v1.06 bug thread

[PranQster 457]

I put the Forger into my map and the gloves and apron render solid black and show no texture on the model in DR. Aprilsister, who is beta testing, also shows no glove or apron textures in-game.

[stumpy 242]

missing skins default to _black texture, had a look and actually cant fine a skin definition file for the forgers, although can find the textures for gloves and apron.

[ungoliant 120]

hm, my glitchy AI skins seem to show as _white, which is super annoying and contrast highly in almost every setting in TDM. Makes keys/loot on belts harder to spot as well. I've been having that difficulty since long before 1.06 though, but it hasn't been fixed yet (assuming its not something on my end).

[PranQster 457]

missing skins default to _black texture, had a look and actually cant fine a skin definition file for the forgers, although can find the textures for gloves and apron.

 

 

Looking inside of 'tdm_ai_humanoid_townsfolk01.pk4' :

 

There is a '/def/tdm_ai_townsfolk_engineer.def' for the forger, but I don't see a .def for the scientist... scientist must not need one because he renders fine.

I did notice that there is:

'/models/md5/chars/inventors/engineer2' > *.jpg and *.tga (no .md5mesh file here) ... also notice the '2' in the path such as 'engineer2'

'/models/md5/chars/inventors/scientist' > *.jpg and *.tga and 'tdm_inventor_scientist.md5mesh'

 

And then there is:

'/models/md5/chars/townsfolk/engineer/generic_engineer.md5mesh' (the only file in that path) ... also, no '2' following 'engineer' here

Also, in this .md5mesh file are lines such as:

shader "models/md5/chars/builders/forger/forgerbottom"

 

So, should the forger's path be like 'models/md5/chars/builders/forger/' or like '/models/md5/chars/inventors/engineer2/' or like '/models/md5/chars/townsfolk/engineer/' ???

I'm confused because I thought there was going to be 'Forger' and 'Engineer/Scientist', but Forger seems to be referred to as 'Engineer' as well as 'Forger'

 

Is that what needs fixing?

Edited June 27, 2011 by PranQster

[Springheel 4645]

Is it a default Builder forger or are you using a skin?

 

Are there any errors in the console about missing textures?

[PranQster 457]

Is it a default Builder forger or are you using a skin?

 

Are there any errors in the console about missing textures?

 

I used the default forger. I'm sure there are errors, but won't be able to check them for more than a week.

[Sotha 1909]

From Oscar's problem thread:

 

Has anyone ever been able to use S&R "turn light on" effect correctly?

 

Looks like the light gets turned off with the "turn off effect"

But the "turn on" never relights the light.

 

Is this a bug in the S&R system? I think I set everything correctly in this test map:

http://www.mediafire...dah3y9eapluw8f2

 

but the light "turn on" behavior does not work.

 

Anyone interested looking at this?

[Tels 278]

The (small) metal glasses from the Builder Forger / Engineer/ BlackSmith (not sure which of them it is) are set to solid which means very often instead of blackjacking him, you hear the "metal clunk" sound and he gets alerted. Shouldn't a hit to the glass stun him, anyway?

[lost_soul 128]

I've started getting crashes in TDM 1.06 after I install a new FM... or at least I think it crashes. TDM just closes and does not restart. --Debian Squeeze 32-bit with NVidia drivers and 8 GB of RAM.

 

I have to restart it manually, which isn't really a big deal.

Edited July 1, 2011 by lost_soul

[Tels 278]

I've started getting crashes in TDM 1.06 after I install a new FM... or at least I think it crashes. TDM just closes and does not restart. --Debian Squeeze 32-bit with NVidia drivers and 8 GB of RAM.

 

I have to restart it manually, which isn't really a big deal.

 

This seems to be a boost-linux problem. Could you please track this at http://bugs.angua.at/ ?

[Springheel 4645]

I put the Forger into my map and the gloves and apron render solid black and show no texture on the model in DR.

 

Can anyone else confirm this? The forger shows up fine for me in 1.06.

[New Horizon 524]

Can anyone else confirm this? The forger shows up fine for me in 1.06.

 

The textures were setup properly for the two variants of ambient lighting?

[Sotha 1909]

When the player steps on texture

textures/darkmod/nature/dirt/dry_earth_muddy

there is this sound of wet muddy footstep. "Splut."

 

When an AI steps on the same surface there is the sound of a heavy clomp, like he steps on concrete (but it is not the same sound that is hear when he steps on stone floor.)

 

The sound is muddy&wet for the player but for AI it is dry and solid. AI uses incorrect sound shader?

[Springheel 4645]

Sounds like the AI is playing the default footstep. What type of material is it?

[Sotha 1909]

Sounds like the AI is playing the default footstep. What type of material is it?

 

textures/darkmod/nature/dirt/dry_earth_muddy

 

Defined in materials/tdm_nature_dirt.mrt

 

Definition says:

 

// Author: shotgun
textures/darkmod/nature/dirt/dry_earth_muddy
{
surftype15
description "mud"

qer_editorimage 	textures/darkmod/nature/dirt/dry_earth_muddy_ed
diffusemap 	textures/darkmod/nature/dirt/dry_earth_muddy
bumpmap 	textures/darkmod/nature/dirt/dry_earth_muddy_local

{
	if ( parm11 > 0 )
	blend 	gl_dst_color, gl_one
	map 	_white
	rgb 	0.40 * parm11
}
{
	if ( parm11 > 0 )
	blend 	add
	map 	textures/darkmod/nature/dirt/dry_earth_muddy
	rgb 	0.15 * parm11
}

// TDM Ambient Method Related 
{							
	if (global5 == 1)		
	blend add				
	map				textures/darkmod/nature/dirt/dry_earth_muddy		
	scale			1, 1		
	red				global2	
	green			global3	
	blue			global4	
}							
{							
	if (global5 == 2)		
	blend add				
	program	ambientEnvironment.vfp	
	vertexParm		0		1, 1, 1, 1		// UV Scales for Diffuse and Bump	
	vertexParm		1		1, 1, 1, 1	// (X,Y) UV Scale for specular		
	vertexParm		2		global2, global3, global4, 1	

	fragmentMap		0		cubeMap env/gen1				
	fragmentMap		1		textures/darkmod/nature/dirt/dry_earth_muddy_local			// Bump				
	fragmentMap		2		textures/darkmod/nature/dirt/dry_earth_muddy			// Diffuse			
	fragmentMap		3		_black			// Specular			
}
}

[Springheel 4645]

surftype15

description "mud"

 

My guess is that there is no "mud" sound for AI.

[Sotha 1909]

A bug in the bugtracker:

it says 1.06 is not yet released. Also, it is not possible to report bugs for v1.06.

[Tels 278]

A bug in the bugtracker:

it says 1.06 is not yet released. Also, it is not possible to report bugs for v1.06.

 

The first is know (but someone probably needs to PM greebo as I have no permission to change this).

 

As for the second: I am reportng bugs against v1.06 all the time!? *puzzled*

[Sotha 1909]

Not a bug, but a feature creep proposal.

 

Currently we have light/sources/all-kinds-of-torch-and-candle-flames the mapper can use for custom torches etc.

 

We do not have such a source ELECTRIC light! When mapper wants an electric light light source he can attach to a street lamp post, he has to embed a atdm:lamp_electric_grill_lit inside the streetlamp to get it to work. That means an instant +300 tris the player will never see.

 

Ordinary light-entity cannot be used if the mappers want the AI to be able to spot if the light is off. (Ordinary light-enties have no stims.)

One might ask, why does not the mapper use the combo street lamp posts? The reason is: I cannot control the lamppost shadows. For instance atdm:streetlamp_round_lit appears to have the lamp post model casting shadows so that the lighting looks awful, unrealistic and unfit for gameplay purposes (a black square near the lamp post base.) If I set it to "noshadows 1" the LIGHT stops casting shadows, not the model!

 

EDIT:

Nevermind, it was the light texture, which I mistook for real shadows. The model shadow toggling was working alright. Now it works without embedded light entites.

 

But anyways, a model-less electric light entity would be nice, since you never know what kind of electric light emitting contraptions the mappers might devise. Now such things cannot be made without adding a hidden model carrying light.

[Springheel 4645]

But anyways, a model-less electric light entity would be nice, since you never know what kind of electric light emitting contraptions the mappers might devise. Now such things cannot be made without adding a hidden model carrying light.

 

I'll look into it.

[Springheel 4645]

Something from a TTLG review:

 

one thing I noticed is that TDM Revenants are oddly vulnerable to blackjacking; it takes a ton of hits but they get completely stunned if you sneak up on them, so I ended up just bonking every Revenant to death.

[Tels 278]

Not a bug, but a feature creep proposal.

 

Currently we have light/sources/all-kinds-of-torch-and-candle-flames the mapper can use for custom torches etc.

 

We do not have such a source ELECTRIC light! When mapper wants an electric light light source he can attach to a street lamp post, he has to embed a atdm:lamp_electric_grill_lit inside the streetlamp to get it to work. That means an instant +300 tris the player will never see.

 

Ordinary light-entity cannot be used if the mappers want the AI to be able to spot if the light is off. (Ordinary light-enties have no stims.)

One might ask, why does not the mapper use the combo street lamp posts? The reason is: I cannot control the lamppost shadows. For instance atdm:streetlamp_round_lit appears to have the lamp post model casting shadows so that the lighting looks awful, unrealistic and unfit for gameplay purposes (a black square near the lamp post base.) If I set it to "noshadows 1" the LIGHT stops casting shadows, not the model!

 

EDIT:

Nevermind, it was the light texture, which I mistook for real shadows. The model shadow toggling was working alright. Now it works without embedded light entites.

 

But anyways, a model-less electric light entity would be nice, since you never know what kind of electric light emitting contraptions the mappers might devise. Now such things cannot be made without adding a hidden model carrying light.

 

Uh?

 

You should be just be able create a new func_static, set its class to:

 

entityDef atdm:static_electric_light_lit_base

 

set it's "model" to "" (so it has none), and then attach whatever model you have as your model. Or simple replace the model spawnarg.

 

Why would that not work for you?

[Sotha 1909]

Uh?

 

You should be just be able create a new func_static, set its class to:

 

entityDef atdm:static_electric_light_lit_base

 

set it's "model" to "" (so it has none), and then attach whatever model you have as your model. Or simple replace the model spawnarg.

 

Why would that not work for you?

 

I cannot leave the model field empty. There must be something there, otherwise the change is not set in the entity. If I set "model -" I get a black box.

[Tels 278]

I cannot leave the model field empty. There must be something there, otherwise the change is not set in the entity. If I set "model -" I get a black box.

 

Ah. This is a bug in DR then (the model field can be empty for lights and you should be able to override this).

 

Also, setting "-" as a model is a non-standard way, which is supported by a few things, but not by lights. However, I think we might be easily add this.

 

In any event, if you write your entity defintion into a .def file, and include it in your FM, it should work:

 

entityDef myElectricLight
{
 "inherit" "atdm:static_electric_light_lit_base"
 "model"   ""
}

 

I guess we could also add such an entity, so it can attached to whatever conctraception the mapper builds.

 

Back to the "model" spawnarg, what kind of model are you using? Is it an func_static build from brushes? Or a regular model?

[Sotha 1909]

Back to the "model" spawnarg, what kind of model are you using? Is it an func_static build from brushes? Or a regular model?

 

Does it matter? If we had a source entity for electric lights the mapper can embed those into anything, models, func_statics. Heck, even AI's. (Wow, electric zombies! Now there's an idea free for someone..)

 

In my case I wanted to make a model into an electric light, but that model does not have a combo-entity.

 

Having an electric source means there is the possibility to do anything.