@ jlehtone- If you are asking to me, I don't really know..
If so, I believe I could live without it then, just thought it might be a neat option, but hey, if it is way too complicated, then no need- this script (it is a script for now, right?) is very, very good, just for that immersion factor.
[SCRIPT] Attack Rocks Command v2.10 [UPDATED 26/8/07]
Moderators: Moderators for English X Forum, Scripting / Modding Moderators
It could be done as an AL plugin.
But to be honest I think most people prefer to have just one sector at a time undergoing mining for performance reasons.
They may get miffed at a bunch of NPC miners lowering FPS while they work and flooding the local market with minerals.
[EDIT] From my game it looks like the NPC mines have plenty of stock, its just the NPC ships are not delivering it to the weapon fabs.
Then again, if the economy was perfect then the player would have no niche.
But to be honest I think most people prefer to have just one sector at a time undergoing mining for performance reasons.
They may get miffed at a bunch of NPC miners lowering FPS while they work and flooding the local market with minerals.
[EDIT] From my game it looks like the NPC mines have plenty of stock, its just the NPC ships are not delivering it to the weapon fabs.
Then again, if the economy was perfect then the player would have no niche.
Ah, I see, thaks for the reply anyway 
True, performance issues thing did not occur to me..
But if it could be an AL plugin, then it could be switchable on/off, right?
Anyway, I'm not saying you should start doing this, atleast not before more people say that they want such a thing, I'm just throwing of (rotten- spoiled or non-developed, i mean) seeds of something that can blossom very nicely in a fine soil (I hope I did get that saying right, never tried to translate it)
Regardless, your scripts (atleast these two) are one of those things that X3 badly needed, so, a thousand "thank you"s from me!
True, performance issues thing did not occur to me..
But if it could be an AL plugin, then it could be switchable on/off, right?
Anyway, I'm not saying you should start doing this, atleast not before more people say that they want such a thing, I'm just throwing of (rotten- spoiled or non-developed, i mean) seeds of something that can blossom very nicely in a fine soil (I hope I did get that saying right, never tried to translate it)
Regardless, your scripts (atleast these two) are one of those things that X3 badly needed, so, a thousand "thank you"s from me!
I was using an earlier version of your mining script in a previous game. I first experimented on an asteroid that I broke up, to see how long it would take using some number of ships (and to test the theory that asteroids respawn after mobile mined). Took several days to clean up completely, and the original asteroid came back shortly thereafter.
I think using this new set of scripts and having fighters take the job of breaking things up (which leaves the TS's to just pick up ore), should make the process go a little faster. I'm working on building up a large fleet of mining ships to speed things up. I don't think you need a huge number of fighters to break things up...TS's can't keep up with the process that quickly anyway. I put 3 M5's on the job in each of 2 sectors I'm mining currently. No noticable lag issues that I can see so far.
I think using this new set of scripts and having fighters take the job of breaking things up (which leaves the TS's to just pick up ore), should make the process go a little faster. I'm working on building up a large fleet of mining ships to speed things up. I don't think you need a huge number of fighters to break things up...TS's can't keep up with the process that quickly anyway. I put 3 M5's on the job in each of 2 sectors I'm mining currently. No noticable lag issues that I can see so far.
For some reason, M3s appeared to me much more effective than lighter fighters on "attack rocks". At least OOS. (When I tested a few versions back). The breaking is very efficient.
But it seems you do need a lot of TSs to supply a useful amount of minerals. So many that just building a mine, which has the capital cost of just few miners, is a no-brainer. Or then I'm doing something wrong. I use your mobile mining script on the TSs, bunny. I think it was called "collect minerals". And they carry no weapons, so they don't try to break the rocks, a Falcon does that for them.
The "missile fab" has 10 missile production factories (4 typhoon, 2 tempest, firestorm, thunderbolt, silkworm and wasp), and the energy procdution loops to make it self-contained. I try to supply it with 16 miners. So its only 1.6 miners per self-contained (apart from minerals) factory. But still an L mine on an average 'roid with one TS can supply 5 loops, and cost something like 3 miners, or even less. Which leads to equivalent capital cost of 0.5 miners per factory loop. Of course its not your fault if the game is balanced against mobile mining. This script does work like a dream.
I would like to see some numbers, or gut-feelings, on how many miners people need to supply a factory. And also if this depends on the system a lot, i.e. is the average yield of rocks largely system dependent? Just to get a ball-park estimate.
But it seems you do need a lot of TSs to supply a useful amount of minerals. So many that just building a mine, which has the capital cost of just few miners, is a no-brainer. Or then I'm doing something wrong. I use your mobile mining script on the TSs, bunny. I think it was called "collect minerals". And they carry no weapons, so they don't try to break the rocks, a Falcon does that for them.
The "missile fab" has 10 missile production factories (4 typhoon, 2 tempest, firestorm, thunderbolt, silkworm and wasp), and the energy procdution loops to make it self-contained. I try to supply it with 16 miners. So its only 1.6 miners per self-contained (apart from minerals) factory. But still an L mine on an average 'roid with one TS can supply 5 loops, and cost something like 3 miners, or even less. Which leads to equivalent capital cost of 0.5 miners per factory loop. Of course its not your fault if the game is balanced against mobile mining. This script does work like a dream.
I would like to see some numbers, or gut-feelings, on how many miners people need to supply a factory. And also if this depends on the system a lot, i.e. is the average yield of rocks largely system dependent? Just to get a ball-park estimate.
Part of the problem might be the miners are bunching up and chasing the same rocks. This drastically reduces the collection rate OOS.
Now the script had code to prevent this in version 2.75. However, the script had a major makeover for version 3.00 . I am currently looking at the code to see if this bit got removed.
One suggestion for now would be to place more advanced satellites in the system. This would help the ships spread out (v2.75) - this is because they would random pick a satellite to fly to and then look for rocks near the satellite. This method worked quite well - I'll check it is still used (looks like some heavy load tweaking is needed again).
Cheers
Bunny
Now the script had code to prevent this in version 2.75. However, the script had a major makeover for version 3.00 . I am currently looking at the code to see if this bit got removed.
One suggestion for now would be to place more advanced satellites in the system. This would help the ships spread out (v2.75) - this is because they would random pick a satellite to fly to and then look for rocks near the satellite. This method worked quite well - I'll check it is still used (looks like some heavy load tweaking is needed again).
Cheers
Bunny
As far as supplying fabs and complexes are concerned, I use dedicated mines within the loops for that -- you get a constant supply to keep things working full time, not the piecemeal delivery with long waits in-between from mining ships (unless you have so many ships that they're waiting in line to dump their loads at the dock).
I'm using my ships to drop at L sized mines on relatively low grade rocks (saving the good rocks for loops). I use L size mines for the larger cargo space, and then TS's to ship it out to neglected third-world AI fabs that haven't seen a delivery in who-knows-how-long. I'm just that kind of guy...
I like mobile mining as a way of earning a little extra cash (though it takes a long time to recover the initial investment) and to clear the space lanes of traffic hazards. Because when you're zipping around in a Starburst at Mach 3+ through a rock field, you don't want something big and heavy getting in your way!
I'm using my ships to drop at L sized mines on relatively low grade rocks (saving the good rocks for loops). I use L size mines for the larger cargo space, and then TS's to ship it out to neglected third-world AI fabs that haven't seen a delivery in who-knows-how-long. I'm just that kind of guy...
I like mobile mining as a way of earning a little extra cash (though it takes a long time to recover the initial investment) and to clear the space lanes of traffic hazards. Because when you're zipping around in a Starburst at Mach 3+ through a rock field, you don't want something big and heavy getting in your way!
Okay the code in mobile miner 3.00 is fine. The thing to watch out for is that there should be enough navigation or advanced satellites in sector to get the ships to spread out.
What normally happens is the mining ship will randomly pick one of these satellites as a reference point from which to search for rocks. It will then move to that area and drop a navigational beacon to mark the position it will be mining.
So arranging navigational satellites in a star formation around a cluster of rocks would give optimal collection efficiency. It is also important to make sure there are enough fighters breaking rocks. Fighters are much bettered than armed TS ships for breaking rocks OOS. It appears the game code gives it a bonus just based on ship type.
Other developments:
On the German forum Lucike has added code to the "attack rocks" and "mobile mining scripts" to allow the user to restrict which type of minerals are collected/broken based on the ship name.
So, for example, if the word "ore" is embedded in the ship name then a free trade miner it will only collect that mineral type. Similarly, a fighter would only break rocks of that type.
Give it a few days for testing to complete.
Cheers
Bunny
What normally happens is the mining ship will randomly pick one of these satellites as a reference point from which to search for rocks. It will then move to that area and drop a navigational beacon to mark the position it will be mining.
So arranging navigational satellites in a star formation around a cluster of rocks would give optimal collection efficiency. It is also important to make sure there are enough fighters breaking rocks
. Fighters are much bettered than armed TS ships for breaking rocks OOS. It appears the game code gives it a bonus just based on ship type.Other developments:
On the German forum Lucike has added code to the "attack rocks" and "mobile mining scripts" to allow the user to restrict which type of minerals are collected/broken based on the ship name.
So, for example, if the word "ore" is embedded in the ship name then a free trade miner it will only collect that mineral type. Similarly, a fighter would only break rocks of that type.
Give it a few days for testing to complete.
Cheers
Bunny
OK, Thanks bunny 
First of all I'll update the software, and the messages I get from collectors should help me optimize. Maybe I'll also add one more breaker, since the miners could bunch up when supply is limited, trailing the breaker like seagulls behind a trawler.
Looks like only the breaker will need sats, right? I have a "standard box" of 8 adv. sats in CBSW, which should be OK spreading-wise, if rock supplies are OK. But I think I used an old version of the mining software, which didn't have sat features, up to until now.
EDIT: If I arm my freighters, will they only break if they find no collectibles? If so, this could be used to check the balance between breakers and collectors, because breaking collectors mean more breakers needed.
First of all I'll update the software, and the messages I get from collectors should help me optimize. Maybe I'll also add one more breaker, since the miners could bunch up when supply is limited, trailing the breaker like seagulls behind a trawler.
Looks like only the breaker will need sats, right? I have a "standard box" of 8 adv. sats in CBSW, which should be OK spreading-wise, if rock supplies are OK. But I think I used an old version of the mining software, which didn't have sat features, up to until now.
EDIT: If I arm my freighters, will they only break if they find no collectibles? If so, this could be used to check the balance between breakers and collectors, because breaking collectors mean more breakers needed.
The latest version of the software is contained in the X3Plus (right click "save link as"). Don't panic, when you click on it it will show a list of scripts - just select the mobile miner and attack rocks script. The installer is the same type used by the bonus pack.
You will probably need to stop and start the software on the ships if it is running mobile miner version 2.75 or earlier.
The suggested satellite arrangement should do the trick. Also keep an eye on where the TS ships deploy the navigation beacons (feature of script version 3.00) they should not be really close together.
Yeap, collectors will only use the weapon if they find no collectables. So yes if they are using it then more [EDIT] breaker ships are needed.
Your seagulls analogy is spot on
You will probably need to stop and start the software on the ships if it is running mobile miner version 2.75 or earlier.
The suggested satellite arrangement should do the trick. Also keep an eye on where the TS ships deploy the navigation beacons (feature of script version 3.00) they should not be really close together.
Yeap, collectors will only use the weapon if they find no collectables. So yes if they are using it then more [EDIT] breaker ships are needed.
Your seagulls analogy is spot on
A word of warning, Bunny :
I updated from v.1.19 (I think?) to the current one. This caused complete lockdown of my save. I got a few seconds after loading the game, and then a crash. Sometimes the game just slowly ground to a halt (in a minute or so), and sometimes it just stopped. This depended on the save I loaded. All my saves had one Falcon running Attack Rocks.
Using those few seconds, I turned the Falcon off, and the game returned to normal. At least so far. It took a good two hours of experimenting to figure out what went wrong. This because I just happened to make other script additions and cleanups at the same time I updated this one. Thank you, Murphy!
I suppose this is because the old script calls a "sub script" differently than the new one. And that difference causes an infinite loop if the old "base" script calls the new "sub" script. And the old "base" script is of course saved "on" the ship running it.
A fair warning to users should probably be in order ... I'll get back to you if I find something else on my mystery crashes.
I updated from v.1.19 (I think?) to the current one. This caused complete lockdown of my save. I got a few seconds after loading the game, and then a crash. Sometimes the game just slowly ground to a halt (in a minute or so), and sometimes it just stopped. This depended on the save I loaded. All my saves had one Falcon running Attack Rocks.
Using those few seconds, I turned the Falcon off, and the game returned to normal. At least so far. It took a good two hours of experimenting to figure out what went wrong. This because I just happened to make other script additions and cleanups at the same time I updated this one. Thank you, Murphy!
I suppose this is because the old script calls a "sub script" differently than the new one. And that difference causes an infinite loop if the old "base" script calls the new "sub" script. And the old "base" script is of course saved "on" the ship running it.
A fair warning to users should probably be in order ... I'll get back to you if I find something else on my mystery crashes.
One more thing I forgot to mention. Removing the new script files, and reloading a save which newer saw the new files, didn't help. So as far as I understand, just removing the old script files without turning the command off first, should have the same effect. Which means that the problem lies with the old version. It of course could have been inherited to the new one. However, for obvious reasons, I don't feel like testing this hypothesis.
And finally, just to make sure, I'm still not 100% certain this command was to blame.
And finally, just to make sure, I'm still not 100% certain this command was to blame.
I popped the hood on the attack rocks and mobile miner scripts to see what was going on....
A lot of issues have been fixed
The changed files are here (free host - I cannot upgrade the X3plus installer):
http://www.bigupload.com/d=170D889B
http://www.sendmefile.com/00538299
447000.xml
plugin.bar.checksats
plugin.bar.mainscript
plugin.bar.selectrock
plugin.bms.mainscript
lib.by.randommove
This patch is for Attack Rocks V2.00 & Mobile Miner V3.00/V3.02 ONLY (2.75 works properly already)
Changes are:
1. Attack rocks now destroys yield zero rocks again as it did in v1.19 - fixed
2. Attack rocks messages from language file - fixed
3. Random move lib file code was broken - fixed
4. Miner code did not contain the 32768 flag - this caused a severe reduction in collection rate (factor 2-3)! - fixed
5. Attack rocks had infinite scanner range when searching in a sector with no satellite in - fixed.
6. German language attack rocks messages missing - pending issue.
@ttl - I reckon the damaged lib.by.randommove file would have contributed to a lock up. The ship would have been making a random move of 0 m followed by a rock scan in a wait free loop - this would have only happened in a satellite free sector though.
Since the 32768 flag was reintroduced the miners are now collecting a lot quicker again - a queue of ships is now forming at my complex. Again the problem with the random move file would have meant that the miners were bunching up more as well.
Time to work on weapons changer.
A lot of issues have been fixed
The changed files are here (free host - I cannot upgrade the X3plus installer):
http://www.bigupload.com/d=170D889B
http://www.sendmefile.com/00538299
447000.xml
plugin.bar.checksats
plugin.bar.mainscript
plugin.bar.selectrock
plugin.bms.mainscript
lib.by.randommove
This patch is for Attack Rocks V2.00 & Mobile Miner V3.00/V3.02 ONLY (2.75 works properly already)
Changes are:
1. Attack rocks now destroys yield zero rocks again as it did in v1.19 - fixed
2. Attack rocks messages from language file - fixed
3. Random move lib file code was broken - fixed
4. Miner code did not contain the 32768 flag - this caused a severe reduction in collection rate (factor 2-3)! - fixed
5. Attack rocks had infinite scanner range when searching in a sector with no satellite in - fixed.
6. German language attack rocks messages missing - pending issue.
@ttl - I reckon the damaged lib.by.randommove file would have contributed to a lock up. The ship would have been making a random move of 0 m followed by a rock scan in a wait free loop - this would have only happened in a satellite free sector though.
Since the 32768 flag was reintroduced the miners are now collecting a lot quicker again - a queue of ships is now forming at my complex. Again the problem with the random move file would have meant that the miners were bunching up more as well.
Time to work on weapons changer.
)Thanks for the update
Well ... I was thinking what happens, if you make a call to a script in a wait free loop, and assume that the called script handles the waiting. Then you get an infinite loop lockup, if the called script file gets deleted, right? And this would happen when a script is uninstalled while a ship is running it. So in order to make uninstall -proof scripts one should never assume a called script to handle waits in a potentially infinite loop.
There were satellites in the sector where that "attack rocks" Falcon locked my game, so this is why I was thinking maybe removing the lib-file causes this in any case.
Well ... I was thinking what happens, if you make a call to a script in a wait free loop, and assume that the called script handles the waiting. Then you get an infinite loop lockup, if the called script file gets deleted, right? And this would happen when a script is uninstalled while a ship is running it. So in order to make uninstall -proof scripts one should never assume a called script to handle waits in a potentially infinite loop.
There were satellites in the sector where that "attack rocks" Falcon locked my game, so this is why I was thinking maybe removing the lib-file causes this in any case.
-
SymTec ltd.
- Posts: 5285
- Joined: Mon, 11. Apr 05, 21:11
Yes, that's one big problem in uninstalling/changing a script. If there are major edits to a script or you are to uninstall the script, you should make sure no instance of that script is running at the point you save and reload with the new/removed files.ttl wrote:[...]if you make a call to a script in a wait free loop, and assume that the called script handles the waiting. Then you get an infinite loop lockup, if the called script file gets deleted, right? And this would happen when a script is uninstalled while a ship is running it. So in order to make uninstall -proof scripts one should never assume a called script to handle waits in a potentially infinite loop.[...]
As this usually does not happen very often in betatests (because scripters don't always make uninstall/update tests), it is not spotted until release.
However, the problem is very rare, only happens in very special cases, is in big parts impossible for the x3plus-Pack, and not likely to happen in such a good script as this is. Of course, the bigger a script, the bigger the risk of unexpected things happening.
Got a new problem after dropping your patch files into place. My ships will go back to port to drop their load, but for some odd reason, they message me telling me they have a full load, but are waiting 10 minutes.
My docks are open, I have free cargo space in the station and money to pay the fees. Not sure why they wish to "wait" idling around the sector.
To be sure I didn't have any conflicts between old and new script functions, I stopped all my ships running the mining scripts before dropping the new files into place, then started them up again. At least now some of them are picking up silicon, whereas they were only doing ore before.
My docks are open, I have free cargo space in the station and money to pay the fees. Not sure why they wish to "wait" idling around the sector.
To be sure I didn't have any conflicts between old and new script functions, I stopped all my ships running the mining scripts before dropping the new files into place, then started them up again. At least now some of them are picking up silicon, whereas they were only doing ore before.