[SCRIPT] Attack Rocks Command v2.10 [UPDATED 26/8/07]

Bunny · Post by **Bunny** » Sun, 27. May 07, 11:56

I ran into the same problem last night wth my silicon mine.
Stopping and restarting the script cleared it, they delivered properly after that. I am looking into why this happens.

Alkeena · Post by **Alkeena** » Sun, 27. May 07, 17:40

Is there any chance you could separate the break/destroy decision from the combat software installed? I like to keep mosquito missile defense running on pretty much all my ships. I would like mosquito defense AND break, not destroy.

jumbled · Post by **jumbled** » Mon, 28. May 07, 04:04

Bunny wrote:I ran into the same problem last night wth my silicon mine.
Stopping and restarting the script cleared it, they delivered properly after that. I am looking into why this happens.

Tried stopping and restarting individual ships when they ding at me after returning to base, but they just ding again and sputter around the system till I take manual control. The only way, so far, is to manually unload them and then send them out again fresh.

I don't know what mght be the cause, but it started doing this after dropping those replacement files into place. All I can think of is I'm using the SPK version of the mining script, but I noticed the T file you included in the zip looks like it might be part of the X3plus set (it didn't replace the existing one already installed, like the scripts did and has a lot of extra stuff in there besides mining texts), so this makes me wonder about version compatibility.

jumbled · Post by **jumbled** » Tue, 29. May 07, 07:40

Well, I sat down tonight and once again waited for my mining ships to beep at me that they aren't working right. So I decided to find the trouble and fix it. And I think I may have found your problem....

Look in the script plugin.bms.mainscript, at line 108. You have a call to the script plugin.bms.dockedtasksv2 in there. After a bit of searching, I found this line to be different than in your previous version (from the 3.0 SPK file).

Here's how it *seems* to be working to me... If I install the older script file into X3 (it has version 300 on the top), go into the editor and look at the list of scripts available, I do not see the dockedtasks file listed. If I go into the mainscript file and then exit back to the listing, NOW I see the other script. Not so with your new file (v 305). I noticed this sort of by accident.

The reason being, it seems your new file calls the other script as "plugin.bms.dockedtasksv2" (small 'V'), whereas your old v300 called it "plugin.bms.dockedtasksV2" (big ''V"). Also, in your new 305 file, the parameter after the script name reads "???=$WorkSector", but the old v300 file shows it correctly.

So, in your 305 file, I replaced the script call to point at the file again, and I just had two ships apparently go in to unload and neither of them complained. Previously, every ship had troubles.

I do need to stop and restart the script, it seems, to get it running correctly, though.

I'm guessing ether the call name is case sensitive with the name "inside" the other script (not the actual filename), or else this bugger is REALLY finicky about linking stuff.

Bunny · Post by **Bunny** » Tue, 29. May 07, 10:15

Thanks for looking,
Lucike renamed the files to bring them in line with the signed script rules.

ttl · Post by **ttl** » Tue, 29. May 07, 13:39

So, has the problem with script name capitalization been fixed in the correction files now? So should I re-download, or should I go digging into the file myself?

Bunny · Post by **Bunny** » Tue, 29. May 07, 14:40

The correction files do not contain this fix.
It would be quicker to edit the mainscript at line 108.

The next upgrade will be an spk file. This way it I can keep an eye on things in future.

jumbled · Post by **jumbled** » Tue, 29. May 07, 23:38

This thing is starting to piss me off (not necessarily your script, the whole program).

I had it working last night. I fixed the line in the script to point at the file again, and went back to a save without the editor active (I don't like to keep it active in my "official" game since I don't like the 'S' cmd in my menu). It ran and all my ships were docking and unloading as usual.

I shut down for the night (after several more hours of play

) and today I go back and the ships are dinging at me again that they can't dock/unload. I go back into the editor and see the dockedtasks file is not loaded in the list of scripts available...not until I go into edit mode on mainscript, which somehow "initializes" the load of dockedtasks. Why doesn't it load on it's own? I stopped and restarted the game last night in the same way as this morning, and it worked fine.

jumbled · Post by **jumbled** » Wed, 30. May 07, 01:21

(sigh) I'm back...again. Sorry for so many posts, I feel like a bit of a nag now, but I am working this problem through, piece by piece.

I think I found problem #2, and this time it's inside plugin.bms.dockedtasksv2.

My troubles have been with a ship carrying a load of silicon. You said in an earlier post you also had a problem with a load of silicon, right? Well, in and among all the things I've been trying from my previous posts, I had something interesting happen to me.

I was stopping and restarting the script over and over trying various things, like init'ing the dockedtasks script manually (that is, to get it in the list of loaded scripts), checking and rechecking the mainscript for anything I missed before, etc., when on one of the restarts, my ship, loaded with an *almost* full cargo of silicon, decided to go out, reset the beacon and get some ore. It had just enough space for 2 units of ore before returning to unload.

When it got back to the station, I watched and it apparently docked (which it seemed to be doing each time it returns), and then undocked and dinged at me....again. BUT, I looked in the freight menu and it did NOT have those 2 pieces of ore, just the silicon. This gave me a clue...so I looked in the dockedtasks file to see what's going on.

There is an IF...ELSE structure on line numbers ranging in the 20's and 30's (mostly) where you test to see if the homebase is a TL vs a station, and if the station takes ore, silicon or Nvidium. The conditional, as it is written, assumes only ONE type is taken, and falls out of the structure after processing that one type, in this case ore comes first.

My stations often take BOTH ore and silicon (silicon for power and some mid-level tech, ore for the main products), so if a ship comes in, it sees ore first and goes to sell, then falls out of the IF statement to the part where it basically leaves the station. If it was full of silicon, it doesn't get sold and THEREFORE, in mainscript, it sees a full cargo and dings.

The problem was solved by changing the complex IF...ELSE IF...ELSE IF...END to a series of IF...END for each ore type, effectively causing it to repeat the sell process for everything that might be in there before leaving.

I tested it by running the script on my trouble ship with the silicon. It docked, sold and left. I have other ships already docked (I stopped the script on them earlier), so I loaded up one with a combination of ore and silicon, ran the script and watch him leave port. I looked in his cargo and it was empty (he sold before leaving). Filled up a second ship in port, undocked him and then ran the script, and it seems he went out to establish a beacon, then returned to sell and is now back out mining again.

BTW, I ran these tests after exiting and reloading X3 without going back into the editor and manually loading that dockedtasks script, so this doesn't seem to be an issue now.

Let's see if it STILL works this way tomorrow!

Bunny · Post by **Bunny** » Wed, 30. May 07, 11:02

Just for the record
Lucike restructured the script in version 3.00.

I am just as cheesed off fixing bugs that were fixed.

jumbled · Post by **jumbled** » Wed, 30. May 07, 11:16

Bunny wrote:Just for the record
Lucike restructured the script in version 3.00.

I am just as cheesed off fixing bugs that were fixed.

I've had it running all day now and not one complaint out of any of my ships. I also noticed one group has migrated to a new area in the sector. They must've finished off all the rocks in the first cluster.

Bunny · Post by **Bunny** » Wed, 30. May 07, 16:15

jumbled wrote:(sigh)
There is an IF...ELSE structure on line numbers ranging in the 20's and 30's (mostly) where you test to see if the homebase is a TL vs a station, and if the station takes ore, silicon or Nvidium. The conditional, as it is written, assumes only ONE type is taken, and falls out of the structure after processing that one type, in this case ore comes first.

The problem was solved by changing the complex IF...ELSE IF...ELSE IF...END to a series of IF...END for each ore type, effectively causing it to repeat the sell process for everything that might be in there before leaving.

@Jumbled - Take a look at the code in the third post up from the bottom in this link.
http://forum.egosoft.com/viewtopic.php? ... &start=165
Is that the code you fixed?

I ask because that would mean this bug had been fixed and then reintroduced again.

jumbled · Post by **jumbled** » Wed, 30. May 07, 23:22

Yup, that's the section I found in my copy here. Was IF...ELSE IF, and I changed it to IF...END.

As they say, great minds think alike. Too bad some of us also think backwards on occasion.

(I should probably learn German one of these days...this isn't the first game I've had to "edit" with German language references in scripting.

)

Bunny · Post by **Bunny** » Sun, 15. Jul 07, 11:55

Version 2.02A released - Minor interface change
- Command now only appears in combat menu when a mineral scanner is installed.

Cheers

Bunny

No other changes.

Bunny · Post by **Bunny** » Wed, 1. Aug 07, 00:05

Okay version 2.06
http://www.xai-corp.net/files/xaicorp/p ... s-2.06.zip

The changes are
1. The command will not show in the menu if the ship has no weapons in the turrets (JMCorp )

2. Additional check for fight command MK I software while the script is running.

3. The ship will not move around as much when destroying rocks.
(breaking rocks behaviour remains the same - they have to keep moving to help mobile mining ships equally)

4. The ship will only shoot "Nividium" rocks in the vicinity of a navsat or beacon with this word in the satellite name (it already does with "Silicon" and "Ore").

Additional notes about the way the ship works

A. The ship will not destroy rocks around a mobile mining ship's navigational beacon. It will break them instead.

B. If a sector contain mobile miners then the rock breaking ship will fly only to their navigational beacons.

C. If no miners are present then the rock breaker flies to navigational satellites to look for rocks.

D. If the sector is completely empty then the breaker will use its scanner and make random searches till it finds something to hit.

E. If a satellite or beacon contains the word "Ore", "Silicon" or "Nividium" in the name then the breaker will give priority to seeking out rocks of this type.

Bunny · Post by **Bunny** » Mon, 6. Aug 07, 00:27

Version 2.09 - additional control over which rocks the ship will shoot.

- Placing the keyword "Ore", "Silicon" or "Nividium" in the ship name will force it to break/destroy only rocks of that type.

If a keyword is not included in the ship name then it will still check for it in the name of the navsat/nav beacon it flies towards. These are the two ways the ship can be restricted in its choice of rocks.

Keyword in ship name takes precedence.

Bunny · Post by **Bunny** » Sun, 26. Aug 07, 13:23

Minor t file fix.

argon_emperor · Post by **argon_emperor** » Sun, 16. Sep 07, 04:30

If I give the Destroy Rocks command to a carrier, will any fighters homebased to it also take up the command?

Bunny · Post by **Bunny** » Sun, 16. Sep 07, 12:10

Nope, the command will need to be started on each ship individually.

Nikolka · Post by **Nikolka** » Fri, 25. Jun 10, 11:43

Hello! Does this is mod probably adapt for terran conflict?