MS4: Crashes with dynamic lighting
by Stefan Lundmark · in Torque Game Engine Advanced · 09/10/2006 (8:05 am) · 10 replies
I get alot of crashes when enabling dynamic lights. I cannot reproduce it as I would like to because it is not the same each time and differs between tries.
The first time it crashed I removed an interior that I thought was interfearing, and it did not crash after that. Then I added a .ogg file playing in the background and all of the sudden I cant turn on dynamic lights again.
Edit: Removing the ogg files in question takes away the crashes.
Edit: I got 778 megabytes free of RAM so that shouldnt be it.
The first time it crashed I removed an interior that I thought was interfearing, and it did not crash after that. Then I added a .ogg file playing in the background and all of the sudden I cant turn on dynamic lights again.
Edit: Removing the ogg files in question takes away the crashes.
Edit: I got 778 megabytes free of RAM so that shouldnt be it.
About the author
#2
Edit: Removing the terrain (old TGE terrain) from the mission, almost completely removes the crashes, but they occour every once in a while.
Edit: I think this is related to attaching of objects before they have been ghosted to the client.
09/10/2006 (12:22 pm)
Lowering the lighting quality does seem to help, but my low-end laptop crashes way before my high-end box. Performance related? Gah.Edit: Removing the terrain (old TGE terrain) from the mission, almost completely removes the crashes, but they occour every once in a while.
Edit: I think this is related to attaching of objects before they have been ghosted to the client.
#3
Good catch, it looks like the problem is that mpAttachedObject is never initialized in fxLight's constructor. If you set it to NULL in the constructor the crash should stop occurring.
Let me know if that helps, and I'll add the change to 1.0.
09/11/2006 (7:05 am)
Hey Stefan,Good catch, it looks like the problem is that mpAttachedObject is never initialized in fxLight's constructor. If you set it to NULL in the constructor the crash should stop occurring.
Let me know if that helps, and I'll add the change to 1.0.
#4
Edit: OK I got another one.
sgLightObjects that are attached before a client enters the mission do not update their position to them for some reason and the light ends up on the joining clients control object, no matter where it was mounted on the server. So I figured I'd have to put setUpdateMask ( sgAttachedObjectMask ); somewhere.
onAdd() wont work, as it is only called once per object on the server. processTick() could work but then again I dont know how to see if the object has been scoped or not, so I ended up hacking it into the setEnable() function and calling that each time after the light has been created, which solved the issue.
I guess that's what this is for:
Though it doesnt seem to work, like the code suggests.
Edit: More. testLOS() does not take the attached object's parent into account because it only checks fxLight::attachObject and sgLightObject's do not attach that way so it got broken.
This function is needed so flares can still be seen if they are within the objects bounding box, which 99% of the time they are.
Which brings me to my question: Why use sgAttachedObject when you can use fxLight's mpAttachedObject and keep all the functionallity that it had while saving a few pointers?
09/11/2006 (11:06 am)
That does indeed solve the issue John. Thank you!Edit: OK I got another one.
sgLightObjects that are attached before a client enters the mission do not update their position to them for some reason and the light ends up on the joining clients control object, no matter where it was mounted on the server. So I figured I'd have to put setUpdateMask ( sgAttachedObjectMask ); somewhere.
onAdd() wont work, as it is only called once per object on the server. processTick() could work but then again I dont know how to see if the object has been scoped or not, so I ended up hacking it into the setEnable() function and calling that each time after the light has been created, which solved the issue.
I guess that's what this is for:
// alright lets fix attachObject...
if(isServerObject() && !sgAttachedObjectPtr.isNull() && (sgAttachedObjectGhostIndex == -1))
{
// no? keep trying...
setMaskBits(sgAttachedObjectMask);
}Though it doesnt seem to work, like the code suggests.
Edit: More. testLOS() does not take the attached object's parent into account because it only checks fxLight::attachObject and sgLightObject's do not attach that way so it got broken.
This function is needed so flares can still be seen if they are within the objects bounding box, which 99% of the time they are.
Which brings me to my question: Why use sgAttachedObject when you can use fxLight's mpAttachedObject and keep all the functionallity that it had while saving a few pointers?
#5
I got your email, if you are seeing bugs definitely continue to report them, it helps us build a better product. Regarding light mounting this is a feature that never worked on TGE, was updated in TLK, but had networking related issues, and was rewritten again for TLK 1.4.2/TSE MS4, though the code wasn't fully merged with TSE (not sure how I missed the fxLight changes), so keep in mind that this feature is still evolving.
In the version I have here all fxLight attach members were removed except for mAttached. This solves a lot of the problems, but is causing issues with the LOS calc (which I pulled not knowing what it did).
Having a list of what is broken will help when I fix the code, right now I have:
-LOS doesn't work
-position not updated on connecting clients
Now regarding the position; what is your test setup? I've tested this with TLK, setting up players to mount lights during onAdd, when a client connects to the server both see the lights attached to the respective player. Is this broken in TSE or are you trying a different scenario?
09/12/2006 (2:50 am)
Hey Stefan,I got your email, if you are seeing bugs definitely continue to report them, it helps us build a better product. Regarding light mounting this is a feature that never worked on TGE, was updated in TLK, but had networking related issues, and was rewritten again for TLK 1.4.2/TSE MS4, though the code wasn't fully merged with TSE (not sure how I missed the fxLight changes), so keep in mind that this feature is still evolving.
In the version I have here all fxLight attach members were removed except for mAttached. This solves a lot of the problems, but is causing issues with the LOS calc (which I pulled not knowing what it did).
Having a list of what is broken will help when I fix the code, right now I have:
-LOS doesn't work
-position not updated on connecting clients
Now regarding the position; what is your test setup? I've tested this with TLK, setting up players to mount lights during onAdd, when a client connects to the server both see the lights attached to the respective player. Is this broken in TSE or are you trying a different scenario?
#6
So I should wait for a new CVS checkin rather than step trough fxLight and just confuse myself? I was going to do some cleanup but if you guys have done it already then I wont.
I too add lights during Player::onAdd and basically run light.setEnable() to turn them on/off. I had to force a maskUpdate inside that function for it to work out.
I'm not too sure if the maskUpdates are getting across in processTick() but my first tests showed that they did not. I'll take another look.
09/12/2006 (6:42 am)
Hi John,So I should wait for a new CVS checkin rather than step trough fxLight and just confuse myself? I was going to do some cleanup but if you guys have done it already then I wont.
I too add lights during Player::onAdd and basically run light.setEnable() to turn them on/off. I had to force a maskUpdate inside that function for it to work out.
I'm not too sure if the maskUpdates are getting across in processTick() but my first tests showed that they did not. I'll take another look.
#7
09/13/2006 (4:15 am)
I'll take a look at the code to see whats going on.
#8
Can you zip up your test mod folder and post or send it over, and I'll debug the problems you're seeing (specifically the no movement/not-attached issues). I've run some tests here with the player using an attached light and it seems to be working (based on the code in CVS).
09/30/2006 (12:30 am)
Stefan,Can you zip up your test mod folder and post or send it over, and I'll debug the problems you're seeing (specifically the no movement/not-attached issues). I've run some tests here with the player using an attached light and it seems to be working (based on the code in CVS).
#9
I have not merged with CVS since the first release of MS4. Our version of the game is also heavily modified so it would not be helpful (we have no mod folder, either).
Code that is connected to SG stuff is untouched, except fxLight - following your advice above in the thread. I might have broken something in there. Or it might simply be the case that I have not yet updated.
Sorry for the mess, I will do the CVS merge tonight.
09/30/2006 (6:27 am)
Sorry for not replying sooner John. Other stuff took priority :/I have not merged with CVS since the first release of MS4. Our version of the game is also heavily modified so it would not be helpful (we have no mod folder, either).
Code that is connected to SG stuff is untouched, except fxLight - following your advice above in the thread. I might have broken something in there. Or it might simply be the case that I have not yet updated.
Sorry for the mess, I will do the CVS merge tonight.
#10
Edit: Or perhaps there has not been a codedrop yet?
10/01/2006 (6:29 am)
I grabbed HEAD and it is no different than MS4 initial. I do not know the tag to get the latest stuff, obviously.Edit: Or perhaps there has not been a codedrop yet?
Torque Owner Stefan Lundmark
fxlight.cpp @ 1597