MAX-COTE Miner: ColdWar Edition , Official Thread/Download : EVE Online Bots Hacks | EVE Bots Hacks

the banner will dissapear once your minimize the script program. you must be running the program behind the eve window.
This is what i do!

run the script and quickly minimize the script window so it only shows in the taskbar, and then the popup dissapears. works like a charm.

crashergs...

I'm sorry , but I don't think turning off the banner is possible...

I never had trouble with the demo I used a year ago, before I purchased the full version of Macro Scheduler...This must be a more recent addition...I am wondering if there is some sort of deliberate crippling on the part of Macro Scheduler...

I'm also sorry that I had to use a non-free version of a macro program...now that I have looked at AUTO-HOT-KEY, I am pretty amazed at it's depth...How stable and bug free it is is another matter...

When I chose a macro program, I knew this macro would be a complex and large project, and most macro programs being fairly equal, my main concern was a stable editor...I needed an editor that I could cut and paste 500+ lines into...Those of you who perused the other forum on Comments about ACTool, or ToolWorks probably saw my opinion...

On another note:

I am addressing the logon/lag issues as we speak...

Please understand, that originally, as the macro was growing, I wanted everyone of varying scripting skills to be able to plain read remarks, and code in plain text.

Throughout the macro, almost every single action is remarked with a description of what it is doing...Also Labels, which must be unique were fully descriptive of the module it was used in AND the Subroutine OF the Subroutine it was used in...

Every bit of text was written as fully descriptive as possible...Now the complexity of the macro is hitting a wall of features vs resources/lag/system capability...I have so far hesitated to render the macro unreadable by all but experienced programmers...But also, now as the new interface has developed this may not be necessary...

I am painfully aware of these issues, and even I would get quite a kick out of being able to fully JetCan on my 1 GHz coffee warmer...heh

Be it known, I have heard the cry in the wilderness, and have untaken the task...It came to me midday today, that it was totally impossible by any stretch of the imagination, to render this feature rich macro fast and lag free, and able to run on all systems...hmmm...impossible huh...that's what got me to write the macro in the first place...they said it was impossible...

I'm buried in a complete rewrite of the entire Wait/Detection/Logon Subroutines including new Window ops, and detection code...the macro does not sleep, does not lag, boots like a demon outa hell on a mission...

I have to rewrite Debugging code just to see what's going on...

My 3.4 GHz EE, just left skid marks on my desk...and was half way up the hallway before I caught it...heh

Upallnite

They don't just use chat prompts to detect macros...

They also use logging...if you are on 22.999 hours a day for 3 weeks, you will be banned...

Hence the Stealth Logons/Logoffs...

Also another way is to detect your window operations...The game is fully able to detect your window operations down to the millesecond...This is what I refered to weeks ago as "ANTI-MACRO" Code...

I have already written and inserted "ANTI-ANTI-MACRO" Code, that also rnadomly varies all waits, 50% of their values, approximating human intervention...It is now impossible to detect the macro this way...But Also Hence the additional lag...

I'm now in the process of turning off this feature for some of you that can't run the macro...but you will be vulnerable...

Upallnite

On another note:

A 100% Search & Find Window Op AI Routine has been written...needs to be optimized and integrated...There is just one fault to it, it cannot detect if the user accidently got the window stuck BEHIND the station interface...But hopefully we WON'T have that problem too...

And to tell the truth, it's also WinXP...If you've ever noticed in a comparison of a default install of both Win2000 Pro and WinXP Pro,...the Win2000 Pro machine will sit idle just fine...while WinXP shutters, stutters, and spits...WinXP has more unnecessay crap running than any operating system in existence, and Vista will be worse...

Anyone could just as easily say that a major issue is OS performance...

Just like any other product that Microsoft produces, they add 10% features and 90% dead weight...Kinda like the old office Easter Egg, that if you worked with spreadsheet in a certain way, you had MS Flight Simulator popup...

Upallnite

I've noticed a gain of about 500MHz in raw CPU power in using Win2000 Pro over WinXP Pro...My 1 GHz machine with Win2000 is every bit as fast as my 1.8 GHz with WinXP...

@Upallnite

I have been thinking along the same lines myself for a wile now, A few of the people that have had problems getting it to run have solved there own problems with either a reinstall of the os or of the game and the Macro Scheduler program.

bloat it often the cause of most problems, and to be honest home system and or game system are normally the worse for colecting crap, programs downloaded from the internet and 100 and 1 programs to improve performance.

Best set-up would be fresh install of 2000 + EVE + Macro Scheduler nothing else. If it does not work with this set-up then its time to start working on other causes.

Now my PC at home is not quite that simple but Its pretty slim

Firelord

Dont know If You like to try but the CCC (chaos computer club) coded a small gui that shuts donw all unneeded windows crap with one shot.

its located here http://www.dingens.org/win32sec.exe

The funny thing abot that is You dont need any firewall after you did ran this sucker. Cause it deactivates all those thingys the trojans rely on.

my problem was fixed by reinstalling the entire os and mac and the game itself, now it runs beautifully. but I also noticed that the macro does not like stations that are more elaborate than the usual amarr stations. Like those stations in deep space where they have bunch of awkward additions and not simplized, such as the stations in keshirou, the macro will keep zoomin in and zooming out, but all amarr stations seem to be fine.

You could also use Win XP (Stripped to the bone) version, its only 175 meg and had only the needed components to run, no extra BS.

Hi all,
Just in case no one is aware, the macro will NOT save your butt if your mining in less than .5 system. You are vulnerable when docking and undocking. Pod check did not do me any good either, gotta check that and see whats up and what can be done. I suspected this for some time and it was proven just a bit ago when I came back from store to find myself at clone base and thinking wtf......oh well was just a cruiser, this time.

This can result from being fast locked and then scrambled, there is no solution that applies to someone mining afk

How about this as a idea

Armor check red with warp to safe spot and wait.
turn on armor repair and wait there till armor and shield shows good again
then warp to next belt.

If podded could warp to safe spot and log


I have allways thought if warping from field to field, long as your set to warp in far enough away you be safe, but I guess that does not hold true if you have pirates other than npc rats,

firelord

Ok safe spot is good idea, what location or id will it have in PnP?

Question on the hauler/jet can code. Hauler is looking for roidline in c:\root or other root drive. Jetcanner is writing roidline to the shared folder MAX_COTE under Eve path...how the heck is hauler supposed to find roidline?!

I shared my MAX_COTE directory for the roidline files under ?:\CCP\EVE as MAX_COTE$ for security purposes...It is Available on my lan, when I query for it, but it is not broadcast...I then Open Windows Explorer on the Hauler machine and do a "map network drive"...Directory is mount as root using available drive letters...Hauler code when looking for roidline files, checks all drives for root roidline files...such as "Z:\roidline*.txt"

Upallnite

In other words, after mounting, the "contents" of the shared "MAX_COTE" are mounting as root objects using an available drive letter. Do Not share "CCP" or "EVE" directory, or Hauler code will not find the roidline files...

Maybe I wasn't clear on the arrangement of JetCanner/Hauler...It was intended that they be on totally different computer systems, on the same lan, they cannot be used alternately on the same computer...

Maybe someone might want to try that, but I don't see why...Just like any mmorpg...using one account leaves you vulnerable to leechers, and pirates...The intention was to perfect JetCanning so that the JetCanner could work non-stop...and even the Hauler on the other system too, was even going to add switch to normal mining for the hauler down the road to fill the time, but with all the evasions, my JetCanner keeps my Hauler Working...If the Hauler catches up and waits, The JetCanner is still pulling in 4 times as much as 2 solo Indy's...I was even thinking that 2 JetCanners could use one Hauler...but didn't get that far...

Also, in case it wasn't mentioned or obvious...JetCanner needs to drop first JetCan and write first roidline file before activating Hauler, so Hauler can home in on roidline file, after initial startup...roidline file location is saved in memory, and Hauler should be fine....You can wait for several roidline files, before starting Hauler, but Hauler must have at least one roidline file available to startup properly...

New Problem found.

Found that rocks poping half way though mining stops mining, IF the next rock slected is outside target lock range.

Added GoSub>Asteroid_Approach

SRT>Asteroid_Target
Let>vAsteroid_Target_Check=0
Let>vAsteroid_Target_Icon_Check=0
GoSub>Asteroid_Approach
Label>ASTEROID_TARGET_ICON_RECHECK

Added the approach GoSub to the Asteroid_Target Sub to make sure we come in range of the rock. otherwise ship sits there waiting for a target that never comes into range as ship is stoped. Code stopper

Problem 2
When ship waits for mining lasers to all disengage before returning to
dock.

added 2 lines for extra cargo check to speed up return to base

GoSub>CargoHold_Open_Space
GoSub>CargoHold_Detect



GoSub>Get_Pixel_Color
If>{(%vColor%=1084595) OR (%vColor%=9936286)},MINE_NORMAL
If>{(%vColor%=1085117) OR (%vColor%=10265244)},MINE_NORMAL
GoSub>CargoHold_Open_Space
GoSub>CargoHold_Detect
GoSub>Lasers_Reset
GoSub>Lasers_ON_OFF





Thanks

Firelord

There was an existance check for targeting icon, that should have forked to Asteroid_Approach, but it may be failing...checking code now...

I believe that I've had some trouble in the past with this issue due to OverView Lag, when opening Upper Section after Ore Detection/Selection...that icons were "popping" late for macro detection...

Issue with CargoHold...I think I mentioned a bit earlier that CargoHold Detect is actually just waiting on Full CargoHold Detect, it does not wait on lasers to disengage...it is just that accurate now detecting an absolutely full CargoHold, that it actually triggers the same time as game auto disengages lasers...I had some code down for altering that so you can just do a one pixel check for Cargo Detect and move it around to cut down your excessive mining cycles just to top off CargoHold...It just wasn't practical to do any sort of calibration for all the different ShipType/CargoHold Capacity/Expander Module Combinations...

Upallnite

Issue with targeting...seems that interface activity after dead roid, such as flashing lasers, may be adding to lag issues with OverView icon detection...testing now...

Got it...Code indicates a target existance icon check at beginning that does a one pixel color check...it has a 2 sec wait attached to loop with a 60 loop timeout...there's the problem...that's a 120 sec timeout before reacquiring/detection/approach...I Had the 60 loop timeout there before..but had a 0.100 wait attached...never changed loop to balance longer wait...cutting wait back down for new release...

Thanks upallnite

I hear what you are saying but that does not match the logic of what my system is doing.
My reasons for this are that when the cargo is full, and 1 mining laser is still mining, it will allways warp directly after the laser disenganges. If I turn it off by hand, the ship warps, every time, Within seconds.
I added the extra cargo detect to the mining subs and now it works as expected. when full it warp. I think from reading the code that it does not fork down the line to go a cargo detect untill the icons for the lasers are not detected.


GoSub>Get_Pixel_Color
If>{(%vColor%=1084595) OR (%vColor%=9936286)},MINE_NORMAL
If>{(%vColor%=1085117) OR (%vColor%=10265244)},MINE_NORMAL
GoSub>CargoHold_Open_Space
GoSub>CargoHold_Detect
GoSub>Lasers_Reset
GoSub>Lasers_ON_OFF

just some food for thought

Thanks

Firelord

upallnite wrote:Issue with CargoHold...I think I mentioned a bit earlier that CargoHold Detect is actually just waiting on Full CargoHold Detect, it does not wait on lasers to disengage...it is just that accurate now detecting an absolutely full CargoHold, that it actually triggers the same time as game auto disengages lasers...I had some code down for altering that so you can just do a one pixel check for Cargo Detect and move it around to cut down your excessive mining cycles just to top off CargoHold...It just wasn't practical to do any sort of calibration for all the different ShipType/CargoHold Capacity/Expander Module Combinations...