Fallout 2 with RP 2.3.3 : I can't extract a brain from a companion

Unfortunately, decompiling a Fallout script is a little like trying to turn omelette back into eggs...
I disagree. It really isn't much trouble at all, unless you want to edit multiple scripts. Endocore wrote his mods in decompiled scripts without headers. MIB88 is doing the same. They use noid/ruby while I much prefer int2ssl/sfall script editor.
 
:scratch:

I've been doing it like this for 15 years. But, who knows? Maybe my way will become untenable after 16 years... or something.

TSpent three days trying to find out why Dr. Fung in San Francisco was killing my PC when I realized that even if I took a working script, decompiled it, then recompiled it without changing a thing that this error would still happen.
:D

Here's a revised version, anyway.
 

My issue isn't related to the process/decision of using headers versus just decompiling and editing scripts. And, Kokeeby in that other thread was using headers. So... eh.

We find humor where we can, I guess.
 
Last edited:
My issue isn't related to the process/decision of using headers versus just decompiling and editing scripts. And, Kokeeby in that other thread was using headers. So... eh.

We find humor where we can, I guess.
Oh, but it is. Regardless of whether the decompiler worked correctly or not, you can't find the problem in the decompiled script. The reason is, you don't understand it, and that's because it's too complex.

Using headers or not, a decompiled script will almost always be more complex than the original (barring cases of bloating the original with unnecessary code). Managing complexity is a fundamental issue in programming, and preprocessing is a technique designed to do just that. Decompiling throws preprocessing out of the window and in addition obfuscates variable/constant names. This is exactly the recipe to spend more time debugging.
So, it's definitely harder to work with decompiled scripts. And since development resources are limited, but complexity is not, with certain project size it's bound to become nigh impossible.
 
I wish I knew how to script...and no (before anyone says "go learn it asshole"), I don't have the brain for such things.
 
It's not harder for me. Over 1700 scripts modified this way, multiple times being decompiled and recompiled (so, easily 17,000 such successful operations) and you want to use this one instance to justify a way of doing things the way you want to do them. Your method is fine for you if that's what you want. But, talk about confirmation bias...

@.Pixote. I barely get through the scripting, having learned just enough to mod this game. However, you've got the gift of working with graphics. That's something we all appreciate already. Thanks for your work.
Oh, and: go learn it, a-hole. :P
 
Last edited:
I thought the main idea here is the readability of script source for other people to maintain/expand/build upon?
 
I thought the main idea here is the readability of script source for other people to maintain/expand/build upon?

It's not only a question of readability as such, dealing with decompiled scripts is easy enough if you spend some time with them. With scource scripts the big advantage is documentation (of comments, changes, problems etc) and variable names. Headers saves a lot of time as you don't have to type the full code, and you can easily add it to several different scripts. This is obviously way better if you are making a new mod (especially if several people are involved.

But there is a big advantage to decompiled scripts. You see the full code all at once, which makes it a hell of a lot easier to find bugs, especially those whitin the header files.

Also when merging several mods, ie adding code from multiple versions of the same script into one, like MIB88 is often doing I would also rather use decompiled scripts.

Personally I find using headers and documenting everything boring. While it's probably better for the community to do so, in the end it's the enjoyment each modder get from their own modding, that is most important.

Depending on what you are trying to acomplish, and for who, there are advantages to both methods. Saying you should stay away from decompiled scripts, especially when there is no team involved, just comes off as a snobbish prefferance.
(This was not directed at you @NovaRain, just wanted to add to what you said.)

@.Pixote. Considering the thread title, have you considered a brain transplant?
 
Last edited:
Oh, but it is. Regardless of whether the decompiler worked correctly or not, you can't find the problem in the decompiled script. The reason is, you don't understand it, and that's because it's too complex.

I felt I should make one more post here in case someone else read this thread and was scared away from scripting or looking at decompiled code.

Dr. Fung works properly once again. I did find the problem. It just takes a little patience. Don't let anyone tell you something is too complex or you can't understand something. Odds are, they're just talking out of their a$$.
 
It's not harder for me. Over 1700 scripts modified this way, multiple times being decompiled and recompiled (so, easily 17,000 such successful operations) and you want to use this one instance to justify a way of doing things the way you want to do them.
I'm not sure what's your measure of success here. That there's a lot of modifications made? As if it was something good. The point of using headers is exactly to achieve more while doing less.
Of course, any problem can eventually be found. The question only is how much time you spend on it.

It's not "my way", really. It's simply that there are good practices and bad practices in programming. And duplicate code is a bad one, generally. A simple google search will reveal that to anyone willing to make an effort of typing a question into the search bar https://www.google.com/search?q=why%20duplicate%20code%20is%20bad.

Also, anyone wanting to get an independent opinion on that, can easily do that. Take any script, for example the mentioned one, Dr. Fung's, in original form and decompiled one. Head over to stackoverflow.com, and ask a question: "These two files are forms of the same script. Given that I'm going to modify and maintain this script for some time, which version I'm better off using?"

Edit: of course, if someone actually prefers working with decompiled files, that's their own business, by all means. I'm simply offering an advice.
 
Last edited:
blah... blah... blah...

I know you're not sure what my measure of success is, since I've never told you. However, simple context clues should have indicated that my use of the word successful in "successful operations" simply means operations which worked.
So, take your mind back about a week. I know it might seem like a long time, but, please try. Do you remember when you said that using decompiled scripts was "Unmantainable [sic] in the long term"? And then you tried to use something I said in another thread as some sort of proof that the method is no good? Yeah, that is what my 17,000 successful operations comment was about. Sure, I said you were looking for evidence to justify your already chosen course of action ("the way you want"). It's common. A simple google search about confirmation bias, the comment that I made after the portion you quoted, would reveal to anyone willing to make the slightest bit of effort what I was referring to.

So, to clarify since you missed it: I was saying that I had 17,000 successful operations the way I've been doing things. You zeroed in on something from another thread, which showed one instance of the procedure not working which might support your position (but didn't, since that person in the other thread was already using headers), rather than the larger number. That is an example of confirmation bias.

Duplicate code? Who said anything about duplicate code? And how is it duplicate code if it is a script modified in a different way from a different mod from a different author? What are you talking about?
No... Wait... Nevermind. I don't care.


Maybe you just completely overlooked what Darek wrote. Do yourself a favor and (re)read that. He hit the nail on the head there.
 
Last edited:
I know you're not sure what my measure of success is, since I've never told you. However, simple context clues should have indicated that my use of the word successful in "successful operations" simply means operations which worked.
So, take your mind back about a week. I know it might seem like a long time, but, please try. Do you remember when you said that using decompiled scripts was "Unmantainable [sic] in the long term"? And then you tried to use something I said in another thread as some sort of proof that the method is no good? Yeah, that is what my 17,000 successful operations comment was about. Sure, I said you were looking for evidence to justify your already chosen course of action ("the way you want"). It's common. A simple google search about confirmation bias, the comment that I made after the portion you quoted, would reveal to anyone willing to make the slightest bit of effort what I was referring to.

So, to clarify since you missed it: I was saying that I had 17,000 successful operations the way I've been doing things. You zeroed in on something from another thread, which showed one instance of the procedure not working which might support your position (but didn't, since that person in the other thread was already using headers), rather than the larger number. That is an example of confirmation bias.

Duplicate code? Who said anything about duplicate code? And how is it duplicate code if it is a script modified in a different way from a different mod from a different author? What are you talking about?
No... Wait... Nevermind. I don't care.


Maybe you just completely overlooked what Darek wrote. Do yourself a favor and (re)read that. He hit the nail on the head there.
Sorry, just because the script compiles, doesn't mean it's working correctly. So what you really (say that you) have is 17000 operations which you think worked correctly.
And like I said, it's quite likely that with a saner approach, there could've been a lot less of them. So while you might pride yourself on filling a swimming pool with a teacup, it's simply not the best course of action if the goal is to fill the pool. However if the goal is to spend your life filling the pool - that's the way to go, I agree and have absolutely no objections to that.

If you simply decompile a script and then try to compile it back without any changes, which the person in the other thread did, it doesn't matter which headers you "use", they will not be actually used, only parsed by the compiler for syntax errors if included. I understand that a person who just downloaded SFSE for the first time might not realize it. However, someone who worked with scripts for over a decade, should.
Furthermore, you're confusing "using headers" with "not decompiling". They are not the same. You can use defines in the script itself, and most scripts do have some defines, and in that case the original version wil still be more readable than the decompiled one.

About duplicate code: macros are there to remove duplicate code. That's their reason to exist. When you decompile a script, you expand all the macros, thus introducing duplicate code.
If a macro is used 50 times in the original script, and you need to change it: say... fix a bug, then you can do it with 1 (one) operation. But if you want to do the same using a decompiled version, then you have to make 50 changes - 50 instances of duplicated code. That's much more error prone, not to mention taking longer.
And if macro was used in 100 scripts, then the work is multiplied by that number. In fact, there's more - you have to find those scripts first. And you don't even know if they are there.

Regarding what @Darek said, he does have a point. Sometimes looking at low level code is necessary. (Although there's no need to decompile for that actually, preprocessing will do more or less the same.) And sometimes that might help to find a bug in header files. However, after finding it, you got to fix it, and about that, see the above paragraph.
Which is why my advice is not "don't decompile, ever", it's "don't decompile if you can help it".
 
Back
Top