Rynchodon
commented
9 years ago Wow, that sounds really ambitious, I had a much lazier harvester in mind.
For controlling the movement of the ship, the easiest way is to accelerate to the desired speed and, instead of disabling dampeners, disable the reverse thrusters. ThrustProfiler is already keeping track of the directions of each thruster, so this should be relatively simple.
Turning while inside of a tunnel is a bit tricky, we do not want the ship banging into the sides of the tunnel more than it has to. Reversing out of an asteroid when there is nothing left to harvest is an even bigger problem, it is very easy to get stuck and we want harvesting to work with as many different ships as possible. It would be much easier to implement a straight-through asteroid approach.
I have not done any work with voxels, but I believe that the way to get the content of a voxel is IMyVoxelMap.Storage.ReadRange().
Random Musings: The harvester should be able to function even if the remote is facing the wrong way. Initially I thought checking inventory would be complicated, but it is only necessary to check the drills' inventory. The ore detection should be kept separate from the harvesting, there may be other uses for it.
I did not intend to abandon you to the will of the code; I am happy to explain my poorly-documented code to you, assist in writing code, explain what I can about modding S.E., or any other help you need.
zrisher
ghost
Alright I'm taking a stab at harvesting and here's how I was thinking of implementing:
We add a command
Hthat works likeMbut targets ore voxels.Etakes precedence (so you can have military harvesters...) and if we ever implement a "flee" functionality that would take precedence too.Hcan be called with no arguments to target all ore types besides stone, or a prioritized list of ore types by periodic symbol i.e.Co, Si, Ag, Au, Ni. If you wanted to actually harvest stone, you'd need to specify this list and include it (maybe asSoorSt) likeCo, Si, So. Clearly this should require a connected ore detector, but we could also eventually add the ability to run it with just a sensor and ignore the ore type arguments.Harvesting would occur whenever a targeted ore is detected within the range of the currently used detector and would continue every time such ores exist until inventory is full or another command takes over.
Example - Fly out to an asteroid at 1000,1000,1000, stopping to mine any Uranium that comes into detector range everywhere between here and there until full. Once there and full or no more U detected, fly back to 0,0,0, dock, unload, and repeat.
Do the same thing, but engage detected enemies 1km away along the way:
@Rynchodon What do you think?
In terms of implementation, I'd add a case for
'h'intoNavigator.addInstructionthat would hook into the CNS at a lower priority than E or M (or F for flee later?), and would function very similarly to a missile but with different search and engagement algorithms.I haven't gotten much farther than trying to get my arguments parsed and logged (not very experienced with C#), but I'm working on it. : )
I think engagement will be moderately straight forward - approach voxel at range, then slowly go forward towards it with drills on, pulsing forward so as to minimize shake due to asteroid collision. Remember vector in, follow it directly out when voxel no longer in front or inv full, resume unless inventory full.
But search - that's a bit of a mystery to me. How can I find the part of an asteroid voxel that is of a particular type of ore? The ore detector does it and finds their centers, so I know it's possible. I see we get voxels a few different ways and IMyVoxel exists, but I can't find any examples of finding parts of an asteroid by material. Are the ore patches seperate voxels? How do I get material type?
@Rynchodon Any guidance on implementation at this point would be highly appreciated.