Laws of X3 Scripting

[Litcube]

Indexed Laws of X3 Scripting & Modding

1 ) LV's 1st law
Regardless of the effort an author invests in the features of a product, it's almost a certainty that the first series of reply posts will be requests for new features.

2 ) LV's 2nd law
Regardless of how user friendly a script is, or how much detailed spoonfeeding documentation is included, there will always be a constant flow of users who either don't RTFM or are incapable of following the most basic of advice.
2.1 ) Carlo the Curious' addendum to LV's 2nd law
In space, no one can type "Thereshallbewings".

3 ) LV's 3rd law
If something is broken, wildly blame any script that you feel like.

4 ) jocan2003's 1st Law
No matter how hard you try, your first script will have a lot of bugs.

5 ) mailleweaver's 1st Law
Every function has some built-in undocumented quirk that will eventually throw you for a loop.

6 ) mark_a_condren's 1st Law
What may seem the simplest thing to do, will quite often take the most lines of code to accomplish.

7 ) djrygar's 1st Law
Regardless of how many times you answer, the question will be repeated within the next 2 pages.

8 ) EmperorJon's 1st Law
When you've finally fixed a script bug, you've created a new one.

9 ) Logain Abler's 1st Law
Its not a bug, it's a feature.
9.1 ) Apricotslice's addendum to Logain Abler's 1st Law
A Feature is a Bug you decide works better than the original idea.

10 ) EmperorJon's 2nd Law
More often than not, the scope of a workaround to a feat deemed impossible is directly proportionate to a negative impact in performance.

11 ) jocan2003's 2nd Law
The size of a script is directly proportionate to the author's probability of having carpal tunnel syndrome.

12 ) Apricotslice's 1st Law
There is a point where a complete rewrite is faster than fixing bugs.

13 ) h2o.AvA'ss 1st Law
While loops are magical.

14 ) Roger L.S. Griffiths' 1st Law
In scripting, to wait is to sleep and sleep is divine.

15 ) Killjaeden's 1st Law
At minimum, the notion "oh nice, let's quickly try that" will last 2 hours.

16 ) Alan Phipps' 1st Law
Marking a script package as an Alpha version will automatically trigger a user complaint that said package has destroyed a savegame with no backup.

17 ) EmperorJon's 3rd Law
The amount of time spent making a script is directly and negatively proportional to the number of downloads.


If I've mis-paraphrased you, please let me know. If I've skipped you, it's because I've felt the laws were covered in earlier sections, or weren't necessarily relevant to X3 scripting or modding.

[jocan2003]

No matter how hard you try, you first real script will have a lot of bug. Unless its a simple script and even...

[mailleweaver]

Every function has some built-in undocumented quirk that will eventually throw you for a loop.
And no matter how simple a script is, bug testing and fixing always takes at least 10 times as long as writing it.
But... scripting can sometimes be more fun than actually playing, just because of "Oh, the possibilities!"

[LV]

Well as i'm writing laws now:-

LV's 2nd Law Of Scripting

Pebcak errors

No matter how user friendly a script is, no matter how much detailed documentation is put with it, No matter how much spoonfeeding of how to's are added:- There will always be a constant flow of users who either don't RTFM or are incapable of following the most basic of advice. Therefore all scripts must be written to cater for the Neanderthal user

Expect several posts stating the script does not work or that they can't install it, this will never be the fault of the user, why would it be their fault, just because 99 out of 100 other users are using a script without issue, it is the authors fault it does not work for that user.

Onto Law 3:-
"IF something is broken, wildly blame any script that you feel like"

Yes, the bane of coders, User has a problem and decided either through random topic selection or the fact someone else makes a vague reference to a problem in a topic that a script is the cause of their problems.

No evidence or detail is needed, simply post in a topic that "this script" has broken your game, within hours others will read the post and assume that the script is the cause, the jungle drums will start to beat and before long your script becomes the devil incarnate. The real fun value comes for the coder who then spends hours looking for a bug that does not exist for them as it is not their script that is causing it.

The proverbial cheery to top this cake is after spending countless hours searching the OP on occasions pops back into the thread a couple of days later with "My bad it was something else causing it"

[ external image ]

[mark_a_condren]

What may seem the simplest thing to do, will quite often take the most lines of code to accomplish.


Examples:
(Take getting all the items onboard a ship for example, 1 line of code? Oh no .... I still can't find; <RetVar> = Get all items onboard: <Ship/Station>)

And, there is alway,
<RetVar> = Get sector array from universe
<RetVar> = Get sector array: <Var/Race> Start Sector: <Var/Sector> Only include linked sectors: <Var/Booleen> (Race = Argon, Start sector = Argon Prime, Booleen = TRUE. This would return an array of just the linked Argon sectors around Argon Prime)

MarCon

[gmargaro]

Laws of programming / scripting :

- Any software or script that have no bugs is a software / script that have no users.

- There is 99.99999 % of chance that the problem is between the keyboard and the chair.

[djrygar]

there are easy solutions to things described in LV's laws

User:
- how do enable IR menu? / I think I found a bug..IR crashed my game

Me:
-GTFO (go use RFF)



(because no matter how many times you answer, it will be repeated in next 2 pages, because 'users don't have time to go trough 200 pages of text')

[EmperorJon]

My personal law:

You'll spend ages fixing a problem only to find out that wasn't the cause of the problem... and when you finally get it right, you create a new problem.

[Litcube]

I love law 3. So true. I've edited the original post.

[Logain Abler]

My 1st law:

Its not a bug, its a feature!

LA

[EmperorJon]

Another 2:


You spend hours working on a genius idea, and just when you get to the last key feature someone points out it's impossible.
Eventually you come up with a way of making it work.
A way that kills the user's FPS so much nobody will use it.

_______

Just when you've achieved something wonderful, you find a small niggling detail that you're determined to fix. You then find out that it's impossible to make it how you want without using the Mission Director.
You open up the MD files, and promptly commit suicide.

[jocan2003]

2nd law, longuer the system you are trying to build, closer you get to the carpal pain. (edit it im french i know its not the right wording, but i believe you understand what i say )

[EmperorJon]

Carpal Tunnel Syndrome?


Agreed!™

[Carlo the Curious]

Addendum to LV's 2nd law:
In space, no-one can type Thereshallbewings.

[EmperorJon]

EDIT:

More often than not, the scope of a workaround to a feat deemed impossible is directly proportionate to a negative impact in performance.

That is a win way of putting it.
You sir, deserve a Valhalla.

[Litcube]

Addendum to LV's 2nd law:
In space, no-one can type Thereshallbewings.

Yeah, that's a good one.

[jocan2003]

You got my sentence better than i first tought it in french word! ( god my sentence are awfull )

[apricotslice]

Apricotslice's first law of coding :

A Feature is a Bug you decide works better than the original idea or adds something you decide to keep.

Apricotslice's second law of coding :

Fixing a bug always creates another bug.

Apricotslice's third law of coding :

Bugs multiply exponentially by the number of attempts to fix them.

Apricotslice's fourth law of coding :

There is always a point where a complete rewrite is faster than fixing bugs.

Apricotslice's Law of Honesty in the coding place :

Anywhere where coding is done should have the following sign on the wall. : "Controlled C*ckup in Progress"

[h2o.Ava]

1. Don't use the same variable for everything.

Code: Select all

$var = [Playership]->get sector
$var = $var->get owner race
if $var == [Argon]
  $var = 20
else
  $var = 10
end
while $var
  dec $var =
  skip if $var < 11
    continue
  $var = [Playership]->get sector
end
*explosion*

2. To master arrays, build yourself an array of arrays and extract data from those arrays.

3. While-loops are magical, they turn 100+ lines of code into 10 lines of code.

4. Use detailed information in incoming messages, write to player logbook, and logs. The more details you provide yourself, the easier it is for you to troubleshoot your bugs.

[Sam L.R. Griffiths]

Nice thread, love the concept (kind of like a lessons learned from fellow scripters/modders).

1. The holy trinity of scripting is MCSI (Script Editor), AL Engine (Script Editor), MD (Mission Director)
2. (The) GoD (Engine) works in mysterious ways (e.g. Weapon/Missile selection for spawned craft, and "apparently" random destruction of "last of their kind" stations)
3. What can not be done in MCSI can sometimes be done in MD if at all (and visa versa)
4. To wait in scripting is to sleep and sleep is divine