PATCH 2.0a - !WARNING FOR MODDERS! (Corrected)

The place to discuss scripting and game modifications for X³: Terran Conflict and X³: Albion Prelude.

Moderators: Moderators for English X Forum, Scripting / Modding Moderators

Post Reply
aXeL_UK
Posts: 195
Joined: Thu, 23. Oct 08, 22:45
x3tc

PATCH 2.0a - !WARNING FOR MODDERS! (Corrected)

Post by aXeL_UK » Tue, 7. Apr 09, 21:59

Hi folks,

Unless I've been really obtuse and missed the announcement, Egosoft have tweaked the script engine (for the better I'm sure), with the unfortunate side effect of stopping scripts working unless they conform to a particular convention. Some of my mods, including my White Star load script, won't work properly in patch 2.0a (fixed now, upload to follow). My script was produced with Exscripter and worked fine on patches 1.3, 1.4. With patch 2.0a it didn't load the ship, instead it loaded a laser tower!!! I immediately checked for conflicts and found none. Even the language files were ok and I could still spawn the ship. To fix my script I had to open it in the game engine, change the lasertower(?!) back to my White Star and then save it and guess what.....

The new script file, produced by patch 2.0a is very different to the old one even though the syntax I wrote is identical. I then went and checked my other mods. All the mods which have failed do not follow this particular convention.

I tried to post samples of what to look for but the forum engine strips out all the additional code (yes I turned off HTML, BBCode, tried [quote], code etc....). Suffice to say if you take a script produced in Exscripter and then save it again in the patch 2.0a game engine, the new script file will be very different to the old one. Notably, everywhere there was a space in some text it's now filled with '*&#160'

Before you go loading all your favourite scripts and plugging the gaps with '*&#160' be warned that the objects can be changed for no reason I've been able to discover so it maybe safer to leave it to the authors.

Interestingly, amurph0's shipyards already followed the correct convention. Amurph0, what tool did you use?

To the author of Exscripter; Great tool, relied on it heavily, however for Patch 2.0a...DOH!!

If this is all obvious to everyone then my apologies for ringing alarm bells. XML isn't my forte...

aXeL
Last edited by aXeL_UK on Tue, 7. Apr 09, 22:33, edited 1 time in total.

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Tue, 7. Apr 09, 22:16

This should be more a warning for modders not scripters. And conceptually they should be aware in the design phase before the need to address in version control, so mostly mute.

The reason why object details have changed is because the various catergory files have changed with the inclusion of new standard objects (e.g. Tships, TwareT and so on). So you have to incorporate your custom models into new files. Or modders have changed standard configurations for their use and have been overwritten by the standard install.

I doubt anything in the script language itself has actually changed in moving from 1.4 to 2.0, and whilst scripters might use literals to address the above file entries it's best to design mods and write scripts with ES version control in mind.

Hence for the mods to work in version 2.0 it is best to wait till they have included in the new standard list their custom content again.

(As a side note version 2.0a is the same as 2.0. The numbers that have been used are for shipping purposes not software versions)

User avatar
SymTec ltd.
Posts: 5285
Joined: Mon, 11. Apr 05, 21:11
x3tc

Post by SymTec ltd. » Tue, 7. Apr 09, 22:25

I agree with pelador: Things that need to be updated are mods (+ scripts that only work with those mods) and the external script editor. Scripts from the vanilla editor for a vanilla game are not affected.
  • No X3TC scripts created with the X3TC script editor 1.x will stop working in any way
  • Scripts created with an external script editor should also work, but that external script editor needs to be made compatible to the new commands of 2.0 (not the other way around)
  • 2.0 adds new ships. Therefore, the ships list from the external script editor is not up to date anymore (the list of the internal editor is always up to date), and needs to be updated
  • Mods that add ships will have to be updated for 2.0. No way around it; it just doesn't work any other way.

aXeL_UK
Posts: 195
Joined: Thu, 23. Oct 08, 22:45
x3tc

Post by aXeL_UK » Tue, 7. Apr 09, 23:16

Thanks for the quick response chaps.

I should've pointed out that I update my mod for the relevant files, TShips, WareLists etc, using the 2.0a versions as the baseline, before I did anything else. I first noted the revisions to TShips by the change in the index number at the start of the file. The fact that my ship spawned properly with all the correct wares and parameters plus I could still see new 2.0a objects, proves those files were loading and behaving correctly.

Oddly, the same script was still referencing a different object, despite the game engine recognising the proper object (and enabling it to be loaded manually).

I agree with the point about 3rd party script editors needing updating, hence my point about Exscripter.

While I agree with all of Symtec's points, I'm not sure I agree with Pelador's comment about pre-requisite knowledge for modders/scripters. Is not the purpose of this forum to provide that kind of advice and support to modders (Some of whom are not professional devs)? (By the way, it's 'moot' meaning debatable, not 'mute' ;) ) And what is 'ES' version control?!

I'm not any kind of programmer - I see changes in script file format and behaviour which stopped some of my 'mod' scripts working so I fixed them and posted what I found. I spent an evening learning that updating mods from 1.4-2.0a was far harder than for 1.3-1.4 so hopefully this helps save others from the same headaches along the way...

jlehtone
Posts: 21801
Joined: Sat, 23. Apr 05, 21:42
x4

Post by jlehtone » Tue, 7. Apr 09, 23:55

In "version control system", one would talk about "merging branches".

ES made a file A for TC 1.
Modder made file A', a changed version of A, a "branch".
ES changed A for TC 2, lets call that version B.

Now modder has to merge differences between A and A' into B in order to create B'. And if both A' and B have changed the same part of A, the merge will be non-trivial.

pelador
Posts: 1399
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by pelador » Wed, 8. Apr 09, 00:48

aXeL_UK wrote:Thanks for the quick response chaps.

While I agree with all of Symtec's points, I'm not sure I agree with Pelador's comment about pre-requisite knowledge for modders/scripters. Is not the purpose of this forum to provide that kind of advice and support to modders (Some of whom are not professional devs)? (By the way, it's 'moot' meaning debatable, not 'mute' ;) ) And what is 'ES' version control?!

I'm not any kind of programmer - I see changes in script file format and behaviour which stopped some of my 'mod' scripts working so I fixed them and posted what I found. I spent an evening learning that updating mods from 1.4-2.0a was far harder than for 1.3-1.4 so hopefully this helps save others from the same headaches along the way...
Yes its useful advice. But modders should be aware of the implications of mods with changes to the standard software in order to best support it. I prefer to look at other developers favourably as a result that they will have done their "homework" so to speak. So the point is moot (sorry for the previous homophone) for those aware, but very relevant for those who havent. The fact that some may not work at the moment may be due to the fact of personal time or discontinued support so your comment about not following convention may not be true as people will be following convention prior to 1.4 and need to update to the same convention in 2.0, I just think your post came accross a bit alarmist that you didnt credit developers as aware but currently converting. The reason now why we have purple stars in the library to show who has converted.

The point about developing scripts is to best do them generically as possible, if similar ids are used in cat files and their are consistent then the 1.4 version "will work" but if those standard aspects arent incorporated into their mod the game wont be running with correct definitions. Some people might also take shortcuts to get their end results making them harder to convert and its also dependant on the nature of the catergory file wether additions appending to or changing default values is preferable but support implication arise based on those choices either way.

My point about being "mostly" moot simply was to state that i like to think others are aware and doesnt require the alarmist responce, but i will concede that those who dont know it is useful.
Last edited by pelador on Wed, 8. Apr 09, 05:16, edited 1 time in total.

User avatar
apricotslice
Posts: 14129
Joined: Sun, 16. May 04, 13:01
x4

Post by apricotslice » Wed, 8. Apr 09, 01:53

In v2a, egosoft added 3 new ships. (in 1.4, they did not)

That means all the mod ships are now offset by a ship slot, which means that the scripts need to be altered to reselect the right thing.

*reminds self he forgot to change the scripts*

While the script shows the name of the ship, its actually seeing only the slot. So if the file changes, whatever ship is in that slot will be displayed int he script.

The first new ship is a lasertower, so thats why the whitestar is now a lasertower. :)

Logain Abler
Posts: 2255
Joined: Mon, 31. Oct 05, 08:44
x4

Post by Logain Abler » Wed, 8. Apr 09, 09:19

I use the code below in my FDN scripts so the off-set of my added stations is not "hard coded", any changes to the type file don't mean a re-write of the script files.

A great tip from Gazz.

Code: Select all

$PageID17 = 17
$node.XL = read text: page=$PageID17 id=300021
$node.XL = sprintf: fmt='%s', $node.XL, null, null, null, null
 
$sub = get number of subtypes of maintype 5
while $sub
  dec $sub =
  $node = get ware from maintype 5 and subtype $sub
  $node = sprintf: fmt='%s', $node, null, null, null, null
  if $node.XL == $node
    $Found = [TRUE]
  end
end
LA

User avatar
Sartorie
Posts: 389
Joined: Sat, 10. Apr 04, 13:05
x3tc

Post by Sartorie » Wed, 8. Apr 09, 12:59

If you base your mod on someone elses (in this case TC ;)) you have to update your mod everytime the base mod adds / changes stuff in the Tfiles. The crux of modding in X ;)

While adjusting references in scripts etc. have to be done it should also be noted that running games being updated can be complicated. For example if you added you Whitestar ware for being on sale at a shipyard (pre 2.0) the shipyard in your game will remember the id and once you update to 2.0 this shipyard will happily sell the Lasertower ... this is also true for every running script (running scripts are cached), every reference saved in an ingame object (wares on stations / cargo hold / space) and of course ingame variables.

aXeL_UK
Posts: 195
Joined: Thu, 23. Oct 08, 22:45
x3tc

Post by aXeL_UK » Wed, 8. Apr 09, 17:55

Sartorie wrote:If you base your mod on someone elses (in this case TC ;)) you have to update your mod everytime the base mod adds / changes stuff in the Tfiles. The crux of modding in X ;)

While adjusting references in scripts etc. have to be done it should also be noted that running games being updated can be complicated. For example if you added you Whitestar ware for being on sale at a shipyard (pre 2.0) the shipyard in your game will remember the id and once you update to 2.0 this shipyard will happily sell the Lasertower ... this is also true for every running script (running scripts are cached), every reference saved in an ingame object (wares on stations / cargo hold / space) and of course ingame variables.
Now this betrays by ignorance of references in scripting!! I thought if I specified an object it meant the script would always get that object, i.e. get White Star means goto wherever White Star is and get it - lines be damned! It seems logical that 'get White Star' does not mean 'get Lasertower' irrespective of what line it's on. Why? Because I never had to consider the line numbering of the objects, i.e. if it was line 326 in TShips, for example, I didn't need to consider that when I wrote the script so I'm still at a loss as to why I need to consider it now. If the script saved with some sort of mumeric reference to line 326 then it makes sense that it needs changing but it doesn't, it saves the object as 'White Star' I can open up the script in a text editor and see 'White Star' not Lasertower but even if I start a new game it was still a Lasertower - but thanks for the heads-up folks. At least I know now that just because I refer an object it doesn't mean the engine will always use it, even it isn't clear to me how/why it references these 'slots' instead when I've not specified them! Like I said, I'm clearly not a programmer. Scripting is something I endure as the only way to get stuff into a game without cheating it in!!

Logain, that code looks really clever... and far too complicated for me but thank you (Gazz too).
If you base your mod on someone elses (in this case TC Wink) you have to update your mod everytime the base mod adds / changes stuff in the Tfiles. The crux of modding in X Wink
Thanks Sartorie - glad we cleared that up! :lol:

I think the key lesson is that for scripts created in 3rd party editors, ALWAYS check them through the in game editor and re-save them. I didn't... oops!

User avatar
Gazz
Posts: 13244
Joined: Fri, 13. Jan 06, 16:39
x4

Post by Gazz » Wed, 8. Apr 09, 18:08

aXeL_UK wrote:Logain, that code looks really clever... and far too complicated for me but thank you (Gazz too).
If you "hardcode" a shiptype like "Shrike" in a script, all you're really typing is Maintype 7, Subtype 165.
That system makes it a bitch to create a script that uses a speciall modded/added object.

Not because you can't hardcode that particular object type but because you can not guarantee that user Tom Doe has not already some other modded ship on that index.
Then your script fails because it accesses the wrong ship type.

I wrote "that code" for the Complex Cleaner. The CC runs on a bunch of special station types but it can be added to every modded game there is because those objects are referenced by name rather than by index.
That way it's sufficient to glue these station objects to the end of TFactories.txt and that's that.

I think the plugin manager uses a similiar system to handle the adding of modded ships.
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.

aXeL_UK
Posts: 195
Joined: Thu, 23. Oct 08, 22:45
x3tc

Post by aXeL_UK » Wed, 8. Apr 09, 18:53

So, if I understand correctly, I could use the name in my custom language file (assuming no-one else uses my indices) to then go and find the correct object type and sub-type which I can then use in the rest of the script so I don't need to worry about type changes across revisions to TShips and similar files. Cool, thanks Gazz, I'll take some time to get to grips with it if you don't mind me blatantly plagiarising your code!

Logain Abler
Posts: 2255
Joined: Mon, 31. Oct 05, 08:44
x4

Post by Logain Abler » Wed, 8. Apr 09, 20:50

aXeL_UK wrote:So, if I understand correctly, I could use the name in my custom language file (assuming no-one else uses my indices) to then go and find the correct object type and sub-type which I can then use in the rest of the script so I don't need to worry about type changes across revisions to TShips and similar files. Cool, thanks Gazz, I'll take some time to get to grips with it if you don't mind me blatantly plagiarising your code!
I'm sure Gazz won't, he let me :wink:

LA

User avatar
Gazz
Posts: 13244
Joined: Fri, 13. Jan 06, 16:39
x4

Post by Gazz » Wed, 8. Apr 09, 21:08

The beauty of that is, that the string comparison works in every language.

If the language is russian then the shiptype reads it's name from the russian TFile, ID 40457 and the script fetches the compare string from the russian TFile, ID 40457.
Just... beautiful.

Logain Abler wrote:I'm sure Gazz won't, he let me :wink:
Besides, it would be terribly hard to claim and enforce a copyright on like 10 script instructions.
My complete script download page. . . . . . I AM THE LAW!
There is no sense crying over every mistake. You just keep on trying till you run out of cake.

Whimsy
Posts: 167
Joined: Mon, 9. Feb 04, 20:32
x3tc

Post by Whimsy » Thu, 9. Apr 09, 12:40

Everyone seems to have explained and sorted the problem out already, but I thought I'd just add a bit more to help clear up a couple of things.

Firstly, as far as I know, there have been no changes to the script engine for 2.0. In the script files, the actual text you see is not used by the game (and so all the '&#160' things are not important, and you can't trust it if the text says 'White Star'); Exscriptor usually outputs slightly different text here to the in-game editor but you'll only see it if you view it in a browser. You can create a valid script file without any of this text at all and it will still run in the game, because the game itself uses a huge list of numbers in the second half of the script file called the 'codearray'. In this case, somewhere in there will be your command to load up your White Star, and it will just be a list of numbers, e.g. 750, 131075, 1, 9, 459087. That last number is translated by X3TC into something like 'TShips #321', so it looks up whatever ship is at line #321 and loads it.

If something like a patch or a mod inserts new ships before #321 (or whatever) then #321 is no longer what the script thought it was. The only way to fix this is to open it up in a script editor, change it back to what you want it to be, and resave it. This applies to scripts made in both the in-game editor and Exscriptor; also, both use the same data files (Exscriptor doesn't have its own separate list). Unfortunately, you will still have the problem of updating currently running scripts in a save game though and these commands may have to be restarted. The best solution is probably to use Gazz's code or something similar so you avoid having to use a specific hardcoded number in the first place. :)

Rudinho
Posts: 73
Joined: Thu, 6. Mar 08, 20:42
x3

Post by Rudinho » Mon, 13. Apr 09, 15:26

Cycrow's SCS don't work with 2.0a

The ware is on my ship as blank field, and Teladi EQ the same, blank, vlo 1 , no price.

Posted in SCS thread.
X3: Reunion SH3 and IV style Hunter :D
Asus P5QLD
Antec True Power 650W
C4Q 9550@2.8Ghz
G.Skill 4x1GB 6400 CL4
SSD X25 60GB
ATI HD6950 2GB

Post Reply

Return to “X³: Terran Conflict / Albion Prelude - Scripts and Modding”