TGEA 1.7 Bug: light editor saves a mixed datatblock

#1 This appears to be a side-effect of choosing the "Clone..." operation without first selecting a light datablock using the "Light DB" menu. It starts off as a copy of some arbitrary datablock and then sgLightObjectData fields become added as dynamic fields.

If you select a valid light datablock first, then clone, it appears to save correctly. However, this does look like an easy mistake to make and it could produce strange errors by inadvertently saving a rogue copy of some other datablock in your project.

#2 I should have explained more, sorry about that...

This light was not a clone, it was "New"...but I did not select a DB block before creating the new light.
hehe..tricky tricky.

#3 Could not replicate this problem. Even with no prior light DB selected, the light editor always created a correct new block. When cloning with no prior selection, the resulting file is empty.

Going through the relevant code, it's also odd how the SFXDescription had found its way into the light editor's code. Looks more like a corruption issue.

#4 - This has randomly occurred with properly named datablocks[(redlightbright)]..with no ryhme or reason.
I just delete the .cs file and restart the game to get everything back in order.


[absurd]..and of course the issue always occurs with the following poor naming convention:
Using 3 or 5 as the prefix to the light name will cause "datablock SFXDescription(AudioDefault3d)"
Using 55 will cause "datablock ParticleData(CrossbowDebrisTrail)" or likeness.
Using 33 will cause "datablock SFXProfile(HealthUseSound)" or likeness.

examples: 33light, 5sure, 3darn, etc....[/absurd]

#5 Thanks, eb, for the additional info. That's valuable. Will give that another look.

#6 Hmm... I can see that I will have to stop speaking casually for you to understand me without a chance of error.

I do not use numbers like you may think...this is why I encased that information with [absurd][/absurd] WHILE starting off with "... . . the following poor naming convention".

- Nevermind about that anymore Rene.
It is not a huge deal as long as there are ways to work around the issue.



Try this one:
Here is a different issue..try this to see if you can recreate *anything * I post about:
1. open a tgea mission
2. press f11
3. press ~ (for console)
4. type: reloadmaterials and hit enter
5. Look at your mission inspector ....it just added material writeouts to the mission inspector
6. move an entity and then save the mission...now your mission file contains the material information

Your mission file will now look like this:
from 9kb to 491kb
www.fragstudios.com/devuploads/borkedMission.mis.txt

These issues are not a huge concern to me..they just make me giggle. Other people have the same problems. They are "manageable" IF you understand the issue and how to fix the problem.
- Some new users will not comprehend this whacky-ness..so I post here to hopefully help someone stop banging their head against a wall.

That's all really. Just alerting those that may need this info.

#7 Can reproduce the problem with the names you have given above but since these are not valid TorqueScript identifiers, that sort of doesn't count.

Are the properly named datablocks really all valid TorqueScript variable names? If so, can you maybe post a dump of a console log snippet for when you create and save such a light DB? That would be helpful.

//EDIT:
Sorry, haven't hit "reload" before posting...

I got that with the [absurd] only after posting. Sorry, if I'm a little slow here.

#8 Sure Rene...I will give it a try later today or tomorrow.

#9 The reloadMaterials() behavior is due to $InstantGroup being set to "MissionGroup" and compiledEval thus adding all the custom materials to the group. Will take a more thorough look at that tomorrow.