Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / NPC Selection/inheriting from dbObject

Author
Message
Troll Fiddler
19
Years of Service
User Offline
Joined: 19th Jan 2005
Location: Mayo, Ireland
Posted: 12th Oct 2005 14:30
Hi,

I have an NPC class which, amongst many other things, constructs a 3D model from an ordinary X file. I can select the model on screen using dbPickObject(). However I need to relate the picked object to the NPC class that it is in, so that I can call other methods like the dialogue etc. Is there some way to do this (find the enclosing class for an object)?

The ideal thing would be to inherit from whatever the base dbObject class is, so that I could have all the object commands available in the SDK plus my own methods to call. I guess this isn't possible?

One idea I had was to map the picked object number to an instance of the NPC class using one of the collection classes like Map. But this seems a klutzy and long winded way of doing it, and introduces complexity and possibly hard to find typos/inconsistency bugs in the mapping.

Appreciate any ideas anyone might have about this, or alternate methods to the one I'm trying for NPCs.

Thanks a lot,

T.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th Oct 2005 15:26
Your assumption is that DarkSDK is OO behind the scenes - it isn't, so there is nothing there to derive you class from.

In the framework I've put together (a little more advanced now than the one I posted back in may) I've done exactly what you said.

I have a BasicObject class that handles all of the allocation/deallocation of the object ID, and storing/removal of the ID to object address within a hash_map (a little faster than map, but unordered) - Once that base class was tested and debugged, I just inherit from it and don't worry about the internals unless I need access. I haven't used the dbPickObject function yet, but that is the kind of thig I was thinking of when I implemented this class.

For free Plug-ins and source code http://www.matrix1.demon.co.uk
Troll Fiddler
19
Years of Service
User Offline
Joined: 19th Jan 2005
Location: Mayo, Ireland
Posted: 12th Oct 2005 15:45
Damn! Oh well, thanks Ian. Looks like the long way is the only way to go then. Better get coding that teeeedious stuff. Ho hum.

Thanks bud,

T.
Troll Fiddler
19
Years of Service
User Offline
Joined: 19th Jan 2005
Location: Mayo, Ireland
Posted: 12th Oct 2005 18:01 Edited at: 12th Oct 2005 18:03
Been thinking a bit and have come up with the following simple idea which seems to be working.

1)Create a factory object that produces NPC instances based on a static int that is incremented for each new NPC.
2)Store the int in an ordinary field in each NPC object. Use that int for everything to do with the NPC, such as object numbers for models, array/list indices for storage, index into dialogues, quests etc etc.

So, if dbPickObject returns (say) a 2, then you know you need the NPC object at index 2 of your NPC array (or whatever), dialogue index 2, quests indexed for character 2, blah de blah.
Plenty of scope for automating things based on a unique ID, as long one makes sure their other factories for landscape blocks and so on don't generate numbers in the same part of the domain.

Let you know how it works out when the game gets more complicated than it is at the moment

T.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 13th Oct 2005 22:55
That's basically the right idea, except that in some instances, DGSDK suffers from slowdown when your numbers get too high. I use this class for objects, images, lights etc to avoid this:



If you check it, you'll see that any freed numbers are pushed onto a stack, and are reused whenever possible. New numbers are only allocated when the stack is empty.

For free Plug-ins and source code http://www.matrix1.demon.co.uk
Troll Fiddler
19
Years of Service
User Offline
Joined: 19th Jan 2005
Location: Mayo, Ireland
Posted: 14th Oct 2005 13:57 Edited at: 14th Oct 2005 14:04
Thanks for that insight Ian. I've used thread pooling and object pooling, but this is the first time I've had to use "number pooling". The vagaries of SDKs eh?

<edit>I assume this is to do with the creating/deleting issue and not just a generic "high numbers" feature?</edit>
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Oct 2005 14:58
Nope - it *is* the generic high numbers feature. For some reason, lower numbers are dealt with faster than high numbers, and this would appear using your system only after a lot of continuous play.

For free Plug-ins and source code http://www.matrix1.demon.co.uk
Troll Fiddler
19
Years of Service
User Offline
Joined: 19th Jan 2005
Location: Mayo, Ireland
Posted: 16th Oct 2005 12:47
Stranger and stranger. I can't imagine a reason for that, even if the objects were kept in some collection or another surely the SDK wouldn't stuff object number 20,000 right at the back and fill in all intervening places with nulls or whatever? I mean, if you only had two objects, object number 1 and object number 20,000 would you still have the problem?

T.

Login to post a reply

Server time is: 2024-04-20 11:33:09
Your offset time is: 2024-04-20 11:33:09