PranQster

Ok, thanks, I'll try that. Ok, I'll try rebuilding them with a larger grid size. If that doesn't work, I'll make some other simple hangers.

I made a nail to hang a key on starting with a small brush and using the clipper tool to trim it down and shape it. I applied 'iron_rough' for the texture. In DR it looks how I want, but in-game some of its faces are transparent and it shows this in the shadow too. I tried reapplying the texture to the individual faces, but that didn't help. Took a screenshot. Any suggestions? Edit: I know my wall textures are not aligned yet

Fixed. Please close or delete this topic.

Fixed, please close or delete this topic.

Thanks. Chalk that one up to my DR newbiness. I figured since I was able to do most of the basics in the DR tutorial, and in fact had TDM textures available, and was able to dmap my map, that all was alright. But the lack of common textures clued me in to the fact that doom3 textures were missing.

Yeah, my whole problem was that I did not have any such 'textures/common/ladder'... after changing the game engine path in the DR preferences, I now do Another annoying problem I had before is now fixed because of this. I had trouble previously with creating a player start point when nothing was selected. It had been requiring me to assign player start to a brush. That is now fixed and all is normal.

Nevermind. Most things were working fine, but I had not edited the DR Preferences>Game settings. It had the Engine Path set to the default '/usr/local/games/doom3/', but I have doom3 installed in '/home/myusername/apps/games/doom3/', so I changed that. 'Mod (fs_game)' had been set to 'darkmod', but 'Mod Base' was blank. I set that to 'darkmod' too. I now have a massive amount of textures available which were not there before.

I only find /textures/common/tdm_nodrawsolid_climbable. If I apply that to a brush surrounding a ladder, it is not climbable. I do not stick to it. Any pointers, please?

LOL, that is funny! Hmmm... I kind of like the idea of having the arrows stick to the player, as long as the player has a way of frobbing them

Very funny. Did that arrow do health damage, and/or is it possible that it is stuck in the players hood, just above their head?

Ah, ok. LOL, I keep forgetting that the Linux world revolves around 'buntu.

LOL I actually used a stucco texture on the diving board, but it looks like wood in the light. I wouldn't want the player getting splinters from the wood. Someday I plan on finding out how to make that diving board bend as the player walks to the end of it. Yeah, I should stop tinkering so much with the tutorial and keep this stuff in another build. I'll do the rest of the tutorial more or less as Fidcal intended, lol.

I'm starting to get a hang of the basics. I am following the tutorial, but I got a bit carried away with that part for creating a pool of water.

That would be nice. My distro, Mandriva, uses .rpm which install directly into /usr. Recent fedora and suse .rpm files seem to be doing the same, but some older versions preferred to install into /usr/local or /opt. In any case, if I use an .rpm packaged for either fedora or suse, I am in the habit of using 'rpm2cpio filename.rpm | cpio -idv' to extract the .rpm. I can then manually move the contents to the appropriate path. So to make a long story short... any .rpm will do

Recompiled fresh svn code after modifying the configure script. Now it shows the proper version.

The tutorial stated to DEselect all before creating a player start position. If I do that I get an error stating that no brush is selected. This forces me to create a small brush for player start and tuck it out of the way where it can't be seen or walked over by the player. This happened in DR 1.2.0 and also in 1.3.0, both were compiled from svn source. uname -a Linux mjollnir 2.6.33.4-server-1mnb #1 SMP Sat May 15 14:20:03 UTC 2010 i686 i686 i386 GNU/Linux

Thanks Fidcal

I'm going to start over anyway and reacquire it from svn and build it totally fresh. Since I did start this last night and finished it today, after system updates. Edit: Ok, I won't worry about it. I'll probably end up starting from scratch and I'll edit the version in the configure script when I do.

Maybe I am actually running 1.3.0, but because of the configure script it got identified as 1.2.3 and the same thing happened with version 1.2.0 showing as 1.1.1...? Edit: While you're at it, any idea why when I go to create a player start position I am required to assign it to a brush? See my other tutorial help request post.

the version.h included in what I built also says 1.3.0 in 'configure' there is this: # Identity of this package. PACKAGE_NAME='darkradiant' PACKAGE_TARNAME='darkradiant' PACKAGE_VERSION='1.2.3' PACKAGE_STRING='darkradiant 1.2.3' PACKAGE_BUGREPORT='' PACKAGE_URL=''

What the??? ROFL it's like when I ended up with 1.1.1 AFTER you had released 1.2.0! I got it from SVN here (last night): svn checkout https://darkradiant....nk/darkradiant/ darkradiant Edit: following the https:/ protocol: /darkradiant.svn.sourceforge.net/svnroot/darkradiant/trunk/darkradiant/

Success! DR 1.2.3 installed and running fine

Though I had all required dependencies installed, I was getting that error when doing ./configure. After system updates, including new kernel, new nvidia drivers and mesa, followed by a reboot, all is fixed. DR is compiling now. Will check for the other problems after compilation. Yep! All fixed. DR 1.2.3 is installed and running. The problem with adding a player start position is resolved. Now there is no need for using a brush. I was wrong. For some reason I still need to attach the plater start position to a brush. Any ideas why?

Unfortunately, that did not work. I uninstalled and reinstalled libglew-devel-1.5.2-1mdv2010.1.i586.rpm. Then I tried reinstalling libglew1.5-1.5.2-1mdv2010.1.i586.rpm. Neither made a difference Edit: Fixed! I applied a system update which, among 215 packages, included mesa and new nvidia drivers. After rebooting with a new kernel, DR is now compiling. Go figure.

I previously compiled DR in March, but the current source from svn gives the following when running './configure' checking for GLIB... yes checking for GTK... yes checking for GTKGLEXT... yes checking for XML... yes checking GL/glew.h usability... yes checking GL/glew.h presence... yes checking for GL/glew.h... yes checking for main in -lGLEW... yeschecking for main in -lGL... no configure: error: GL library not found. The devel dependencies are all installed. If it can find GLEW but not GL, then what might be the problem. I have checked /usr/include and found that gl.h is in /usr/include/GL (and so is GL.h). gl.h also exists in /usr/include/nvidia-current. I have tried both linking and then copying them directly to /usr/include, to no avail. I still get the GL library not found error