Bigger, Fatter, Faster ...

#1 I thought the regular fxLight was cool, but this is awesome =)

#2 Thanks Simon,

Now I really must go to sleep. (4:27am) :)

- Melv.

#3 hehe, fxflare4 looks like a night club :D

Great work melv! congrats again

#4 Totally speechless.

This is one badass piece of code.

#5 Hey Melv, looks really great but I seemt o be having a problem (probably me thoguh)

I added this just after where my projectile is created

%plight = new (fxLightDB)()
{
	dataBlock	= fxDefaultLight;
};
echo("%plight = ",%plight,"   p = ",%p);
MissionCleanup.add(%plight);
%plight.attachToObject(%p);

in the hope that this would attach to my projectile. In game I cannot see it at all and I get this displayed in the console...

%plight = 2284 p = 2283
(null) attached to object 2283.

Any ideas?

#6 Wow, phenominal work. Bravo Melv. :)

#7 Nice work, Melv. I really want to use these, but haven't come up with a need yet ! Well, maybe for the sun...

#8 Thanks folks. :)

Daniel,

I just got up so I'm gonna get my breakfast then I'll double-check the script stuff for you.

Later.

- Melv.

#9 Thanks Melv
Its quite possible I am not doing it correctly but it is how I would guess it would work.
:)

#10 Daniel,

The console message "(null) attached to object 2283" is in-fact not an error. It's just that the light has not got a name (as it's a ghost on the client). I've removed the message if the object doesn't have a name.

Anyway, back to the problem. I've identified the problem and I think it's worth explaining it a little.

The 'fxLightDB' is based upon the GameBase class for two reasons. One, datablock support and Two, the ability to use the 'processAfter' call. I use the 'processAfter' function to force my object to be processed after the selected object to which you want to attach. This way I can guarantee that the object has been processed before I reference it's position.

Previously, I was doing the lighting a little wrong. To explain, to get dynamic lighting working you have to do two things. The first is to add your object to the LightSet (preferably in it's OnAdd) and the second is to override the RegisterLights function.

Previously I was (incorrectly) adding the object to the server-side LightSet. This resulted in the server-side RegisterLights function being called. This sounds like it just wouldn't work but suprise suprise, the light still appeared client-side (possibly only when the client is running on the server machine).

Where am I going with this? Well, now that the light is only client-side (where it should be), I am only animating client-side (I don't want the animated position streaming over the network). This means that I use the check for dependency 'getProcessAfter' on the client. This is the root of the problem! The attachment is actioned server-side but it looks like the client doesn't see this as normally it's position would be sent via the standard pack/unpack facility after the simulation has occurred server-side....phew!!

To cut a *very* long story short, I'm going to have to find a better method of locking the light onto the selected object. The problem is really because I'm trying to avoid having the lights position sent across the network. I've got all afternoon to tackle this so I don't see why I can't solve it.

Sorry for the long explanation but I believe you can never have enough information floating around. :)

I'll drop a post when I've solved it.

- Melv.

#11 OMG! That's INSANE, Melv!!! Really awesome effects!!

#12 Daniel,

I have updated this object now. It should now track any GameBase type object *without* sending any data over the wire. :)

To explain, I wanted to allow the light to track the selected object without it resulting in data being sent over the wire. The problem was that the ghost object on the client connection didn't seem to get an event regarding the 'processAfter' call. It must be meant for server-side only which is a bit restrictive as ordered processing sometimes need to happen on the client as well.

I also had to modify the client scoping aspect of the object as the object can potentially be rendered *way* outside of the original scoping frustum if it's attach to an object. The ObjectBox now expands to take into account any 'offset' incurred by the attachment.

When you attach, the object sends the ServerID down the pipe to all clients. The clients then resolve this ID to a local ghost object and do the 'processAfter' procedure locally. Everything then behaves as normal!

The links have now been updated.

That problem was a bitch ... phew!

Enjoy.

- Melv.

p.s.

I have tested this on a remote client and all seems well although I have not tested your case of using a projectile. I have tried it by attaching to items laying about the landscape and then moving the objects themselves. On both the server and the clients the attachment seems to hold.

Let me know how you get on with the projectile case. :)

#13 Cool, Melv!!
One question, though: does the attachToObject stuff only work in the *DB-version? I'm using the "normal" one and couldn't find anything for attaching in the code...
if so, why is it the case? Are there major differences between the two versions?
Anyhow, thanks for the great work!! :-)

#14 Darn it. It seems to work on everything except projectiles. The projectiles are not returning a valid ID.

I'm on it ...

- mELV.

#15 Stefan,

Yes, only GameBase objects allow you to explicitly set process ordering. This is essential otherwise you couldn't be sure that the object you are attached to has been updated yet!

- Melv.

#16 Thanks for all the work Melv. Is the script I was using correct for adding the light?

I cant wait to see this as a projectile :)

#17 Okay,

I got this working as a projectile although I will warn you that there is a minor problem still to be sorted. It appears that the fxlightDB object is hanging around long after the projectile has died. I'm too tired to sort this at the moment, I'll do it on Monday.

I made the following amendments to 'crossbow.cs' in "fps/server/scripts" in function "CrossbowImage::onFire(%this, %obj, %slot)" to test the projectile. I entered this at the bottom before the "return %p" statement.

%fxldb = new(fxLightDB)()
{
  dataBlock = fxDefaultLight;
};
%fxldb.attachToObject(%p);
MissionCleanup.add(%fxldb);

Obviously you will need a 'fxDefaultLight' datablock or your own.

Apart from the thing hanging around it works really well. If you shoot it behind buildings it disappears until it comes out the other side ... cool!

Enjoy.

Melv.

#18 Works like a charm Melv :)

To remove the lightdb when projectile gets removed just do the following

%fxldb = new(fxLightDB)()
{
  dataBlock = fxDefaultLight;
};
%fxldb.attachToObject(%p);
%p.light = %fxldb;
MissionCleanup.add(%fxldb);


function ProjectileData::onRemove(%data, %obj)
{
	%obj.light.delete();
}

Thanks again Melv, great resource :)

#19 Thanks Daniel,

Yeah, I guessed it would be something simple. I really must play more with the scripts.

Enjoy. :)

- Melv.

#20 Much Thanks Melv. You're doing a very great job here.
Don't know, what i would do without you :)