[Nel] Getting NeL up and running.

Tue, 27 Feb 2001 18:00:05 +0100

According to Leighton Haynes:
+>     Most of my 'fixes' aren't really, they address the symptoms rather
+>     than the cause, though I don't think I've broken anything major 
+>     with them ;) If anyone wants to give me some hints on what could
+>     be causing them, please do. 
+
+Well, we don't have hints, because, as you may surmise, these do not
+occur here.
+
+>           I gather the point of the Callback function is so that the 
+>           client which has loaded the Config file can become aware 
+>           of any changes to the parameters in the file, the time_service
+>           doesn't appear to set any callbacks for this though. *shrug*
+
+That's exactly what it's supposed to be, yes. So, either the callbacks
+are set incorrectly, or they are called while they should not be.
+
+>         the client was exiting with a message in the logfile about 
+>           being unable to load file "data/". Managed to eventually track
+>           it down to some of the texture loading code in 
+>           code/nel/src/3d/landscape.cpp. The loading of the diffuse
+>           texturemap doesn't do a check for textName == "" though
+>           the loading of the alpha texture map does. Haven't worked 
+>           out yet why it's decided that the textName is "" (it's too
+>           late ;)). I modified the code to do a test for textName == ""
+>           and made it default to loading the CTextureCross texture.
+
+That's the strange part. It should not be loading an empty file name
+at all. I suppose the check doesn't hurt either, so we'll look at
+integrating it in future commits.
+
+>     As some other comments - processes are defaulting under linux to
+>     some (IMHO) really ugly behaviour of 'fork'ing another process,
+>     the sole purpose of this appears to be to let them run in the 
+>     background. I don't see any really good reason for doing this,
+
+Well, there is one. Basically, if you look at these processes, you'll
+see they first do a set of initialisations, then fork. The whole
+fork-and-exit sequence is used to guarantee that service N+1 isn't
+started before service N has at least performed the minimum required
+initialisations.
+
+>     since it can be quite easily achieved by 'nohup'ing it and 
+>     shoving an '&' on the end of the line. Am I missing something?
+
+You could too, but you'd have to slide in a "reasonable" sleep N in
+the shell startup script. With reasonable varying a lot.
+
+>     (It makes it a bugger to debug, I can't run 'strace' on them effectively
+>     etc etc. Obviously, i just commented the code out of my version ;)
+>     Perhaps a commandline switch would be more appropriate?)
+
+That'll be added, yes.
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+