SRL Archive - General

SRL Positioning System

Well it's a no-brainer: MSI will definitely be using SPS, how, exactly? That's what this thread is for. Do we scratch the auto-generated color walking recently added and replace it with SPS? Do we use SPS as an extra? Do we use SPS as our primary method, then auto-generated points as an extra?

My thoughts:

• Scrap auto-generated color walking. Yeah, I put a shit load of work in to it, but you know what, SPS is better, and sometimes better things comes along. It happens. I'm not upset about it, especially when it will change the face of color botting.

• From: marpis
  Yea it's very simple really, I'm just kinda lazy now :p

It'll be something like

function PosToTile(P: TPoint): TTile;
begin
  Result.x := 3213 + P.x/4;
  Result.y := 1231 - P.y/4;
end;

Just got to calculate the "3213" and "1231" numbers. It's easy too. I'll get it tomorrow maybe. Once this function is written, we can declare one path (either reflection or color) in our TScript records, and the opposite one will be converted from the declared one. Yes, even simpler.
• No, it won't wreck our hybrid system. It will only make it better. It will work basically the same as it does now, just without the automatically generated records.
• It will also FINALLY get rid of two walking files. Since the color one will probably only be one function, they can be combined.

Ideas/thoughts?

Yes Yes Yes Yes! Been looking forward to this for a while now.

I would like to wait just a bit as marpis just released it so I think we should give at least a few days to let any kinks get worked out.

I do think it would work best replacing the auto-generated color records, but I'll leave that up to you as you wrote it. :)

I honestly can't wait to get this implemented. It will clean things up immensely as well as optimize our Hybrid system. So exciting!

From: NCDS
Yes Yes Yes Yes! Been looking forward to this for a while now.

I would like to wait just a bit as marpis just released it so I think we should give at least a few days to let any kinks get worked out.

I do think it would work best replacing the auto-generated color records, but I'll leave that up to you as you wrote it. :)

I honestly can't wait to get this implemented. It will clean things up immensely as well as optimize our Hybrid system. So exciting!

Yeah I think I'll get rid of the generator. Not really need + it will still be posted in the scripting tools section if anyone ever wanted to use it.

And yeah, just wanted to get everyone on the same page before adding it. We'll of course wait until marpis has marked it as "MSI-read" :p Or even perhaps when he's added it to SRL.

I think it would be good as an extra, but the use of pointers makes other extras unable to use that pointer, which is a con..

From: Zyt3x
I think it would be good as an extra, but the use of pointers makes other extras unable to use that pointer, which is a con..

Not to mention if SPS is really that good, it makes every other color walking method look obsolete. Oh, and since MSI is a community project, and SPS will be in SRL, it only makes sense to use the community's methods. ;)

I've also been having some issues with generating some points and I haven't for the life of me been able to figure out why.

If it's going to be in SRL, then we'll make it in-built into MSI :)

If SPS can give you a tile accurate color version of GetMyPos and the auto generated DTMs cannot, then absolutely scrap and switch, no question. Much better integration with reflection paths and webs etc.

Only thing is.. I would have to ask marpis to provide documentation in the event that he cannot update this.

From: Boreas
If SPS can give you a tile accurate color version of GetMyPos and the auto generated DTMs cannot, then absolutely scrap and switch, no question. Much better integration with reflection paths and webs etc.

Exactly.

From: Nava2
Only thing is.. I would have to ask marpis to provide documentation in the event that he cannot update this.

Yeah, I'm sure he wouldn't have a problem with that.

From: Nava2
Only thing is.. I would have to ask marpis to provide documentation in the event that he cannot update this.

What… The code is pretty simple and straightforward.

Also, what's with the I, doesn't make sense…

Cool and all, but I still want the possibility to use other walking systems.

I like your tool, I lie Camaro's walking and I'm still developing my walking method.

Sure use it as the main walk, but find a way to be able to use other walking systems (pointer)

e: I just rethought that and scrap it. Just keep SPS and cStrike's global walker as walking methods and get those perfected, no point in having more than that. This is a script afterall.

~RM

From: Wizzup?
Also, what's with the I, doesn't make sense…

Bad English, it was 3 am and I was tired?

Didn't really deserve that response.. o.O

From: Sir R. M8gic1an
e: I just rethought that and scrap it. Just keep SPS and cStrike's global walker as walking methods and get those perfected, no point in having more than that. This is a script afterall.

~RM

Sounds good. MSI can still be used as a testing ground for your walking by using it as an extra. Could be the same for Camaros; although we already know it works well.

From: Coh3n
So I basically worked all day on implementing this into MSI, and I think I've got it working. I'll be testing it over night and will make it available for anyone to test through MSI tomorrow. I'll write detailed instructions tomorrow for testing.

Also, I'm thinking we wouldn't really need a hybrid system for walking because reflection/sps are both good enough on their own. And, SPS takes about 500ms to get the player's position so we would somehow have to work around that. I don't think it's worth it to have hybrid, but you guys may.

From: Coh3n
Also, I'm thinking we wouldn't really need a hybrid system for walking because reflection/sps are both good enough on their own. And, SPS takes about 500ms to get the player's position so we would somehow have to work around that. I don't think it's worth it to have hybrid, but you guys may.

Call GetMyPos during WaitWhileResting for scripts that walk?

From: NCDS
Call GetMyPos during WaitWhileResting for scripts that walk?

That forces the waitWhileResting to be 500ms then no matter what.

From: Nava2
That forces the waitWhileResting to be 500ms then no matter what.

I don't think I've ever seen it be less than that honestly.

The only time would be if your energy level was already > MAX_ENERGY, which could be handled with a simple conditional. Then we would just need to think of how to do it if the condition was true (ENERGY > MAX_ENERGY).

Idk, I've only got a couple minutes to be on right now so I really don't have time to look at it.

From: NCDS
Call GetMyPos during WaitWhileResting for scripts that walk?

SPS_GetMyPos is called before walking to each point.

These are two different "tile" walking methods, that can't really "fail". I just find it would be useless to make it hybrid. Like what would we benefit?

From: Coh3n
SPS_GetMyPos is called before walking to each point.

These are two different "tile" walking methods, that can't really "fail". I just find it would be useless to make it hybrid. Like what would we benefit?

Nothing besides a solid failsafe, really. We can just leave it as an option, I don't really mind either way. I haven't had shit for time this week, but if SPS is stable then I see nothing wrong with that.

A color walker combining aspects of SPS and CTWB may be faster, but I would need help as I just started a second job.

From: Boreas
A color walker combining aspects of SPS and CTWB may be faster, but I would need help as I just started a second job.

What's the difference between the two? From what I gather, they both use bitmaps of the minimap/world map, but what exactly could be combined from the two?

From: Coh3n
What's the difference between the two? From what I gather, they both use bitmaps of the minimap/world map, but what exactly could be combined from the two?

They use different techniques for speed, so using both techniques should make it faster. I'm not sure on the status of the tile math for SPS, but CTWB is reflection compatible from the ground up because the math used to define the bitmaps. CTWB divides the map into small sections, and only searches a small number of them based on other criteria (quickly read from a text file). SPS uses a plugin to perform the searches faster per tile than I assume algos written for CTWB probably would have. So basically use CTWB to determine which bitmaps to search, and SPS to search them.

From: Boreas
They use different techniques for speed, so using both techniques should make it faster. I'm not sure on the status of the tile math for SPS, but CTWB is reflection compatible from the ground up because the math used to define the bitmaps. CTWB divides the map into small sections, and only searches a small number of them based on other criteria (quickly read from a text file). SPS uses a plugin to perform the searches faster per tile than I assume algos written for CTWB probably would have. So basically use CTWB to determine which bitmaps to search, and SPS to search them.

Oh, make sense. For SPS, you specify which parts of the map to search from when you set SPS_Areas (defined by the sections it has when you download SPS). Not sure if those bitmaps would be larger than the onces generated by CTWB, though.

From: Coh3n
Oh, make sense. For SPS, you specify which parts of the map to search from when you set SPS_Areas (defined by the sections it has when you download SPS). Not sure if those bitmaps would be larger than the onces generated by CTWB, though.

CTWB could have an area defined also, but I never got that far. A CTWB/SPS could certainly have an area defined for the first look, and then look everywhere if there was a failed random tele or the user just started the script without moving the player(s) with a web. The bitmaps would probably be about 30KB, loading 4 at a time (mega chunk), and only loading the megachunks that have enough symbols/trees/etc (read from text file). The minimap would be in memory the whole time, while there would be up to one megachunk in memory at a given time, plus a simple int/pt array.

As far what is in memory, here is an overview
1) Grab the minimap, this stays in memory the whole time (unless you want to convert to a simplified version, see RMs paint stuff and Galelio pdf by Markus)
2) Get count of trees/etc and each symbol, load into intarray called StuffIntArr. Least common symbol is [0], next most is [1]….end with common stuff like trees.
3) Just reading numbers from a file, no bitmaps for this step. In a file, you basically have an Array of Array of TPA. The top level index is th same as the array in step 2. The next level is the number symbols/trees from 1 to whatever, and the TPA is the megachunks have that number.

//INI example, but whatever you want is fine
[Symbol0]//the least common symbol on the world map
Highest=8
1= 54-29,89-26 //the 2 megachunks that contain 1 of that symbol
2=.....
...
8=47-32
[Symbol1]
.....
[

You can load the whole 3DTPA into memory if you want, but it's best to just load one 2DTPA at a time (just Symbol0 etc), as you just want to keep going until you have narrowed down the megachunks to scan.
Go through the indexes of StuffIntArr until you get a non 0/empty value, lets say [3]=6. Load the contents of [Symbol3] into a 2DTPA called Current2D. Take the TPA from Current2D[6] and the TPAs from everything above that, and combine them into MCTPA.
Hopefully that list is pretty short. If not, go to the next non 0 value in StuffIntArr, and load the symbol for that index into Current2D, overwriting the old Current2D. Now go through Current2D for that value and up, and combine into a TempTPA. Make a new MCTPA that contains the TPoints that the old MCTPA and TempTPA have in common, thereby making MCTPA shorter. Repeat this paragraph until MCTPA is as short as you want.
You can forget about all arrays besides MCTPA now.
4) Go through MCTPA, for each point, use SPS plugin to search for minimap bitmap (30KB) in a megachunk bitmap (4*30KB). Megachunk bitmaps can be made on the fly by copying 4 chunks bitmaps in to a temporary 120KB bitmap (more real time processing, about 2.6MB hard disk usage to store p2p/f2p map), or made once (less processing, about 2.6*4 MB disk usage).

TLDR basically looking at 500x100 pixels worth of bitmaps in memory.

I'm sure it sounds more complicated than it actually is. :p Sounds like you have a good idea of how to make it work.

From: Coh3n
I'm sure it sounds more complicated than it actually is. :p Sounds like you have a good idea of how to make it work.

Yea using the text files to decide which bitmaps to load is really simple. The catch is generating the bitmaps and text files in the first place is a big group effort.

From: Boreas
Yea using the text files to decide which bitmaps to load is really simple. The catch is generating the bitmaps and text files in the first place is a big group effort.

I don't think it would be a bad idea to eventually add it to MSI as an extra. The trouble there would be actually getting people to post what was generated. I would also like to resolve all the memory issues before moving on.

Why not set up a webserver and POST the file to it for storage. Along with some other information.. This would definitely need users to give it permission though. Some are worried about their privacy.

SPS is now in MSI and uses defines until it's in SRL.