Page 1 of 1

[Script] Homebase Mem / Safer Jumps / Hammerhead Detect v2.01

Posted: Sat, 10. Feb 07, 21:24
by Gazz
Der entschrechende deutsche Thread ist hier.

Download: Homebase Memory v1.01 . . . ZIP
Homebase Memory + Safer Jumping v2.0 . . . ZIP + SPK

What the script does:
Whenever I teleported into a fighter the game deleted the Homebase I set.
I never got the reasoning behind that one. I mean if I didn't want it set I wouldn't have done so in the first place, right?

So I stopped that.
When I now leave one of my small ships the homebase is set to what it was before and a small doubleclick sound is played for confirmation.

It will not be possible to play the main quest while keeping this script running at all times.
The story moves the playership around in a way that is indistinguishable from a jump and the automatic relocation feature would play havoc with the story script.

What you can do is temporarily disable the script by calling up the script editor,
looking at "Global Script Tasks" and
deleting "plugin.gz.rem.home.main".

This will temporarily disable the script - until the next time you reload the game.
It is also safe to uninstall the script file after you have deleted the running global task.

v1.01: Now works with Bunny's Weapons Changer v1.45.
The IS/OOS weapon switching is turned off when the player enters the ship so my script always turns it back on...
- if Bunny's script is running on the ship
- if Player just left the ship.

v2.00: Safer Jumping (includes v1.01)
You jump to another sector in your TL and 3 sec later you hear AAAAaaaargh. $%^)!@($&! Another freighter just turned into roadkill.

Also some cap ships consistently destroy themselves when leaving a dock. It may be just my personal opinion but I find that utterly idiotic.

v2.00 will move the playership 2.5 km upwards (or more, depending on size and obstacles)
- if you emerge from a jumpgate
- if you leave a dock or station.

This only affects the ship that you fly personally.

v2.01: Unknown Object Detector
In a Xenon sector the missile warning is basically always on and after a while you ignore it.
Most missiles can safely be ignored but that is not wise with Hammerhead und Firestorm.

If one such missile is launched at you it will be targeted and a warning given.

This warning is only given once so you can choose to ignore it and continue to fight.

If you clear your target while a Hammerhead is still incoming the missile will be targeted again.
Note that a double tap on "t" will clear your target but disable target search so the target stays cleared.

This allows for a quick check if this missile is still chasing you because in a heated fight you can not always keep track of everything. That's what we have computers for, right?

Care and Feeding:
No command slots or any other kind of resources were used.

Manually deleting a homebase still works because I replaced the regular Delete Homebase script with one that has one added line for deleting the sekritly saved homebase.

An "undocumented" feature is that it also turns turrets back on using Klyith's Turret on/off Hotkey V1 (3.16.07)
Lines 51-54 are remmed out because it does not work with the normal Turret on/off Hotkey script. All references in the script point to [PLAYERSHIP] instead of a variable so it would not affect the ship it had to (for this use).

For personal use I changed Klyith's script and added

Code: Select all

002   $Ship = [THIS] 
003   skip if $Ship 
004    $Ship = [PLAYERSHIP] 
and changed all references to [PLAYERSHIP] to $Ship.

I will not release this script for obvious reasons but everyone is welcome to do this if they would like this functionality. =)

Posted: Sat, 10. Feb 07, 22:43
by Klyith
The main script calls plugin.gz.rem.home.memory, but it is missing from the zip file. This seems like an important omission. ;)

Aside from that, your global script method looks like a convenient, no-player-input-required way to solving the problem. Nice idea. Also the playing time as validation idea you came up with is quite clever.

Posted: Sun, 11. Feb 07, 00:33
by Gazz
Woops, yer right.
I gunna have to work on my counting-to-four skills.

Its up now. Fo real.

For many the homebases being cleared wont be a problem at all because they use fancy carrier command scripts which make homebase settings obsolete or actually work better without them.

I just wanted a simpler solution for my uhh... fleet.
An elephant with 3 novas and an LX. Half of those captured.
Owell. Im a builder, not a fighter. =P

All I wanted to do is snap my fingers and say Return home. ALL OF YOU.
And that didnt work half the time...

And thanks for the flowers. =)
As long as it doesnt affect a global script whether it's restarted or not this is a way of making 100 % sure only one instance can be running.
I thought about other ways but if someone manages to double hit "reinit scripts" quickly (spawning 2 instances) and they only use a general "script running" global variable there is no way to prevent mroe than 1 instance from thinking that it is "the" script.
And the other way around, if someone terminates the global script while it is flagged as "running" things stop working, too.
By telling "the" script that it is indeed the one and all others are wannabes this is always cleared up. While it is technically possible to spawn 2 instances (quickly hitting Reinit Cache) this will clear itself up automatically on the next reload when they are both terminated in favour of a fresh instance.

Actually, this can be adjusted to work with global scripts that must not be terminated at will.
They all take note of the play time when they were started. This is their ID.
A new instance that is starting sets the global status variable to null and listens for a minute.
An already running script would constantly set the status var to its own ID number so if the new script sees that "some" script changes the variable, it terminates before starting it's actual work part.

In my last 2 scripts I used a different approach to CPU use.
When the number of objects (be it minefields or ships to watch for homebases) increases, the game is not slowed down by the script doing more work but the script runs slower instead.
The scripts may be a little less effective but that's not a real issue. Having one certain script run perfectly while the game gets unplayably slow doesnt sound like fun.

Posted: Sat, 17. Feb 07, 21:44
by Khaak_Slayer
So is this new version fixed? I'm not sure if the aforementioned was the cause, but every time i went to use this my game would completely lock up upon loading. I'll re-download and try again.

Posted: Sat, 17. Mar 07, 12:49
by Gazz
v1.01 released.

Posted: Sun, 18. Mar 07, 10:32
by Mobuj
Thanks for getting rid of that annoying feature. :thumb_up:

Posted: Sat, 31. Mar 07, 14:45
by Gazz
v2.00 released.

v1.01 still available for those who do not wish to use the Safer Jumping capability.

Posted: Fri, 6. Apr 07, 22:47
by Gazz
v2.01 released.


Posted: Sat, 9. Feb 08, 21:31
by Kienja Kenobi
I am running X3 2.5 with XTM 0.7 and version 2.01 of this script. I believe I have found several problems with this version of the script, which not only remembers home bases, but also makes jump gate travel safer.

When I uninstalled this script (Using the Script Manager), any game I load that had been saved while the script was active will freeze the moment the game begins. This script does not place any settings in the Artificial Life menu, so the only possible way to disable it is by uninstalling the script files, which freezes the game.

Furthermore, this script breaks the main quest.
The quest that takes place right after Kyle Brennan wakes up from his comma requires traveling through a tunnel inside an asteroid. The safe jump gate aspect of this script works by shifting the player's ship several meters away from a point of entry. When the quest first starts, with the player ship inside the asteroid, this script treats it like a jump gate entry point and immediately shifts the ship to a point outside of the asteroid's tunnel. I never found a way back into the tunnel, but even if I could get back inside it would be very difficult to complete the mission inside the time limit.
Therefore, I do not recommend the 2.01 version of this script; however, the original 1.01 version that does not include the safe jump gates aspect works without the issue of breaking the main quest. Because I still can not uninstall this script, I had to remove the 2.01 files and install the 1.01 files, which kept the game from freezing and does not try to move my ship at points of entry.

Posted: Sun, 10. Feb 08, 04:59
by Gazz
You should be able to uninstall it by killing it's global task in the script editor, then saving the game and deleting/removing the script file.

If you don't kill the global task first it will try and run the script you "uninstalled", freezing the game.

I did not know this would break the main quest because I never played it again after having so much fun in the last mission...

Posted: Sat, 16. Feb 08, 14:23
by Gazz
If I knew all the story missions and script enforced jumps I could disable those places for my script but I only played the main quest once, long long ago...
Given the "fun" I had on the last mission I do not plan to repeat that experience. =P

Trying to uninstall

Posted: Thu, 2. Oct 08, 10:20
by JImmyrosso
Hi Gazz

Great scripts all round!

But ive tried to uninstall this script but having the same problems on freezing the game. Youve probably been asked a million times : how do you make the changes to the Global script? so i can remove it successfully.



Posted: Thu, 2. Oct 08, 11:53
by Gazz
See 2 posts above.

Posted: Thu, 2. Oct 08, 17:26
by JImmyrosso
cheers Gazz

i will give it a go and see how easy it is to make the change on the global scripting! i pray its simple enough.....