X3TC Bonus Pack - Script Submission Details

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

User avatar
moggy2
Posts: 5505
Joined: Wed, 6. Nov 02, 20:31
x3ap

X3TC Bonus Pack - Script Submission Details

Post by moggy2 » Sat, 14. Mar 09, 04:07

X³ Terran Conflict - Bonus Package

Image

Important: This package can be used with X³ Terran Conflict version 2.5 or later. The use of the package with earlier versions of the game - or even with X² The Threat or X³ Reunion - can fail or lead to unpredictable results. No guarantee can be given for unsigned third-party modifications or scripts to be compatible with scripts in this package.

Image

The Bonus Package

The Bonus Package consists of a selection of scripts written by player community members. Egosoft has selected them as extensions that fit well into, and do not destroy the balance, of the game. The scripts have been signed and therefore they are enabled without activating the Script Editor. (Script Submission Guidelines, see below.)

The bonus package is available from the Download page of Egosoft. A usage manual in PDF format is included in the package. No redistribution.

General questions and feedback about the Bonus Package can be asked in a discussion thread. Specific questions about the scripts must be asked in their own threads (links below).

Image

The included scripts
  • Commodity Logistics Software MK1 (2010-06-02)

    This software supports the pilot in coordinating his internal production logistics. It will enable a pilot to collect orders from different consumers within your enterprise and coordinate them with chosen suppliers. Therefore, it is possible to deliver the products from several suppliers of a single resource to different consumers.
  • Commodity Logistics Software MK2 (2010-06-02)

    This software allows the pilot to plan a route. The pilot is instructed to follow a given route and the corresponding commodity transfer orders for each intermediate stop entered. This enables the pilot to fulfil special tasks within the company or even at different stations. The route entered will be followed repeatedly until the pilot receives new orders.
  • Commercial Agent (2010-06-02)

    The Commercial Agent can serve all the needs of a single player station or complex, both buying resources and selling products as necessary. But in order to unlock all its abilities an Agent must train by carrying out simple duties for a while.
  • Dockware Manager (2010-04-27)

    A small extension to add wares or remove wares from player owned Trading Stations, Equipment Docks or Headquarters. The Manager can set limits for the different wares for the player Headquarters too. These limits get considered by Commercial Agents and Commodity Logistics MK1 pilots.
  • Missile Defense Mosquito (2010-04-27)

    This software protects a ship - or a whole convoy that the ship is part of - against missile attacks and fighter drones by using Mosquito missiles.
  • Turbo Boost (2010-04-27)

    The Turbo Boost device is capable of temporarily speeding up a ship beyond what’s normally possible.
Image

Technical note

The Bonuspack contains a copy of the Hotkey Manager script. (Required by the Turbo Boost.)

Image

Version history
  • 4.1.00, released 2010-04-27
    Adds:
    • CAG 3.2.20
    • CLS MK1 3.3.01
    • CLS MK2 3.3.01
    • DWM 3.1.04
    • MDM 3.1.02
    • Turbo Boost 2009-12-17
  • 4.1.01, released 2010-06-02
    Updates:
    • CAG 3.3.02
    • CLS MK1 3.3.02
    • CLS MK2 3.3.02
Image

Submission Guidelines

To submit your script for possible inclusion in the Bonus pack of signed scripts, send an email to scripts@egosoft.com containing a link to your script's thread in the X3TC Scripts and Modding forum and a brief description of the script. The description should include which category the script falls under (combat, trading, piracy, etc...).

Only submit your own scripts, as you will be the person contacted to prepare the script for signing. The signing process can be a lot of work, not just fixing and preparing the scripts, but preparing the documentation and getting it translated as well.

When the email is received and processed, your script will be placed in the submitted scripts list. This does not mean that your script has be accepted to be signed. It is an indication that your email has been received. The script signing team will use this list to choose which scripts will be prepared for signing.

The script signing process is to allow the game to be expanded with the best user created content. The simpler a script is, the easier it is to check and test. They are, therefore, more likely to get through the signing process. We may make suggestions/set requirements for modifications to scripts that interest us to make them signable.
Scripts should be balanced with the rest of the game. That's to say, if you give the player something, you should take something else away. This normally takes the form of a financial cost, but may be cost to the player's reputation, or simply making the script difficult to use, or a combination.

For a script to be accepted for signing, it must:
  • enhance the original game of X³: Terran Conflict.
  • be in a finished state and bug free before it is submitted.
  • be independent of scripts from different authors, unless they give permission
  • add functionality in a similar style to the rest of the game.
A script will be rejected if:
  • it is clearly cheating
  • it is a mod
  • it changes established rules (energy free jumping, lower rep loss,...)
  • it makes major changes to the Universe (major conflicts,...)
  • it is too complicated to be properly checked and tested.
  • it is exploitable
  • it has a negative impact on the performance or stability of the game.
We will consider the following types of scripts:
  • group management scripts (preferably using wings)
  • combat management scripts
  • station management scripts
  • exploration tools
  • piracy tools
  • anything else interesting
If your script uses the “Extended Mod Pack” it must be rewritten to work without it before it can be signed.

Image

Testing

When scripts are chosen to be signed they will be posted in the [L3+] Script Testing Forum. Level 3 users can then download the scripts to help prepare them for signing. The preparation can include the preparation and translation of documentation as well as actually bug testing the scripts. The more level 3 users get involved the quicker we can get scripts to the public.

If anyone wants to know how to become a Level 3 member, please see this FAQ Entry. Once Level 3, you should be able to see and post in the Script Testing Forum. Make certain to read the rules CAREFULLY before posting. The rules are different in testing forums and are generally enforced much more ruthlessly.

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

Post by pelador » Sat, 14. Mar 09, 06:22

Could an inidcation of time be given for how long we have to ensure that scripts are in "best quality" condition including translations and then submitted in time for the testing process to be considered for inclusion in the bonus pack? Can appreciate if a "deadline" hasn't been set, but have a reasonable assumption you may have set an approximate one now.

Also can you list the languages and their corresponding numbers we must provide translations for?

User avatar
LV
Sith Lord
Posts: 8255
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by LV » Sat, 14. Mar 09, 12:47

There is an expectation that a script should be in "Best Quality" before it is sent for review ;) e.g. don't send a script for signing that you made 2 days ago, in addition it would be pointless to send any script that appears to have little or no interest in it from the wider community

Most previous plugins that were signed had extensive threads were all bugs and issues/exploits were already shown to be resolved. No scripter in the world can release any script without bugs or exploits unless it is the most simple of commands, we never see the wood from the trees and it takes the eye of other users to find them!


As far a translations people do not need to be multi-lingual the key here is that ALL text used should be contained within the t files. If you can translate then it is obviously advantageous as it means more people can test it. Translators are always needed so if anyone can translate and can help this way make sure someone on the signing team knows ;)

A plugin should also not use too many command slots or wares which would then restrict other scripts

The main language id's are below ,
7 Russian
33 French
34 Spanish
39 Italian
44 English
49 German

If nobody is available to translate to a certain language then the plugin would not be offered in any pack for that language

Moggy may be able to give more clarity on time but what would happen is a separate thread is put up in the L3 Testing forum if a script is to be tested, if an issue is reported there would be an expectation it is fixed asap and usually the author would be able to do this once he knew the issue.


Remember people, scripts get signed if if the people around here are willing to test them, lack of community involvement means a lack of bonus plugins. It's up to the S&M community to show the vanilla folks what they are missing, there is not a rack of testers sitting around waiting for something to test, most involved are usually writing and testing their own scripts in addition to testing others work, this means every little bit of donkey work must be done by the submitter of the script.

Looking through the old TR signing process will help give an insight into how it worked before.
LV's TC Scripts
Readme's For All My Scripts


I felt a great disturbance in the forum, Like millions of voices cried out in terror, then were silenced

si tacuisses, philosophus mansisses

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

Post by pelador » Sat, 14. Mar 09, 15:51

Well "best quality" isnt always the case that you have submitted poor scripting work from a functional standpoint. I have one development Peladors Drones where due to history has evolved with seperate scripting functions for each drone. However due to to crossover in similar operations, the number of files involved could be reduced by amalgamating their functions into library files. Means more scripting work to consolidate them further but for best enginneered script work would be encouraging to do even if not functionally required as potentially they perform individually without issue.

Also performance wise literal texts may be more preferable than read texts from t files dependant on flow. So while I dont see this as an issue personally and pre-loading text into arrays is a workaround for this (if aware) I can see that the translating work might not always be encouraging best scripting practice. Though in the majority of cases the benefits of being able to modify t-files is obviously preferable over scripting entries.

User avatar
perkint
Posts: 5191
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by perkint » Sat, 14. Mar 09, 16:57

Woohoo!

Never found the time to help beta testing X3TC, but since I'm already using some scripts which are bound to be submitted, I'll keep an eye on this and provide feedback on any script I can :D

Tim

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

Post by jlehtone » Mon, 16. Mar 09, 17:02

pelador wrote:Also performance wise literal texts may be more preferable than read texts from t files dependant on flow.
But literal texts are literal constants, and their use is not a good coding style.

The signed scripts will be translated. A t-file you can tanslate with any ascii editor. You cannot edit a script file like that. And imagine if you would have six copies of one script file (with the translated string literals) and then you would have to fix a genuine code bug. :shock:

Besides, doesn't the output of messages to screen take relatively more time than the memory copy of strings?

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

Post by pelador » Mon, 16. Mar 09, 19:25

jlehtone wrote:
pelador wrote:Also performance wise literal texts may be more preferable than read texts from t files dependant on flow.
But literal texts are literal constants, and their use is not a good coding style.

The signed scripts will be translated. A t-file you can tanslate with any ascii editor. You cannot edit a script file like that. And imagine if you would have six copies of one script file (with the translated string literals) and then you would have to fix a genuine code bug. :shock:

Besides, doesn't the output of messages to screen take relatively more time than the memory copy of strings?
Pelador wrote:Though in the majority of cases the benefits of being able to modify t-files is obviously preferable over scripting entries.
Thanks for confirming its more of a performance issue even if negligable in comparison to applied use. It's worth knowing these base line comparisons for best practice. So if not something to worry about in real terms is useful confirmation.

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

Post by Gazz » Mon, 16. Mar 09, 19:34

pelador wrote:Also performance wise literal texts may be more preferable than read texts from t files dependant on flow. So while I dont see this as an issue personally and pre-loading text into arrays is a workaround for this (if aware) I can see that the translating work might not always be encouraging best scripting practice. Though in the majority of cases the benefits of being able to modify t-files is obviously preferable over scripting entries.
Are you sure about that?

TFiles are only read once, at game load.
After that the entries are read from RAM because for a regular script it's pointless to re-read those values from the HDD at runtime.
The speed difference between reading the entry via page/text ID versus reading it from an array must be negligible.
You also have to take into account that array operations require many more script lines than a single read text ID so your array approach might well be slower.

But the whole discussion is pretty moot.
For any serious script you require a TFile if you release it in more than one language.
It's just the way X3 works.

Sure, I have written several scripts without a T-File but those are the kind that consist of no more than 1 hotkey label or 1 name for an AL Plugin. Some use no text whatsoever.
Not really worth the extra effort to localise this one line...
Very few scripts are that simple, though.
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.

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

Post by pelador » Mon, 16. Mar 09, 19:47

Gazz wrote:
pelador wrote:Also performance wise literal texts may be more preferable than read texts from t files dependant on flow. So while I dont see this as an issue personally and pre-loading text into arrays is a workaround for this (if aware) I can see that the translating work might not always be encouraging best scripting practice. Though in the majority of cases the benefits of being able to modify t-files is obviously preferable over scripting entries.
Are you sure about that?

TFiles are only read once, at game load.
After that the entries are read from RAM because for a regular script it's pointless to re-read those values from the HDD at runtime.
The speed difference between reading the entry via page/text ID versus reading it from an array must be negligible.
You also have to take into account that array operations require many more script lines than a single read text ID so your array approach might well be slower.
Well a string literal you define in the script. Rather than having to read from a text file entry using a function either direct from the file or from memory. So I was expecting the function to be slower than a string literal definition. However you format it after that using variables and/or combination of sprintf is irrelevant (i.e. can be handled out of loop/flow logic) as I would imagine its how you retreive the original text that was my worry.

The fact that I dont or didnt know the baseline comparison to be negligable due to how these are used was my concern. But it appears that "worry" is not something to be concerned about.

Which is very encouraging as it means the extra formatting (e.g. colours) from using t files is readily not a concern in large nested loops, likewise translation as t file use isnt an issue from what was just said. However, as I said before its only for complicated scripts with significant flow branches where I'd see it as being an issue anyhow.

User avatar
perkint
Posts: 5191
Joined: Wed, 6. Nov 02, 20:31
x3tc

Post by perkint » Mon, 23. Mar 09, 19:17

I don't suppose there's any chance of Cycrow's Improved Boarding being submitted?

Am I imagining it or have I seen comment saying Cycrow is not active on the forums anymore?

If so, any chance of someone stealing the idea? ;)

I suppose the last bit, I can answer for myself. Wonder how complex it is...

Cheers.

Tim

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

Post by apricotslice » Wed, 25. Mar 09, 03:59

LV or moggy2, is there any sort of "pre-submission ask if this fits" mechanism ? I guess this thread could function as that if you wanted it to.

My impression is that most of my scripts would be classified as either a cheat or unbalanced, but it would be nice to be able to check, without actually going through the submission process and cluttering that up with a lot of rejects.

Ones that come to mind are Cbeam, which beams all containers aboard with a single hotkey press, and Beamdock, which allows compression technology and the transporter device to beam ships on and off a carrier or TL, that otherwise cannot dock because of size. Both to me are simply extensions of the technology, but egosoft probably think otherwise. But it would be nice to get an opinion without submitting them.

Xenon_Slayer
EGOSOFT
EGOSOFT
Posts: 13088
Joined: Sat, 9. Nov 02, 11:45
x4

Post by Xenon_Slayer » Wed, 25. Mar 09, 11:23

The best thing to do is use common sense. We can quickly look at an idea and see if it is either dangerous to the game, or a cheat. For example, that Beamdock would not be considered as it is an obvious hack. It will just save us time and effort if you tried your best to filter out the scripts which obviously would never be signed. I would say, take a look at previous bonus packs to get an idea of what we are looking for.

Still, if a script is very useful and popular, but has an exploit, it could be worth to send that script and mention the exploit in the e-mail.
Come watch me on Twitch where I occasionally play several of the X games

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

Post by apricotslice » Wed, 25. Mar 09, 11:26

That what I was getting at. An obvious hack for you is filling a design flaw for me :D

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

Post by Gazz » Wed, 25. Mar 09, 12:39

apricotslice wrote:Ones that come to mind are Cbeam, which beams all containers aboard with a single hotkey press
Now in my opinion that's too "magic", too "instant", but luckily, that doesn't count for much. =P

If the cargo pods would be slowly pulled towards the ship (force position), it would be "real". It would take time and you could see it happen.
Because it takes time you would still have to protect your collector ship.
No jump in - sluuuurp - jump out of the Xenon sector without any risk to the TS.

It would be a bland X3 if all that ever happened was that you get a text message like "your PPC salvo hits Xenon K for 234525 points of shield damage".
Seeing things happen is so much prettier!
It doesn't even matter if you do technically cheat to achieve the effect. As long as you can make a convincing show of it, it's real.
The commercial agent would have been be considered a cheat if it would sell the wares from it's factory directly to the target stations. Yet, since it makes a show of freighters flying hither and tither and pilots taking courses, getting promotions... suddenly it's no cheat any more.
No difference - except for the show.

The MARS cargo collection has fighter drones swarming out to collect cargo and drag it back to the mothership and depending on how "heavy" the load is, they return rather slowly.
In effect it doesn't do anything different from Cbeam because it transfers cargo from space into the cargo bay. It's just that you can watch it happen. Those drones can be shot down while trying to do their job and when they slowly tow something back, that does happen quite a bit...

Beamdock, which allows compression technology and the transporter device to beam ships on and off a carrier or TL, that otherwise cannot dock because of size. Both to me are simply extensions of the technology, but egosoft probably think otherwise. But it would be nice to get an opinion without submitting them.
The X game design is not cast in iron. There have been too many changes to even consider that. =)
Still, docking 10 Mistral super freighters on a TL or M1 would toss cargo bay balance right out the window.
Even a single TS would more than double the cargo space of every M1 in the game and that's kinda... silly.
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.

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

Post by apricotslice » Wed, 25. Mar 09, 13:31

Silly was not being able to dock any freighter with a TL, which in X2 was designed for docking them, and used for carrying freighters around.

The least they could have done with X3, was introduced a small ship version XL freighter with a 2000 cargo bay that allowed proper ware transfer with any ship with a dock.

The fact they didnt do this, made beamdock essential to people like me.

I wouldnt use cbeam if picking up containers was actually working. But 90% of the time, collect containers does not work, because the auto-pillok is a design fault in the game.

So many of the necessary scripts are fixes to overcome the games many problem areas, that never got fixed. I understand why they dont get fixed.

My real question is why cant something that is a real fix on a problem for so many people, unable to be signed into the game ? Maybe they should do a bonus pack, and a signed "fix problems" pack and let people decide if they want both or not ? Theres no reason I can see why there should only be a single bonus pack. Those who want game fixes are left out in the cold if they dont want a modified tag.

Thats my opinion anyway, I know egosoft dont share it.



Edit : I know I'm flogging a dead horse. Most of the stuff that goes into the bonus pack, I wont use anyway. I dont use them now. The only truely useful bonus pack script from R was UT's.

I guess I'm trying to sow a seed for a different kind of pack that seeks to remedy some of the games shortcomings, giving some functionality that works in the areas of the game that cannot be fixed (eg. pathfinding, collision avoidance and auto-pilot related problems).

There are so many aspects of the game that were brilliant ideas, but never actually worked properly when implemented. So many scripts are used to overcome these shortcomings, and they do deserve to be recognised by egosoft by signing, even if they dont form "the bonus pack".

eg. Cycrows boarding hotkey is essential for boarding (there is no way to board without it presently as the boarding scripts are buggered up by the collision avoidance) until v2 comes out, assuming v2 fixes the problems. If it doesnt, then it remains essential for boarding. Even if it is fixed, those using it now are unlikely to remove it, and it would be very nice if it was signed.

Again, just my opinion, and I know I'm flogging a dead horse.
Last edited by apricotslice on Wed, 25. Mar 09, 14:20, edited 1 time in total.

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

Post by pelador » Wed, 25. Mar 09, 14:14

Although a mod will the Extended Mod Pack be considered for inclusions?

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

Post by apricotslice » Wed, 25. Mar 09, 14:21

I dont think mods get considered at all !

thats why emp is rejected, because it is a mod.

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

Post by pelador » Wed, 25. Mar 09, 15:04

Fair enough. Understandable. Just wondering as its intended as a community resource. Can live with the explicit rule no mods whatsoever though.

Zoed Vega
Posts: 383
Joined: Sat, 1. Mar 08, 18:52
x3tc

Post by Zoed Vega » Wed, 1. Apr 09, 11:47

Moderator erased post
Last edited by Zoed Vega on Tue, 4. Aug 09, 17:48, edited 1 time in total.
ALL EGOSOFT GAMES FOR SALE AT EBAY.

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

Post by apricotslice » Wed, 1. Apr 09, 12:21

Most of both their work fails the balance test as far as I can see.

If you want a quick install method, create a new directory, put the exe in there, install all scripts you want to there, zip the whole directory structure up.

When you reinstall, unzip into the game directory. Done.

Post Reply

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