nbohr1more

I have a P4 3.0ghz and a HD4650 AGP (so kinda lowish...) Caveats: But I am no expert ghoster and I find every FM challenging and fun because of my lack of skills My wife has a tendency to limit my CPU time... (copied from Jesps beta... ) (cant resist the chance to see this in action BC...)

Just wanted to make sure. I have a bad habit of writing twisty sentences and forgetting to include enough context .... I hope you get it running.

I would completely clear out the TDM directory and then just run the latest updater before you decide to blow out everything (reload, FFR, etc). (make sure that no conflicting Mods are in the Doom 3 directory as well). Just to clarify, I was saying to copy the DevIL.dll from TD to TDM then delete TD.

Yes. If you want to play the old TD then you'd also need to put the DevIL.dll into the Doom 3 folder (and create a description.txt with a different name...). Once you've got your precious DevIL.dll I'd recommend deleting the old DM demo unless you can somehow avoid confusion between that and TDM...

Download the old Thief's Den demo, it has a current version of DevIL.dll: http://www.fidcal.com/darkuser/missions/thiefs_den_v1.0.exe Also, clear "Trapped!" out of your currentfm file.

How about your DevIL.dll file? Do you have the latest version in place? I forgot what it's called but I believe there's a config file that specifies that a mission is installed, perhaps that's the problem? Other than that I can only guess that something like security software is preventing either updates or the access to the scripts??? Edit: currentfm.txt ?

Yeah... It makes the entities "think" about their "distance to you" so it will only be beneficial if that thinking takes less processor than the geometry that is being hidden. (works better when there is more "stuff" to hide.). The dist_check_period is where the bug is, it doesn't work well with fractions of a second. I think the default is one second so the bug may not be a problem there? (damn Bold-ing can't un-bold...)

Melan had a similar problem not long ago. He deleted both the gamex86.dll and DoomConfig.cfg. (Cant get this to un-bold ... ) Anyway. I would make sure that your autoexec.cfg, DoomCfg.cfg and gamex86.dll files are gone along with any saved games (not compatible between updates.). I'm sure a brighter bulb will come along and give you more options and better advice.

:laugh: (A prelude to what will happen when we start replacing actors with robots )

Cool!

I don't think that: lod_hide_probability - 1 hide_distance - 750 will work in 1.02... XXXXXXXXXXXXXXXXXXXX You will need to use: editor_float hide_distance - 750 (OK... the "editor_float", etc... part is probably redundant to what happens in TDM and Dark Radiant internally... So editor_float hide_distance = hide_distance... if hide probability is not in 1.02 then it probably ignores it...)

Oh yeah, lights cannot currently be culled via LOD. Not sure if that is just a lot of extra work or impossible (requires Source Code?). Probably just very difficult because of all the other custom SDK stuff Tels put into the lighting system. You'd have to treat every LOD light like an extinguishable candle?

There may be trade-offs with that approach Biker because as soon as you turn around to look at the objects that were out of view the engine will have to recompute silhouettes for anything that casts shadows and the engine will get hit with a bunch of draw calls. But I suppose for far away stuff that is behind you it should yield some benefit (meaning it will probably take some tweaking to find the optimal "make me invisible" distances). I would caution that this type of LOD use should not be used as a crutch for folks who are bad at working with visportals (for any newbs reading this... ) but it may help bulldozer some geometry away when you want it gone. Actually NHAT was what inspired me to investigate Object LOD in Doom 3. I always figured that Doom 3 had an Object LOD system like every other engine so I went running around Doom3world to see if there were any tricks to help it run better. I found out the Doom 3 does not have object LOD at all and there were serious questions about whether it could be made to work because you'd have to build it with what's available in the external SDK (instead of the Renderer). (When I posted the thread here I still couldn't believe that Doom 3 doesn't have a native LOD solution...) I'm not sure Mortem Desino was aware that you could specify distance checks to make entities disappear when he worked on NHAT 3. (Given that it's kinda broken I don't think that it's a widely used feature...). Edit (Late redundant post )

I don't see a bloom cvar but I know that Denton's mod has been known to cause this type of trouble due to Bloom. You could try: r_bloom "0" or r_bloom "3" You could also drop in an updated HDR pk4 from the HDR thread at Doom3world... http://www.doom3world.org/phpbb2/viewtopic.php?f=56&t=22822

Looks great! Any hint of how many more of that quality you have cooking Serpentine? (That mesh looks like it took "awhile" so I wouldn't be surprised if this is the only one with that much goodness to it... )

Those arguments should work for your requirements Biker... but the performance benefits may be (?) inconsistent due to the "typo bug" in 1.02 (they should also work in 1.03 AFAIK).

@Aida Yes, I've brought it up a few times... These are the Spawn Arguments: "hide_distance" "If set greater than zero, this entity will hide itself when it is greater than this distance from the player. WARNING: Performance can be impacted if too many entities in a map use this feature." "dist_check_period" "If hide_distance is used, this sets the interval between distance checks, in seconds. Default is 0.5 (500 milliseconds)." "dist_check_xy" "If true, the LOD distance check is only done orthogonal to gravity, i.e., vertical distances aren't counted in it. Useful for things like rain clouds turning off/on." ...that's for the system that's currently available in 1.02 (options = either visible or invisible). Tels made an example entity definition and passed it along to Fidcal from what I recall. It's also broken due to a typo in the distance check period? (causes FPS to fluctuate wildly...). More details in this thread: http://modetwo.net/d...round-zero-mod/ (Try to ignore some of my raving and ranting ) (edited to exclude redundant internal syntax)

Have you guys been in contact with these folks? Doom 3 Mega-Texture Mod V2 From what I can tell you might need ETQW to author the megatexture but I was reading about some other methods that seemed to do away with that requirement (reading comprehension was low as usual )

So "lightFalloffImage" is always Z bound? (Otherwise as a layman I would say that the material definition looks just like combining two XY textures.... There's nothing else that seems to specify "This texture get's this direction while this one gets the other...").

I get it now! The makeIntensity keyword says "Shine this bright this far away from the light" The map keyword says "You can go this far left, right, forward, backward"

Already stuck (it was hard to avoid the pun from your username...):

lights/aa_1_sky1 { lightFalloffImage makeIntensity( gfx/lights/1_sky1_z.tga ) { forceHighQuality map gfx/lights/1_sky1_xy.tga red Parm0 * 2 green Parm1 * 2 blue Parm2 * 2 zeroClamp } } so it's just a material definition eh...? I am returning to the idea that this may not be so bad...

Light Texture tutorial? Got my hands a little dirty and started writing my own http://wiki.thedarkmod.com/index.php?title=Light_Textures_and_Falloff_Images

@plasticman I think I over-estimated my comprehension of this one. I suspect that to do this you would need to make your own vpf using the ones in the Strombine pk4 as a template? Is this technique possible with what is available in Dark Radiant? Would you be willing to create a wiki article? (I will get off my duff and take another peek tonight to see if I can stretch my noodle a little. )