Thank you Dorjan, appreciate the comments.
Definitely need to be careful here and consider each change carefully. For some stuff there is really no "ideal" and you need to make a choice.
Dorjan wrote:QUOTE (Dorjan @ Mar 15 2012, 08:52 AM) 1) Been ordered to dock, won't relaunch unless a new order is given to it. (Maybe some sort of message to the commander if a miner has been docked for a while?)
That's in R6.
QUOTE 2) Attacked! Panic mode! (Reset last panic mode timestamp after docking / unloading 1 minute.)[/quote]
Original behavior is to reset panic mode (stop running) once sufficiently healed, which results in the stupidity of a miner returning back to the sector it's just been raped in. One option is not to stop running till docked, another is to pick a new rock instead of going back to mining the previous one, which is what I'm doing now.
QUOTE 3) I was ordered to mine a rock in a sector, keep order mining that sector. Each time I've finished mining at a rock, docking or offloading check:[/quote]
Yes, it now works like this - instead of a "return to the same (potentially suboptimal) rock" or "pick an entirely new order" (based on whether there is leftover capacity) logic of before, miners now remember the mining sector and prioritize that.
QUOTE 3.a) Is that sector not hostile (with usual checks, make sure the sector is friendly and there is a path through known non-hostile space to sector and use the route for distance)?[/quote]
The default logic considers a sector friendly if you have a base in it without enemy bases, and not otherwise. Since there is now the definition of a mining sector, you can override this manually and miners will return to neutral sectors properly (and not just beeline to the last mined rock only if they were full before). To this I have added an attempt to GTFO contested sectors after the mining is done and also not treat any sectors with an enemy carrier in it as friendly.
An idea that's been thrown around is to include # of friendly vs enemy in the sector in the definition of friendly sector, and currently experimental mode turns this on. But I don't know if it's smart enough to be beneficial or annoying enough to cause problems simply because of random enemy scout presence. As coded, it's the exact same logic that decides whether to run or not when damaged. See "threat level detection" below.
QUOTE 3.b) Is there enough HE in that sector?
3.b.1) What was the last rock in that sector and how full is it? If more HE than 50% of my hull capacity mine there otherwise add to stack of possible HE rocks and do 3.b.2.
3.b.2) Find nearest HE rock in that sector to last mined rock and check if will give me more than 50%, if so mine there otherwise add to stack of possible HE rocks and do 3.b.3.
3.b.3) Check to see if stack of HE rocks will give me 50%, if not check the next nearest to last mined roid and continue looping until no more HE rocks in that sector. if the whole sector will give less than 50% find new sector to mine.[/quote]
Right now any rock with >25% He3 is considered a target and the closest one to the miner is picked, not the closest one to the last mined asteroid. In practice though these tend to be the same.
QUOTE 4) Finding new sector (with usual checks, make sure the sector is friendly and there is a path through known non-hostile space to sector and use the route for distance), check nearest friendly sector from last HE rock mined location for HE using the rules from 3.b if invalid sector, add sector to a stack then continue through sectors in distance from last HE rock mined location. If no sector found, check stack (in reverse order ofc) for any two sectors to start mining (using the rules from 3.b but using known sector HE totals).[/quote]
Mostly works that way if you keep in mind the distinctions above. The improvement there is previously path-finding would revert to going through "any sector" if there were no path through friendly sectors. Now it tries friendly sectors, then neutral sectors, and only then considers any other sector. This could definitely be improved by making a distinction between "any" and "contested" as well (I skipped over it for now since it needs more 'plumbing')
I think all this currently adds up to significant improvement and the next
big improvement would be intelligent threat level detection.
1) Total DPS of enemy closing in (ignore enemies not closing in)
2) Total DPS of friendly closing in (use a factor here, for example 0.5 to calculate effective DPS) (ignore friendlies not closing in)
3) Total DPS of friendly capable of healing closing in
4) Calculate TTL(me) based on #1 and #3
5) Calculate TTL(enemy) based on #2
6) TTL(me)<TTL(enemy) = run
