[SCRIPT] x0ne Turret Control System (TCS) 1.02 [UPDATED 31/12/2010]

[x0ne]

Thanks man, tell me what ship you were in and I'll see if I can reproduce it.

[surferx]

What confirmation do you get when the system is active? I got the 100% installed message. Then I set my hotkeys but I don't think it's working in my game. I am in a LX and have A/Bpac, A/B HEPTs - no new weapons, but I don't get a confirm when I key in the Master Key. I think I may still have issues in my install of XTM. I'll get back and mess with it some more. Thanks. Looks like a useful mod tho.

[x0ne]

What confirmation do you get when the system is active? I got the 100% installed message. Then I set my hotkeys but I don't think it's working in my game. I am in a LX and have A/Bpac, A/B HEPTs - no new weapons, but I don't get a confirm when I key in the Master Key. I think I may still have issues in my install of XTM. I'll get back and mess with it some more. Thanks. Looks like a useful mod tho.

Ok, make sure you've bought the x0ne TCS Interface from an Argon or Split EQ dock. If you don't have this on board, the hotkeys will sound a 'null' beep (the same one you get when you're trying to scroll too far on the menus).

Once the TCS Interface is aboard your ship, the turret commands themselves become available. Using the Master Switch without any of the commands running on a turret will result in an error beep and vocal prompt "not available". The Master Switch can only be used once you're running one of the commands on a turret, so start one up.

Now the Master Switch will sound like the other hotkeys - a two tone beep to tell you something has been switched off (in this case, all your turrets), and a vocal prompt of "ready" to tell you they're back on again.

Please let me know if you've any more questions, thanks for the feedback!

[x0ne]

Yeah, I checked the turret loadouts and it was 100% flaks at the time. I'm also observing this from an external view. I've had some instances with targets being fired at when they're more than double the flaks range, at least from what I can tell visually. It's really not a big deal, just thought I'd share anything funky that I saw with ya.

This is quite a big deal for me, so I've been testing all evening!

You've def. found something weird going on here, but the strange thing is it's not my scripts, nor does it always happen...

I used the (huuuuge) Valhalla for the testing with a modified version of the scripts (setting a turrets target as my tracking aim so I could follow it better). You can quite clearly see that the left and right turrets continue to fire while the target is well out of range (and yes, I think you're right about it being doubled). It's only the left and right turrets though, and it's every weapon, not just flaks.

I've observed the same behaviour with the default turret commands too, so that rules out this plugin.

The most irritating thing about this? It doesn't always happen, I cannot for the life of me reproduce it for certain, so I don't know what it is?! Everything does work (i.e. ship model, turret commands, weapons), it's just that from time to time, something goes wrong, which after a time miraculously fixes itself...

I'd understand it if I were totally caning the script engine - I've seen some weird stuff happen in the past due to inefficient code, but this has me totally stumped. I guess it's just a bug in the game of some sort?

Please let me know what ship you saw this on mate, I'm not convinved it's ship specific yet, but I've tried it on the Tyr without seeing it yet, so who knows?

[x0ne]

I think I may have an answer as to the cause of this weirdness, but I won't be able to confirm until I get home.

(prepare yourselves for an essay)

Did some more testing last night because of insomnia, and I've been going over everything in my mind ever since, trying to find a pattern. There are some very important observations/facts to take into consideration:

1. I noticed that starting the weapon switching commands on all turrets was actually a consistent way of reproducing the problem.

2. Stopping the turrets and running one of XTMs scripts to mount anti-fighter weapons (FAAs in this case) made the problem go away.

3. Once the issue had 'started' (it was persistant), the EGOSOFT turret commands would also fire at out of range targets (this is for definite, tested and confirmed with just a single ES command running on a ship, nothing else).

4. Whilst testing on a Terran Tyr, certain turrets would retain their lock on a ship even when it had flown to the other side of the Tyr and was outside of the turrets field of fire (i.e. the turret couldn't even point at it!).

5. The method of checking if a ship is in range of a turrets weapons and inside it's field of fire is just one command in the script editor. This is a fundamentally simple check, and is continually checked within a 'firing loop' while the turret has a target.

I'm theorising that the turret configurations on some new ships (I've only tested the Terran Valhalla and Tyr) in XTM are somehow flawed (maybe an error in the scene files or TShips that's not immediately obvious?).

My reasoning for this came about while thinking about what happened on the Tyr, how on earth (no pun intended) were those turrets reporting their target was in firing range? Then it hit me, what if via some sort of error, guns from a different part of the ship were being included when working out if a target ship was in firing range? Seems far fetched when you consider the modding experience the XTM team have, but have a read of this:

1. The weapon switching commands mount 1 x of the longest ranged weapon available when they're scanning for a target - and in the case of this testing, PPCs. If a PPC was mounted when the commands were stopped, it would obviously remain in that turret.

2. Most of the testing I did was on one turret at a time, and with a fixed loadout of FAAs because they were easier to see. During this testing the other turret loadouts were not changed, and some had PPCs mounted.

3. Mounting FAAs all round with the XTM script made the problem go away, unitl I started up the weapon switching commands again.

What I'm getting at is that when testing with FAAs, there were definately PPCs mounted in other turrets, and these have a greater range. It seems like too much of a coincidence that this problem started and stopped with the addition and complete removal of the PPCs don'tcha think?

I'll be testing this tonight via manual addition/removal of PPCs while testing with other weapons. I'm hoping that if I can prove this theory, I'll also be able to work out which turrets and guns are linked to each other in error, and then get that info to the XTM team.

Phew!

Please remember this is just a THEORY based on my observations last night, nothing at all has been proved, so please don't go spreading any unecessary rumors ok?

[x0ne]

OMG I was right!

I'm going to raise this as a bug on TXU tech support and post the details here once I'm done. Back soon.

EDIT:

Ok, the long and short of this is that slots on other turrets are being queried when determining if a target is in range. For example, lets say turret 1 has 4 x FAAs mounted, and turret 2 has 4 x GPPCs. The script engine checks if a target is in range of turret 1, but slot 0 on turret 2 is included in that calculation for some reason. Turret 1 has effectively 5 slots now and a mixed loadout, so the range of the turret equals that of the longest ranged weapon, i.e. the GPPC at slot 0 turret 2. When turret 1 fires, it's only with the FAAs, even though the target could be outside their range.

On the Valhalla and Tyr this is as follows:
Front - OK
Right - includes Back slot 0, 1, 2
Left - includes Up slot 0, 1, 2
Back - OK
Up - includes Down slot 0, 1, 2
Down - OK

The Tyr also exhibited further anomalies not present on the Valhalla. Not only were the listed slots included in the range check, but also the field of fire of the included turret (the turrets could establish and maintain a lock on targets only the included turret was able to hit).

The conclusion? This is nothing to do with my plugin! I'm working on a proper XTM version though, but it won't be able to work around this issue if it's not fixed by the XTM team.

[kamikazepenguin]

I just wanted to say that I love this script. It's solved a lot of the issues I've had with micromanaging turrets.

[x0ne]

I just wanted to say that I love this script. It's solved a lot of the issues I've had with micromanaging turrets.

Thanks for taking the time to tell me, really appreciated!

(x0ne feels all warm and fuzzy now)

[surferx]

Ok, make sure you've bought the x0ne TCS Interface from an Argon or Split EQ dock. If you don't have this on board, the hotkeys will sound a 'null' beep (the same one you get when you're trying to scroll too far on the menus).

Once the TCS Interface is aboard your ship, the turret commands themselves become available. Using the Master Switch without any of the commands running on a turret will result in an error beep and vocal prompt "not available". The Master Switch can only be used once you're running one of the commands on a turret, so start one up.

Now the Master Switch will sound like the other hotkeys - a two tone beep to tell you something has been switched off (in this case, all your turrets), and a vocal prompt of "ready" to tell you they're back on again.

Please let me know if you've any more questions, thanks for the feedback!

OK I'm sure that's all I need, I had not bought the TCS Interface. I think I started reading the readme at part 2- Installation.
I will have to get back to you, and I will eventually, re. performance of the mod. It seems I don't have the 18 mil in credits just yet.
Just beginning my 3rd day for this game and I've put my funds toward UTs and facs. ( And I've never had any desire to use cheat codes. That and running the game on seta only cheapen a great game. IMHO. ) As soon as I raise the funds I'll purchase and give her a go.
Thanks for the time and effort you put into this mod. It's obviously taken much of both, but it looks like an excellent piece of work.
Later.

[x0ne]

It seems I don't have the 18 mil in credits just yet.

Yeah sorry about the price tag, but it's representative of what the plugin can do, and that it's not intended for general fleet-wide use.

I think of it like this - x0ne Systems Inc. is a small company operating out of Getsu Fune. The TCS Interface is a serious piece of kit made from military grade hardware, and given the current state of war this is pretty difficult to source. Production is therefore limited, and the price reflects that.

You could always script it in and take it for a temporary test drive? It only becomes cheating once you've saved your game...

[surferx]

Yeah sorry about the price tag, but it's representative of what the plugin can do, and that it's not intended for general fleet-wide use.

I think of it like this - x0ne Systems Inc. is a small company operating out of Getsu Fune. The TCS Interface is a serious piece of kit made from military grade hardware, and given the current state of war this is pretty difficult to source. Production is therefore limited, and the price reflects that.

Yeah, I can see that. You can relate it to- one I really like, just for example, Cycrow's Salvage Claim Software; which is about 1/3 the price of your TCS but only claims ships, whereas the TCS does a lot of things. And the TCS can help pay for itself by not shooting up cap ships. I usually lose 1/2 million every time I cap a LX because my turret keeps hammering away. BTW I wasn't complaining of the price, just letting you know...

You could always script it in and take it for a temporary test drive? It only becomes cheating once you've saved your game...

That's a good point. I may just do that. Now where's that cheat script......

[x0ne]

Yeah, I can see that. You can relate it to- one I really like, just for example, Cycrow's Salvage Claim Software; which is about 1/3 the price of your TCS but only claims ships, whereas the TCS does a lot of things.

Indeed!

And the TCS can help pay for itself by not shooting up cap ships. I usually lose 1/2 million every time I cap a LX because my turret keeps hammering away.

Yeah, Capture Mode is something I've wanted in a turret plugin for a long time. The Rescan Targets hotkey can also be used to stop your turrets from nailing a ship you didn't intend to cap (although this isn't what I designed it for) - just hit it when you hear a pilot telling you he's gonna bail...

That's a good point. I may just do that. Now where's that cheat script......

Muhahahaaa, another convert to the dark-side!

[x0ne]

Just so you know, version 1.01 of this plugin is available for download and the old version is no longer supported.

All that's changed is the ship command slots, this was done to make it XTM compatible. A version of this plugin that has been fully tuned for XTM will be materialising sometime in the future - stay tuned!

[surferx]

All that's changed is the ship command slots, this was done to make it XTM compatible.

Nice.!

A version of this plugin that has been fully tuned for XTM will be materialising sometime in the future - stay tuned!

I really, really want this when you are done. XTM is so cool I will never play vanilla again.

[crackenspank]

Sorry I didn't get back to ya sooner. I sorta came to the same conclusions as you though. Obviously I don't have nearly the scripting expertise that you do, but I had a feeling it was linked to non-active turrets being equipped with PPCs and their ranges taken into account. And yes, something I didn't really notice, but is quite true, is the fact that you only really see this problem with the left and right turrets.

Glad you got it all sorted though, and hopefully the XTM team can work something out for this. If not, it's really a minor issue...it's kinda cool in a way, like your ship is setting up a flak barrier, BSG style.

[surferx]

I got the message referred to in section 2.1 of the readme: screenshot
"The above message will also be received erroneously under the following conditions, but
these will only occur in extreme cases where either the XScript Installer program isn’t
functioning correctly, or you have deleted files from your X3 install location:
• plugin.scriptmanager.getware.xml is missing from the scripts directory.
• 447400.xml is missing from the t directory."
I have both these files in the scripts and t directory. I have not deleted or altered any of the files from the X3 install.
I will reinstall tomorrow but I have no idea what caused this. The XScript Installer seems to be working fine and I have not reconfigured or edited or deleted any files at all. I just started the game and got the warning.

[x0ne]

I got the message referred to in section 2.1 of the readme: screenshot

Thanks for bringing this to my attention surferx, I'm pretty sure this has been caused by an issue external to the plugin though. You see, the check for the custom ware I'm using is a fundamentally simple one - if Cycrow's script plugin.scriptmanager.getware.xml returns a null value, you get this error - there's no other way of receiving it.

We can still probably get to the bottom of this though, so could you check the following please and get back to me?

Firstly, reboot your system. Then, in the XScript Installer, please check if Custom Wares are still enabled. You could even try disabling and enabling them again to make absolutely sure the installer knows you want to allow their use. After you've done this, close down the installer and run X3 - still a problem?

If the problem persists, it would be useful to know the following:

Have you installed/removed/changed anything using the XScript Installer before the error?

Has the Xscript Installer crashed on you at all when you've closed it recently?

Is this always happening when you load your saved game, or was it just the once?

Does this happen when starting a new game?

I've found that most problems like this can easily be solved by re-running the XScript Installer (it crashes on me from time-to-time), but if we can't find a solution, it might be an idea to get in touch with Cycrow regarding the Custom Wares.

One more thing, I noticed in the error that you're running version 1.00 of the plugin. It might be an idea to upgrade to 1.01 as this is what I'll be running with XTM when trying to re-create reported problems. Upgrading might even fix the issue!

[surferx]

I got the message referred to in section 2.1 of the readme: screenshot

Thanks for bringing this to my attention surferx, I'm pretty sure this has been caused by an issue external to the plugin though. You see, the check for the custom ware I'm using is a fundamentally simple one - if Cycrow's script plugin.scriptmanager.getware.xml returns a null value, you get this error - there's no other way of receiving it.

We can still probably get to the bottom of this though, so could you check the following please and get back to me?

Firstly, reboot your system. Then, in the XScript Installer, please check if Custom Wares are still enabled. You could even try disabling and enabling them again to make absolutely sure the installer knows you want to allow their use. After you've done this, close down the installer and run X3 - still a problem?

No, I updated to 101 and re-enabled the mod. I got the message 101 installed successful.

If the problem persists, it would be useful to know the following:

Have you installed/removed/changed anything using the XScript Installer before the error?

No

Has the Xscript Installer crashed on you at all when you've closed it recently?

Now that you mention it...It did crash; but I was able to open it again so I didn't think any more of it. I'll bet that caused the conflict, don't you think?

Is this always happening when you load your saved game, or was it just the once?

Once.

Does this happen when starting a new game?

Cannot start a new game ATM; but this is an entirely separate issue. I have some kind of other conflict going between the Script Installer and XTM. Cycrow is working on ver. 2.0 which should fix the new games prob. And anyway I can play the saved files, so OK for now.

I've found that most problems like this can easily be solved by re-running the XScript Installer (it crashes on me from time-to-time), but if we can't find a solution, it might be an idea to get in touch with Cycrow regarding the Custom Wares.

No need. Problem solved.

One more thing, I noticed in the error that you're running version 1.00 of the plugin. It might be an idea to upgrade to 1.01 as this is what I'll be running with XTM when trying to re-create reported problems. Upgrading might even fix the issue!

Either the upgrade or re-installing fixed it. Thank you very much for the assistance.

[x0ne]

Now that you mention it...It did crash; but I was able to open it again so I didn't think any more of it. I'll bet that caused the conflict, don't you think?

Absolutely, I'd put money on it. When you exit the installer, this is when it does most of (if not all) of its modifications to your X3 install. A crash at this point would mean it didn't have a chance to do everything it needed to, and in my own experience this has caused me problems on a few occasions - simply running and exiting the installer fixes them.

Seeing as you only saw the error once, it sounds like this is what you did anyway without my prompting you to?

Thanks for the info surferx, I'm glad to hear it's all ok now!

[x0ne]

Slightly stupid of me, I'd left some debug code in a few of the version 1.01 scripts. If you've downloaded that version before I posted this update, please download it again, re-install, and restart any running turret commands from this plugin.

Sorry about that...