As one would expect from the subject, I am a beginner in Panda3d.
I still didn’t get why should a World class (ancestor to DirectObject) be created and then instantiated before calling run().
In fact I couldn’t find an answer to it in the manual or by examining the examples.
Well… its just convenience, actually. Not really necessary or so. You can do it differently, if you need. But, if your game keeps getting bigger and bigger, it might be a very good idea to organize everything into classes instead of having just one huge file.
Ok… But why the World class has DirectObject as its ancestor? I’ve seen no great advantages about that…
DirectObject is a class where you can add event hooks to. If you have a class inheriting from DirectObject, you have the advantage of being able to do self.accept (the accept() function is provided by the DirectObject) to listen for events.
Of course, you could just create an instance of DirectObject, or use plain messenger.accept, but many users find this more convenient.
Ok, thanks a lot!
DirectObject is a stupid class and you just not inherit from it. It just pollutes your name space.
If you want to add hooks just use base.accept() or messenger.accept() or what ever. I find DirectObject highly messy thing that should not exist.
Instead just create class Word or class Game what ever with out the DirectObject crutch. DirectObject is not a new style class so it might byte you with the newstyle/old style python classes.
Meh, it’s just a style preference. If you’re used to the highly object-oriented coding style in which everything inherits from a single common class, then DirectObject can be that class. If you prefer a looser, more ad-hoc inheritance hierarchy, there’s nothing compelling you to use DirectObject.
David
I actually like to inherit from DirectObject. I can create classes for specific purposes, like a editor. I can add as many accepts as i want, if i want to disable the editor i just do self.ignoreAll(). Doing this using messenger.accept is way more code (and error prone).
Oh, by the way, is there a way to ‘pause’ the DirectObject? As in ignore all events, but remember them somehow, so if you call something like a ‘resume’ all your previous events will be accepted again? This would be really useful, since I don’t want my player to be able to move when in the pause menu etc.
Wouldn’t take long to implement I guess, is it OK if I implemented such a thing?
…unless something like this already exists, of course.
I wouldn’t attempt to extend DirectObject to achieve that. Just in case I have many object receiving the same event, then I would have to iterate through those objects just to make them deaf. That feels a little painful and surely can corrupt the development time.
There is messenger.whoAccepts which returns all objects accepting the named event, but still that sounds like a lot of work. It just doesn’t worth the time.
So far, I’ve used to implement events redirection, ie. all events aren’t removed from the listener’s events list. It happens only by altering the generated events names temporarily. It takes advantage of button thrower’s prefix for temporary alteration, so upon states switch, I just need to set the prefix accordingly, and that costs me only 1 code line.
From my IDE :
IDE_BTnode=base.buttonThrowers[0].node()
def IDE_setMode(mode):
IDE_BTnode.setPrefix(mode+IDE_MODE_SUFFIX)Then I just need to call IDE_setMode(currentMode) and that’s it. Fire and forget ! 
Yeah, you should inherit from DirectObject, because the way DirectObject and Messenger work is a little bit surprising and can trip you up if you use base.accept(…) instead of self.accept(…). In short, if you keep using base.accept(…) then each time you register a function with an event it will overwrite any previous function registered with that same event, you can never register two functions to the same event, whereas if you use self.accept(…) you can register many functions to the same event as long as those functions belong to different objects. Each object-instance can only register once to each event, which surprised me. See this thread.