Topic: Imposter ID handling (Read 1611 times)

xat · « **on:** December 03, 2010, 02:33:13 PM »

I need to have 12 sets of imposters, each set having up to 130 imposters(only 5 of the sets at a time could do this, while the total imposters count won't be higher than 600)

-Every imposter needs to be movable by it's individual imposter ID.

So, what would be the most framerate-friendly way of doing this?

I was thinking of using an array in a script to keep track of every indidivual imposter loaction, that way I just need to refer to their imposter ID's for individual movements, then update the array with this info.

Would it be possible to move imposters individually through an object, or do I have to use a script to do this? I heard linking objects to the script is system-straining, but I'm not sure using objects is even a feasible alternative because it looks like there's no way to select an individual imposter if it's not an individual "imposter" object.

replicatokid · « **Reply #1 on:** December 03, 2010, 07:33:42 PM »

I have never used the 'imposter object.' But I have used imposters a good bit in scripting, and I'd say that scripting is probably going to be your best bet. I've done some of the stuff you mention here, including using an array to store imposter locations and moving the imposters around.

I couldn't say whether or not you could use an object to move an imposter created using the 'Imposter object' but off the top of my head I don't think it would be easily possible.

Good luck.

xat · « **Reply #2 on:** December 06, 2010, 09:05:13 AM »

Having not found any imposter ID specifying options in any of the objects, it's a simple conclusion that you can only do this with scripts.

..so is there any way to lessen the strain when working with scripts? like, if the script were to be only called when needed by an eventontimer/input object?

Oh- I know- have 2 scripts, and only one of them is connected to all the imposters while the first one is only connceted to another script and runs all the time.

..would only the script that created the imposters be the one linked to them?

This is different from object linking to scripts, because the script created this and you could assume all scripts are connected to them..?

Mike Hense · « **Reply #3 on:** December 06, 2010, 09:11:20 AM »

Quote

I was thinking of using an array in a script to keep track of every indidivual imposter loaction, that way I just need to refer to their imposter ID's for individual movements

i think you're gonna find that that's the way to go...

be sure to comment your script code and then i you have any problems, you'll be able to post the code and i'm sure someone will help resolve whatever you need done...

--Mike

xat · « **Reply #4 on:** December 06, 2010, 01:54:17 PM »

One thing I wanted to know was how imposters affect the scripts- are all scripts linked to script-created imposters?

I'm concerned with the best framerate-helping way to do things, but don't know if it'd help to do something like have 2 scripts, 1 processes info, then it tells another script what to do with objects, and the object-controlling script doesn't run until it's called by the first script, which isn't linked to anything but the second script.

This way it'd help the framerate by not involving scripts linked with objects, right?

But I'm not sure how script-created imposters would work in this. Most of my objects are imposters, so I should just use one script if every script is linked to script-created imposters.

Mike Hense · « **Reply #5 on:** December 07, 2010, 08:56:19 AM »

i would suggest making everything as simple as possible...

sounds obvious, right...

imposters and arrays can become logic nightmares if you get too "creative" and have the logic distributed all over the place... a single script should be fine for a single functional group...

don't worry about framerate issues until they become apparent... RAD will do a good job of maintaining a steady framerate...

one thing to keep in mind though, since you're working with arrays is to avoid long loops... servicing every element in an array may not be necessary at each main loop iteration... remember, it's happening close to 60 times a second... take care of one... or ten at a time...

good luck...

--Mike

xat · « **Reply #6 on:** December 07, 2010, 09:04:15 AM »

the array is just for data storage, and using it would just involve changing a few values or checking a few specific array variables at a time.

..or are you saying I have to loop through the entire array just to check one part of it?
I was sure you could specify the array variables you want without looping through it all, right?

Mike Hense · « **Reply #7 on:** December 07, 2010, 09:35:49 AM »

i used the word array in it's broadest context... i didn't mean to suggest that you'd be locked into using an array... you could use a class based implementation as well, for example...

the thing is (i thought it was) how to effectively IDentify each imposter when it comes time to update (move, postition, hide show, make it squeak) it or whatever... most people will use a circular, round robin repeating loop methodology in which a counter is incremented and the member whose ID (or whatever) is equal to the counter at that time is the subject element for the update...

this outside-in perspective has its drawbacks, but it is relatively simple to envision and to lay down in code... i'd prefer a different approach, where each imposter is a member of a class which is aware of events thrown up by the simulation, and would update itself upon such...

unfortunately, 3DRAD scripting isn't really suited to this sorta stuff (i don't think)... and you'd have to go outside of the box to write the heart of your imposter logic (a c++ dll maybe) in another language that could be called from 3DRAD...

to get back on topic...

Quote

are you saying I have to loop through the entire array just to check one part of it?

that depends on how you set up your checking... i wrote up something a while back that had a lot of imposter trees... and i wanted to give each one collision with the player... i used one collider and positioned it at the location of the nearest imposter tree so that it would appear that each tree was a solid collision body...

in order to do this, i had to loop around and get each imposters ID in order to have something to pass to iObjectLocation() so i could do a check to see which one was closest and position the collider there (now, while this was fine for a few hundred trees, a forest might slow things down to a crawl)...

and i wound up not doing all of em in a single loop...

unless you could come up with another way to ID a single imposter, this is the sort of stuff i was saying you have to watch out for...

--Mike

This forum is now archived!

News:

Author Topic: Imposter ID handling (Read 1611 times)

xat

replicatokid

xat

Mike Hense

xat

Mike Hense

xat

Mike Hense