Question: can we cast things?

Example: Say I just casted a ray to find an MO, and it found an MO. It just returns a more generic object to me, even if its actually, say, an AHuman. So then if I try to access something like Health, it just tells me it doesn't exist since it doesn't know its dealing with something that has Health.

I've run across this problem here and there, and it seems like casting would be handy. Like, you'd do returnedObject.ClassName == "AHuman" to check if its an AHuman, and if it is you could do retrievedHealth = ((AHuman)returnedObject).Heath or something. As it stands now though, this script sometimes doesn't know its ♥♥♥hole from a hole in the ground, and its a bit annoying.

Its possible the ray hits the actors gun first. Or you're not doing GetMOFromID to it or something. Look at this:
After that you can do self.target.Health or whatever.
Edit: I'm not sure if you actually meant this. Oh well.

I was hoping you'd assume I was smart enough to do all that. No, it still doesn't seem to know I'm dealing with an Actor. Which is weird, because doing IsActor() or looking at its ClassName tells me it is an actor. But I still can't access things like Health or inventory on the objects that raycasting give back. Same thing with objects that SwapNext/PrevInventory() functions give you.

It's not meant to return the entity. I'm pretty sure it returns a structure with information about the ray.

CastMORay gives you back an MOID, which you can then use with GetMOFromID to get a pointer to the actual object.

A nice trick, if the thing you're dealing with is still actively on the scene, is to just use the ID you get to search MovableMan.Actors for whatever you're looking for, because the pointer you get out of the Actors list is actually known by the script to be an actor. Same goes for the Particle and Item lists.

This doesn't help me though, since I'm actually dealing with SwapPrev/NextInventory(), which gives you pointers to objects that aren't currently in any active MO lists. So its either casting or bust.

I assumed you didn't do it because I've had it working that way. I could at least access self.target.Pos through that, I don't see why not others too. Functions too, but not actor specific ones.
Edit: You're right, the actor functions don't work. So what are you doing exactly? Adding stuff into actors in an actor's inventory?

Remember this? viewtopic.php?f=73&t=15056

Basically I'm doing what you suggested. Here's the general running of it:
Step one: If a dropship has something in its inventory, make a copy of that something using the appropriate Create method.
Step two: If that something is an actor, make copies of all the things in its inventory and add those to the inventory of the copy actor
Step three: Add the copied thing to the inventory of another drop ship

Stuff falls apart at step two though. When you retrieve the dropship inventory item in step one, you just get back a generic object. So then I can't use inventory functions on it to get its inventory for further copying if it has any. Furthermore, I can't copy over health, since that's an actor attribute.

Of course, all this would be averted if you could just take whatever you got out of the SwapInventory functions and put it back into an AddInventory function. But apparently inventory handling sucks.

Not only that, but incase no one had noticed, you can fly a dropship and open its doors and abduct stuff that totals over 18708967kg mass and still fly like it has nothing.

Scuttle the dropship while still having the doors open and even more
peculiar thing happens: All the cargo vanished!

Now instead of scuttling, close the doors. *CRASHH*
Suddenly all the stuff you just abducted were added to the inventory for real and only NOW they started affecting and overloaded the mass limit the ship could have handled.

I've already reported this to Data long ago and he's aware of it.
Just telling about it here incase it might have an impact on the script youre trying to make.

I did notice that no inventory stuff triggered until the doors closed. This explains it.

I've given up until further notice.