nel-all
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nel] Getting NeL up and running.


From: Vincent Archer
Subject: Re: [Nel] Getting NeL up and running.
Date: 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: address@hidden

Nevrax France.                              Off on the yellow brick road we go!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]