You seem to feel the need for personal attacks.

Nah, just pointing out the obvious to those that miss it.

Obvious troll is obvious.

I'm pretty sure that people can make up thier own minds about what the obvious is. No need in you telling them what they should think.

Hooray for free speech!!

Dude your not in smack....come back to the sand box before you get us ban again

My bad, I read D's post and assumed this was smack. Removing my offending post...

That's funny. Because I read Sing's post and assumed it was smack talk. I would have deleted it, but it's more dicussion and debate as Sing calls it, so it's all good.

There are 2 kinds of Direct Torpers

1) one kind like qphot gets data and filters After the fighit.
IF you have a fast ping
IF you have a new puter with low latency and fast CPU
IF you load your datbase into memory by checking the box in TWX

Works fine

2)The kind that preload and prefilters data and load into array.

This kind will ALWAYS be faster than #1 but given the IF's from above might not be much of a difference.


All my Grid defender and AFK scripts are of type 2

The type one scripts I have are for quick load / at keys use against peeps playing silly buggers


IF you cant hit anyone with a type 1 script then use a type 2 model.


Personally I like to build in a lot of safety options into many of my direct torpers so that I can use them on the bot with the fastest ping without checking 10 things manually first. Filtering stuff like fedspace or stardock or sectors that have been hit and retreated against costs time in a type 1 but not in a type 2. Yes i know...getwordpos takes 0.1ms or less but stack up enough stuff and it costs time. And if you have Dbase memory turned off on certain games if running multiple games etc then forget type 1 scripts.

Of course if your running a new quad core with 8 gig ram its all moot except as a point of discussion.

Actually, semi-recent variants of qfot do all of this before in a
set of arrays. I changed that over a year ago for private versions.
Prior to qfot, I used a private torper that did everything pre-loaded.
Eventually I wanted a bot torper I could control, and that's when I
adapted qfot to be a bot module. Same time I preloaded everything.



There are some things you can't pre-filter tho. To that end, you
limit the capability of the torper if you restrict yourself only to
what you can filter.

Of course but any post filtering...like "alien hits" slow down the process. How slow and whether it makes any difference is a matter for testing the function

True, but otherwise alien fighits end up being a problem if
you're in an alien game.

Basically, what I do is...

Spoof check
Entered sector check
Alien check
Hitsec range check
Fed ADJ check
Get ADJ fig
Burst macro

All of those combined took maybe 1ms in testing. Even a 5ms
difference in ping surpasses it. I could probably get away with
not doing a range check, but it doesn't add any real time expense
and eliminates the possibility of a corrupted line.

I picked up more time moving the setSectorParameter write
for the fighit to after sending the torp burst. That alone ended
up saving like 2ms.

In testing, I found that if you pre-init your sector parms they
end up being just about as fast as using an associative array.
If you don't, that's where the problem comes in. That's why I
ended up pre-caching the figs, as not all of my corpies were
initializing their parms by order.



That's my alien check. I ran 100,000 iterations of that in a
test and it took 475ms for all of them. That's 0.00475ms per
iteration. That's so tiny, it's not even an issue. Not torping
aliens... totally worth that tiny cost in time.

This Assumes "Cache Database in available memory" is checked in setup otherwise
Sector.warpcount[x] and getsectorparameter "x" "FIGSEC" $x take alot of time to fetch from the hard drive. I find multidementional static array's are the fastest way to retrieve the pre-filtered data.





As I said "testing and function"

Actually no, in my tests I had it off.



Hrm... That doesn't match my testing.

1,000,000 iterations of:


Where 9826 is a 6-way (stardock of a test game) takes
19508 ms. That's ~.02ms per iteration. That's still very
tiny, there's no sense in caching that. I suspect you won't
pick up much (if any) speed by doing that.

GetSectorParameter depends on where in the parmlist the
parameter is. The 10th parm, yes. The 1st, no. Here's my
testing for figsec (initialized as the first parm in each sector).

1,000,000 iterations of:


Took 23604ms. So... .023604ms per iteration. That's a
difference of .004096ms per iteration. We're talking about
a really really tiny amount.

Now that is with cache db in mem turned on. So let me turn
it off and rerun. How much does it go up? Total, 1m iterations
in 33418ms. That's 9814ms per 1m iterations. For a total of
.0098ms per iteration added by doing a non-cached parm get.

Overall, parms versus no parms. Cached versus not cached,
it's not even 1ms per iteration difference.

Now, like I was saying earlier, the setparm takes a little more...

1m iterations of:


Took 59796ms. While still tiny per iteration, it's quite a big
difference. In fact just moving that one thing took out the
bulk of processing time from the pre-torp calculation, like I
said last post.

Now I grant you, my PC is a little faster than average. And
my vbox drive actually outperforms most sata drives, but
even if you multiply the time it takes by a factor of 10, it's
still a small amount of processing.

There is very little difference between pre-processing and
post-processing. When I released qfot originally, I knew this
because I had done testing with EP while he was working on
2.04's parms. It's still a very effective script, less than 1ms
difference between yours and mine.

The difference only comes when you have a very slow, very
fragmented PATA drive and aren't caching your DB, and figsec
is like the 10th parm on the parm list. That is why I moved to
a pre-cached fig database on my private vers, it removes the
one major bottleneck in the system. Still, in most cases, I
picked up no speed improvement by doing so.

The real improvements in fotoning comes with the use of the
bot. You may pick up 1ms or 2ms speed difference at the
extremes of coding, but with ping you can pick up 20, 30ms,
50ms improvements. Distributing the torper as a bot module
and allowing your fastest torpers to shoot... that's the biggest
improvement around.