Everyone's been saying you can't attatch actors, but everyone also used to say that you couldn't make an actor into a round, and in the same build they said it couldn't be done, it was done.

Because of this, I got to thinking, and I think I have a possible solution.

step 1: Make an actor
Step 2: make an MOSR, copy of said actor (can be done, the same way a Round, copy of actor does)
Step 3: Make an attatchable MOSR, copy of, the MOSR copy of actor'
step 4, attatch object.
So, it requires you to make 2 more objects after the actor, just to make it work,




Because you cant directly attach an actor, it has to be an MOSR,
BUT, an MOSR, can be a copy of an actor...


I'd do it myself, but I have NEVER made a working actor, and B21 is just confusing me.
that and i've never used anything that attaches.

someone, test this and post the result, if this works, it will 'revolutionize the modding community' or something.

I... Don't think it'll work, since its like saying a rabbit is a jellyfish. To my understanding the round just says what the gun shoots and what the gun ejects. The round doesn't carry any code from the actor at all. And making a MORotating a copy of an Actor, I don't think the game would understand why a MOSRotating would have some of the code the Actor has... What is AimDistance to a MOSRotating? Etc.

but thats just it, If you add in the round version of an actor, the set AI script (It was there in other builds) you could make them walk, or shoot, or both. In fact, if you give an actor a gun, and set the actor as a round, the actor will shoot at the opposite team, thats how homing missiles worked.

and you can make an object that's a copy of a round, so yeah, you could.
the actor keeps all its code as an actor.


Setting an object of 1 type of instance, then copying it as a new type, Doesn't remove any code, it just Adds it.

IE if you make an actor with all the actor code, then make a round copyof actor, and IN the round, add screen effects, it will add the screen effect to the actor, which will act like an actor, that you can't switch to, and still function.

Also, if in the round, you add something like mass = 0.01 then the entire actor's weight will change to 0.01 over-all although when it gibs its weight goes back.

this is because everything in the new object that you add, if the variable already existed, it over-writes it, in this particular instance.


I made a gun that fired out skulls, that explode into skeletons holding blunderbusses, that would shoot at the AI, and me, And eachother (half on each team) back it B18-20

I never released it because it was retarded.

Also, if this logic holds true, it will work in every build that has attachable objects. (with possible exceptions)

Why can't you just test it with a base.rte actor?

because In b21 the few things that changed really threw me off for some reason, and I tried and the way it got changed nolonger makes sense to me. It might actually work in B20 and not 21, or it might work the other way around, but I am fairly certain that unless data goes out of the way, however it is in B21 will stay...

the CopyOf code works the same in both builds. so you can test it yourself.
however, ill go test it now. brb.

edit: no,, thats silly. as you cannot use copyof in-between classes. ie if you say "CopyOf = Coalition Heavy" itll look for a MOSR that called "Coalition Heavy" which will obviously not exist. => error.
maybe hard copying the code.. meh, i dont care enough to test that yet.

P-P-P-PROTIP: AddAmmo = Round just means that the gun shoots that type of particle! Doesn't mean it's making a bullet with the qualities of that actor! Really!

AddAmmo = Round CopyOf = AHuman.
Means that your magazine is full of rounds that happen to be AHumans. Doesn't mean you must made bullets into actors; it means your actor is a bullet.

There's no code you can copy into an MOSR to make it the same as an actor.

AddAmmo = MOSRotating CopyOf = Soldier Heavy
Have fun with that. Because it doesn't WORK.

Oh and SUPER DUPER BONUS HINT: You always make excuses for coming up with ideas and not testing them yourself. Next time just test them yourself so you can find out that they don't work and stop making the rest of us read horribly formatted five paragraph useless posts.

Not what I ment.



now do you get what I was getting at.
Actor = round
round = mosrotating
mosrotating = attachable


THATS what I meant

--EDIT--
To clarify,
you CAN NOT tell it MOSR Copy of Actor,
you can however say MOSR copy of something else,
and that something else, can be a copy of an actor, such as a bullet.

you have to
A)define the actor
B) define a NEW object, as a copy of the actor
C) Reffer to B) as an MOSR for use as an attachable

you CAN NOT DIRECTLY REFER TO THE ACTOR BUT A NON-ACTOR CLASS COPY OF

Except that still doesn't work and doesn't even make sense.

how does it not make sense?

its a bunch of copyofs

thats it

A = B
B = C
and C = D
because A =/= D, but through that method, A = D, but only through transitive property.

you have to have the redundan't step because not every class can be a copyof actor, and MOSR can't be a copy of everything, however, you need an object that can be either, to be an in-between step.

It still makes no sense, you can't make something in a particular class a copy of something in another class. Attachables, AHumans, MOSRotatings, whatever, they're all distinct things, and can only be copies of other instances of themselves.

And if I'm wrong about that, prove it. And in saying that, I'm not trying to be condescending, I'm genuinely interested if that is something do-able, and would like to see a demonstration.

My brain:

1) Round = AHuman (Platypus = Jellyfish)
2) MOSRotating = Round = AHuman (Rock = Platypus = Jellyfish)
3) Attachable = MOSRotating = Round = AHuman (Non-living = Rock = Platypus = Jellyfish)

So...

Non-living = Rock != Platypus != Jellyfish
aka
Attachable can be a MOSRotating but cannot be a Round and the Round cannot be a AHuman!

Rounds only tell what the gun shoots, but in this case you're trying to say a Round is an actor. MOSRotatings well... Are "inanimate" objects that can rotate, but they are not a round or an actor, as they only can rotate and smash stuff in. Attachables can be MOSRotatings though.

The compiler that loads the .rte's will see the code from the AHuman but expects code from a Round type and go WTFISTHIS and stop... Unless the MOSRotating can use the unique codes in the Round and Actor class, as well as the Round being able to use the ones in the Actor class... Grah I'm reminded of my programming class...

There are instances where you can mix CopyOfs, but this is not one of them, as this was tried and failed repeatedly back when we originally found the way to cross the CopyOf with lesser entities (it redoes all the variable assignments, it doesn't work if you do a CopyOf referencing something with more arguments than whatever you are copying it to. That's the problem here.

tl;dr :
MOSRotating = CopyOf = AHuman will screw up as soon as the game tries to assign a value from the AHuman type that does not exist for MOSRotatings.

Also declaring the round first what?

EDIT: Why the hell don't YOU test these ideas rather than posting them here?

Should work, eh?

Here, I'll rafb it so you don't even have to fix the tabs!

http://rafb.net/p/HNSO3387.html

My tabbing might be a bit off but I'm sure you can fix that.

HOW CAN YOU FORGET HOW TO NAME INSTANCES?[/amazement]
wow, i actually learned something from this topic. i did not know you can attach MOSRs.
also grif has summed it up as i tried to, but much better.
basically, if you try and code it how you say you think we can, you get an error, something about it NOT EXISTING.
MOSR "name" can be something completely different from AHuman "name", they are mutually exclusive, and will not copy. and hard copying the code fails miserably. all that stuff about mismatched properties.
so basically no, this is not possible.