I'm trying to make an actor with a personnel shield attached. The shield itself would be not unlike the energy/bubble shield. The concept I'm working with however requires that the shield be invisible, or atleast very discreet (a 1 pixel thick bubble won't cut it). The closest thing I could think of was emitting invisible particles but in practice it crashed CC almost instantly. So any ideas?

attached?

Why don't you simply make it a shield and make the sprite invisible(pink).

invisible (completely pink) with atomgroups and a glow of the sheild? I don't know if atomgroups collide though (which is why you cant stand on dropships I think)

edit: bbbzzz234 it would not be able to be hit and thus would not be a shield at all, or in fact anything, the game calculates the area of a sprite by the pixels that are not pink/invisible.

Attached in reference to this specific actor.

And if the sprite's pink like the background then how would it collide?

Oh, I see, then make it a bunch of attached emitters, with VERY low rates of emmission.

Wat.

Emissions can't block bullets.

I think Robolee has the closest possible solution. In theory, if you made an atomgroup of the shield, and set AutoGenerate to 0, it would use your atomgroup without, y'know, actually having that visible sprite.

Resolution, Depth, DrawAfterParent, and Deepcheck, Could these not also be changed to help this? if its autogenerate = 0, would that mean it doesn't make the object, and thus it can't be collided with? perhaps make 2-sprites, one thats invisible, that would be on top, and one that is visible, thats under the invisible one? (so that you see the invisible layer, thus, you see through it, and the layer thats 'behind' it, can't be seen because its somehow masked?)

I know, covering something visible, with something invisible, shouldn't make it invisible, but I thought my 2-cents might actually be worth something. I'm probably wrong, but hey, whatever.

I think Robolee got it.
It would be really cool to make forcefields.

Resolution, Depth, and DeepCheck don't really have anything to do with what's being discussed at the moment. To be honest, I don't even really know what Resolution does.

However, DrawAfterParent *might* help, if you were going for a stacking method, but there's no real need to.

AutoGenerate just means that the game doesn't automatically generate an AtomGroup based on the sprite. An AtomGroup is what the game uses to determine collisions. Hence, if you make something that has AutoGenerate = 0, and no AtomGroup defined, it will just fall through terrain; it's like an MOSParticle without that single pixel.

If you assign a manual atomgroup, and offset it right, in theory, it should work. I don't know, and in fact I'll go test it now.

That doesn't work.

Capnbubs has already tried that once.

Aaw, that'd be so cool!

So I guess the only way to do it is have a thin bubble surrounding you, and that'd look retarded.

This I think helps more than anything else, although it would be extremely tedious to make, so correct me if my understanding of this is wrong.

By setting Autogenerate = 0, it doesn't base the materials/atomgroups by the sprites shape, but rather, the way a material file works (such as for a map).

Because you can't use a material layer as a sprite, you would have to define the shape and materials of the object, pixel by pixel, like making a material, as a matrix of text, or a text version of a bitmap. This would be an extremely large file-size, and an extremely long set of repeat code. once known how to do, it would be easy, but tedious, copy/paste, copy/paste, defining the X, Y, Depth, material, atomgroup, and soforth, one pixel at a time, in code, to define the shape, which is then masked by, an invisible sprite, of the same size.

so, theoreticaly you could use an invisble sprite, but you would have about 10 -12 lines of code per pixel, and surrounding an actor, or working as a shield, is between 40, and 100 pixels (10-12 * 40-100 = butthurt lines of code)

However, the advantage is, it could theoreticaly work like terrain, and projectiles could pierce the shield, to still hit whats behind it, with reduced velocity, at which point, you could re-generate each pixel. Unfortuneatly this would lag like mad because every frame it would try to create all of those pixels again, and maybe erase the old ones when it moves. (sort of like bunker modules that include MOSRotating or actors, only in reverse, including material/bunker modules, in an MOSRotating/AHuman, erasing and re-creating the bunker module every frame, lagging like mad, and erasing parts of the map.)



Am I at least going in the right direction with this?

I don't really think so.

The game automatically generates AtomGroups; everything has them. The only thing AutoGenerate changes is whether it, well, automatically generates.

Thus, if you had a way of "saving" atomgroups, you could load a sprite, copy the atomgroups, change the sprite, and then give it the old atomgroups. That would be easier, but, as it is, you'd have to manually position every pixel of the sprite, yes. It wouldn't perform any differently than a normal object, however.

Wait, wheres the delete post button?

My answer was already said.

Actually this is possible, in the old DS code(and maybe it's still there) there is a note about how when the copyof for the second engine is done, you still have to redo the AutoGenerate = 1, because otherwise you would have the new sprite with the old atomgroup. Use this effect?