This is the original source code: (instance goon1 of View
(properties
name "Vinnie"
view vMobFlunkee1
loop tBustLoop
cel 0
x 68
y 65
)
)
(instance goon1Talker of Talker
(properties
name "Vinnie"
view vMobFlunkee1
loop tTalkLoop
nsLeft GOON1LEFT
nsTop GOON1TOP
x GOON1X
y GOON1Y
talkWidth 280
)
(method (init)
(= mouth goon1Mouth)
(super init: &rest)
)
)
You'll note that both of Vinnie's parts have different names in the code, but then the compiler takes the name property and puts that in the final result. The original names (goon1 and goon1Talker) cannot be recovered from the resulting SCR file -- all the decompiler sees is Vinnie. And you can't actually have two objects in the same code unit with the same name (you can't say (Say Vinnie "\"Now to you, Bruno.\"" #dispose: #caller: self) because the compiler wouldn't know if you mean the View or the Talker), so the decompiler has to rename them. However, object names only matter at runtime when an object has to identify itself. For example, by having a talker's name appear in a dialog box title bar. And therefore, when you recompile LSL5 from a decompilation, goon1Talker will have been renamed Vinnie_b, and that's what will appear in Vinnie's dialogue boxes.
I don't know why goon1 was also renamed to the same thing, it doesn't even survive room initialization because of an addToPic. Who knows what John Hartin was thinking? But I do know you can certainly guess what Bruno's original object names are.
And of course the inventory items have much more programmer-friendly names -- would you rather refer to AeroDork_s_In-Flight_Magazine in your code, or just magazine?
