Changing the direction of laser beams?

3Dash

Hello, I'm currently working on a puzzle and I am confused on how I would get this to work, similar to the laser beams in Portal 2, you have a cube and you can redirect the laser beam direction across a room like this



Here is a layout of what I am aiming to do, if I had a laser beam going towards a static mesh, once it comes in contact with it how could I direct it to continue out of another side which would have a hole in it?



Thanks in advance

ambershee

You don't 'continue' it. You spawn another beam for each line.

3Dash

Okay but how would I stop a beam when it hits a box? is it just the case of adding a collision or something?

ambershee

Set the end point of the beam to where a trace collides with the box.

3Dash

Still having problems, what I have done is created a beam effect in cascade, and added a collision on there, which seems to have worked well as it stops when it hits a static mesh.

But for the puzzle the boxes won't be in a set place, the player will need to move them to get it in line with the box to connect the laser beam, my question is how will I get my particle system to suddenly appear when a box is in the correct position?

In this picture, 1 will connect with 2, and when box 3 is in line with 2 a beam should appear connecting box 2 and 3 can this be done in kismet?

r4ptur3

just working this out in my head, I would do the following:

attach the beam to 1
toggle the beam off (so the player can not see it)
set up a trace between 1 and 2
if the trace from 1 hits 2, toggle the beam on

if you apply this logic to each box (you will need to set up traces between all boxes) the beam will appear to bounce from box to box when they see eachother. This will not allow the beam travel at odd angles -- it'll only work in the direction of the trace.

just a thought -- why don't you have predefined spots where the cubes need to land, like in your diagram? If the spots are predefined it'll make the beam part so much easier. The player could still push them wherever they want (creating the illusion of freedom) but they only really work in a particular place.

Vailias

one good way to do this is to define the beam as a weapon type, similar to the shock rifle main fire but with its own damage type..
Your emitter has one of these weapons and is firing constantly.
The blocks are their own subclass of pawn. They each have at least one of the laser beam weapons attached also.
In their TakeDamage function they need to check for what kind of damage they're taking. If its the same type as the laser beam, they then fire their own laser(s) in the proper direction.
You can get the hit direction in the take damage function also, and use that for your calculations on firing the new beam.

You'll likely need to get your hands dirty with actual code to make this work well.

You might be able to hack up something in kismet, but I don't know that its truly going to work in the manner that portal did.

ambershee

@Vailias - not to be rude, but that sounds like a really bad way of doing it. It is not impossible to do this in kismet, but I would almost certainly write this in code.

You need two classes:
One is an object that serves to fire the beam, which may well be a UTWeapon class if you're a first person shooter styled game.
Two is the actor that is being hit. It needs to be little more than a derivative of Actor, or if physically simulated, a derivative of kActor.

The process itself for doing what you want is also quite simple and would occur entirely in the beam firing class:
1: Trace from the beam origin point in the direction of travel. If you hit something determine what you have hit and the collision point. Draw a beam effect between the origin and collision points.
2: If the actor you hit was your box actor, retain the angle of incidence of the collision and use it to determine the direction the beam should travel after colliding with the box actor, then determine the point at which that beam should emerge from the hit actor.
3: Repeat step one.

Vailias

Fair nuf. Yeah actor would work. Its been a while since I had the unreal codebase on mental speed dial.
Though the portal beams do damage to you or objects also, which is why I thought of the weapon route first. Plus the weapon projectile classes have plenty of other existing functionality. (impact effects etc)

Now in the beam firing class, for each new direction it fires, you'd need a new instance of a line trace + effect etc. It seems really odd to me to do what is, essentially, a new beam firing within the previous projectile class. Plus, what do you do if you hit something else?

If you make the projectile like any other weapon, then the effect of a hit can be determined by the object getting hit, so you decouple the functionality of the beam into its basic parts, rather than have to try and account for everything you might want to do in the weapon itself.

Plus if you want to have L blocks, splitter blocks, or blocks that do something other than redirect the light when hit with it, the re-firing logic would be better linked to the block rather than to the beam.

Lets say in level 25 you decide to have another laser puzzle, but rather than deflection you have blocks that become solid when hit with the laser. If you code the deflection logic into the beam, you need a whole new laser and block set for the new puzzle. Which will break then if say you want to combine beam splitting and block solidification.
But if the "what do I do when hit with a beam" logic is in the blocks, you can create much more complex and extensible systems much more easily.


Also, after some additional reading, I realize that my understanding of kismet was quite lacking.
You'll still want an actor subclass, or kactor that has the block as a mesh, so that the takeDamage event can fire. But the rest could likely be done in kismet if needed.

ambershee

A beam isn't a projectile. It's literally just a trace and a particle beam effect. Beams do not have their own class in UDK because it's entirely unnecessary.

You could do all of this in a loop with around ten to twelve lines of code inside the appropriate firing function of the weapon (IIRC, InstantFire or something like that).

Noone mentioned different types of blocks that may have more profound effects, but that would complicate matters. I would still consider handling it in the weapon, but using an interface within the actor classes to determine each block's behaviour and the appropriate beam response.