SRL Archive - General

Again, RM has said a few times about the possibilities when using reflection to gather color walking information. We can get exact tile colors, angles, etc. which can also be updated automatically during runtime if we were to use a record of some sort.

What I want to discuss is the ridiculous amount of color walking routines we have. I brought this up a while ago and we decided to leave as many options as possible; however, with reflection in the works now, it only makes sense that we pick a method. This will not only clean up the include, but it will make everything less confusing for everyone.

In addition, if done properly, the color walking will be written for us. If everything is gathered during runtime, all our paths will be automatically made. sounds pretty awesome, doesn't it?

So, I think we need to come up with the best system for what needs to be done. What will be the most accurate? What is all the information we need to collect and why?

I think we should use Garrett's method, expanded of course. He has one function that will walk to any point based on a record. What needs to be added, what can be deleted?

type
  TWalkInfo = record
    Name         : string;
    Color        : Integer;
    Tolerance    : Integer;
    SplitMethod  : Integer;  // See the split method constants
    SortMethod   : Integer;  // See the sort method constants
    Filter       : Boolean;  // Use FilterPointsPie?
    CTS2         : Boolean;  // Use ColorToleranceSpeed 2?
    HueMod       : Extended;
    SatMod       : Extended;
    StartRadial  : Integer;
    EndRadial    : Integer;
    MinRadius    : Integer;
    MaxRadius    : Integer;
    SortPoint    : TPoint;   // Point to sort from (for SortTPAFrom only)
    SplitDist    : Integer;  // For TPAToATPA/SplitTPA only
    W, H         : Integer;  // For TPAToATPAEx/SplitTPAEx only
  end;

// Revised
type 
  TColorMMPoint = record // I'd like to think of a better name, TWalkInfo may be fine
  end;

I'd like to read everyone's thoughts on this. :)

I'd also like to point out that this isn't going to be rushed. This will probably be the last reflection component that's added simply because I think it will be the most complex.

If it works, I don't see any problem with it.

It would be hard to get the script to know when to use variables like (i.e) SplitMethod, Filter and SortDist, so I think we should take those away, unless someone wants to write the script so it works with those variables. Could be hard though.

But we don't actually have to remove anything right now either.. I mean.. If we see we don't/the script don't use them then we can remove those later on, like you said, no rush..

Well, I think that the FilterPointsPie portion could be taken out, because having the script gather accurate results about the radians and such would be extremely hard, and would likely make it break if it wasn't perfectly gathered. The accuracy rate is still very good when the other criteria are picked well. Based on the suggested accuracy of the system, we could do without filtering the points based on the radials.

This would make it:

type
  TWalkInfo = record
    Name         : string;
    Color        : Integer;
    Tolerance    : Integer;
    SplitMethod  : Integer;  // See the split method constants
    SortMethod   : Integer;  // See the sort method constants
    CTS2         : Boolean;  // Use ColorToleranceSpeed 2?
    HueMod       : Extended;
    SatMod       : Extended;
    SortPoint    : TPoint;   // Point to sort from (for SortTPAFrom only)
    SplitDist    : Integer;  // For TPAToATPA/SplitTPA only
    W, H         : Integer;  // For TPAToATPAEx/SplitTPAEx only
  end;

I also think that for maximum accuracy we should use CTS2, which could easily be perfected if we are gathering the proper colours, so that boolean can be gone.

type
  TWalkInfo = record
    Name         : string;
    Color        : Integer;
    Tolerance    : Integer;
    SplitMethod  : Integer;  // See the split method constants
    SortMethod   : Integer;  // See the sort method constants
    HueMod       : Extended;
    SatMod       : Extended;
    SortPoint    : TPoint;   // Point to sort from (for SortTPAFrom only)
    SplitDist    : Integer;  // For TPAToATPA/SplitTPA only
    W, H         : Integer;  // For TPAToATPAEx/SplitTPAEx only
  end;

That reduces a large amount of work which will help development. I think that it's better to have a solid base, and if we want to add the filtering later it will be really simple to add the code to the walking functions. It would also be easier to break the data gathering into two portions this way, so that we can get the most important base information first, then work on the perfecting of the system later.

I'm willing to help you work on this as much as you want. The code isn't hard to follow (I think) but I can work on commenting the logic and such more for everyone, writing a tut or whatever. I technically have no free time, but since I'm pretty accepting of any break from non-stop studying to relieve some stress, you can hit me up whenever.

Also check my posts on TAreas and TMMAreas and etc.

They could come in very handy at using color to detect which tile you are on.

From: Sir R. Magician
Also check my posts on TAreas and TMMAreas and etc.

They could come in very handy at using color to detect which tile you are on.

I can't seem to find them… :o

http://villavu.com/forum/showthread.php?t=58309&highlight=TColorArea

Read the 3rd post for explanation :)

~RM

SSRL R&D
http://villavu.com/forum/showthread.php?p=754538#post754538


A while ago I developed TAreas.

But I'll just give you the idea in pictures ;)

NOTICE 1: To perfectly walk somewhere you have to perfectly identify where you are AND perfectly identify the place to walk to.


This proves that it is possible to perfecty indentify your location with colour.

This is just me applying the technique on a Bank -> VEM walk.
I didn't bother to do the whole thing, but you get the picture

Normal - Key Points - Background TArea

Ideas / suggestions / comments / code, all welcome.

I have some code already, I'll fetch it later. :)

PS: All of this was done with RGB tol 10. It's as simple as that.

EDIT: I'd say go with Garrett's method first. This still needs development before even thinking of implementing it

~RM

Looks cool. I can see that you can gather all that information, but how do you know you're in the GE? Like what do you compare this gathered information to?

Also, nice FMing picture on the MM. :p

VERY Interesting, RM!
A function for finding walls would also be nice here, so you can check if an area is behind a wall or fence

From: Coh3n
Looks cool. I can see that you can gather all that information, but how do you know you're in the GE? Like what do you compare this gathered information to?

Also, nice FMing picture on the MM. :p

I guess we could always try having records for certain areas. Certain counts of certain colors etc.


Very interesting RM :)

From: NCDS
I guess we could always try having records for certain areas. Certain counts of certain colors etc.

This. And also you can probably imagine I'd throw in some hybrid shit to automatically create the TAreas ;)

~RM

I like the concept, but I do think it's going to be very hard to make it work well.

Moved this to public to see what other people think. :)

If you want to make an automated tile based color walking system it comes down to this: take the minimap, simplify it so that you are looking at certain things, and compare it to the world map simplified the same way. There are multiple methods of simplifying, and you will have to figure out which method works best, which may take a while. However I think the following can be applied to any method, and can be useful before the method is determined.

1) Whether the walking system ends up being automatically updated by reflection, backed up by reflection, both, or neither, it should be made in a reflection friendly way so that you have options (ie maybe one day being able to plug the same TPA into WalkPathColor as WalkPathReflection).

2) No matter which simplifying algorithm you use, the first thing needed is a non simplified word map.

3) The system needs to be efficient. Also it would be preferable if the system works when partially complete and gets better and better as opposed to being all or nothing.

The clean world map must not contain place names, drop/npc(except ones that don't wander)/player dots or symbols (approximate tile locations of symbols can be recorded in a file elsewhere). The map should be divided into square chunks, file names being something like CleanMap-01-03, with the numbers being the X,Y coords of the chunk (CleanMap-02-03 is the chunk to the east). The square chunks should start and end on tiles edges. The length of the size of the square should be divisible by 5 pixels (or however big a tile is), and further divisible by 2 or 3 tiles (so that it can be further divided into 4 or 9 mini chunks that also start and end on tiles if needed). The diagonal should be close (while still fitting the previous spec) to the diameter of the minimap, but not larger (see the small square here). The center of one of the chunks will be a known tile (or 4), so that pixel<->tile calculations may be made anywhere. If a java guru can get a clean extended minimap from the client, then awesome, just make the chunks and skip the next paragraph.

Cleaning the minimap takes several passes, and the world is big, so more people is better. I suggest choosing a frequently used reflection function like GetMyPos (or something that uses GetMyPos for less frequent) and building into it a data gatherer. Obviously, have it turned off by default, but ask users of reflection walking scripts to turn it on, and send in the resulting bitmaps. First, actually get your position, and then get the bounds of the square (see small square in pic linked to above) around you. Within this square are the tiles from 1, 2 or 4 chunks; calculate which ones. Check if these chunks are on the completed chunks lists (there are two lists, one list for the individual user, and one in the ref svn, more on that later), skip the chunks that are on either list. For each incomplete chunk, fill it in from the minimap, but skip tiles that are partially or fully covered by symbols/dots (at this point static npcs are filled in using a special file). If you complete a chunk (no more white space), mark it in the user list. The user then uploads the completed chunks, and on the next commit a ref dev updates the completed chunk list in the svn. If you aren't getting a lot of uploaded chunks, you can start accepting partially completed chunks and write something that combines them.

Once you have a decent number of adjacent clean chunks (preferably covering the walk of a popular script), you can start making simplified chunks from them. You can try different algorithms and see which works best by running an actual script or make a wandering around script, either way have reflection measure accuracy and keep it from getting lost. There's more about how to use a simplified chunk system, but this post is really meant to be about the prep work needed for multiple types of simplification; how to make the clean chunks.

From: Coh3n
Moved this to public to see what other people think. :)

RM wanted only SSRL and MSI to know exactly how this method of walking worked…

From: Zyt3x
RM wanted only SSRL and MSI to know exactly how this method of walking worked…

Don't worry about it, it's ok ;)

~RM

From: Sir R. Magician
Don't worry about it, it's ok ;)

~RM

Alright :)
I'll move it back to public then

From: Boreas
1) Whether the walking system ends up being automatically updated by reflection, backed up by reflection, both, or neither, it should be made in a reflection friendly way so that you have options (ie maybe one day being able to plug the same TPA into WalkPathColor as WalkPathReflection).

How would that work? One's tiles, the others main screen coordinates.

From: Boreas

3) The system needs to be efficient. Also it would be preferable if the system works when partially complete and gets better and better as opposed to being all or nothing.

That is how we were thinking with basically every part of our hybrid system.

From: Boreas

The clean world map must not contain place names, drop/npc(except ones that don't wander)/player dots or symbols (approximate tile locations of symbols can be recorded in a file elsewhere).

Where are we going to get that? As far as I know every map includes at least the symbols. =\

From: Boreas

The map should be divided into square chunks, file names being something like CleanMap-01-03, with the numbers being the X,Y coords of the chunk (CleanMap-02-03 is the chunk to the east).

I'm not sure what you mean. :o If it's a square, it won't really have x/y coords, unless you mean the center point of the square?

From: Boreas

The square chunks should start and end on tiles edges. The length of the size of the square should be divisible by 5 pixels (or however big a tile is), and further divisible by 2 or 3 tiles (so that it can be further divided into 4 or 9 mini chunks that also start and end on tiles if needed). The diagonal should be close (while still fitting the previous spec) to the diameter of the minimap, but not larger (see the small square here). The center of one of the chunks will be a known tile (or 4), so that pixel<->tile calculations may be made anywhere. If a java guru can get a clean extended minimap from the client, then awesome, just make the chunks and skip the next paragraph.

I'm kind of getting a little lost here. :p Here you're talking about the minimap in game, correct? Not the entire world map? So you would get the information from the minimap and compare it to the world map?

From: Boreas

Cleaning the minimap takes several passes, and the world is big, so more people is better. I suggest choosing a frequently used reflection function like GetMyPos (or something that uses GetMyPos for less frequent) and building into it a data gatherer. Obviously, have it turned off by default, but ask users of reflection walking scripts to turn it on, and send in the resulting bitmaps.

Bitmaps of what? The minimap? The minimap chunks?

From: Boreas
First, actually get your position, and then get the bounds of the square (see small square in pic linked to above) around you. Within this square are the tiles from 1, 2 or 4 chunks; calculate which ones. Check if these chunks are on the completed chunks lists (there are two lists, one list for the individual user, and one in the ref svn, more on that later), skip the chunks that are on either list.

Reflection devs may not want things like that in the repository in which case the chunks could just be saves in MSI if needed.

From: Boreas

For each incomplete chunk, fill it in from the minimap, but skip tiles that are partially or fully covered by symbols/dots (at this point static npcs are filled in using a special file). If you complete a chunk (no more white space), mark it in the user list. The user then uploads the completed chunks, and on the next commit a ref dev updates the completed chunk list in the svn. If you aren't getting a lot of uploaded chunks, you can start accepting partially completed chunks and write something that combines them.

Kind of lost again. What white space are you talking about? Would there be a predefined white bitmap for each chuck, and then periodically filled in as information is gathered?

From: Boreas

Once you have a decent number of adjacent clean chunks (preferably covering the walk of a popular script), you can start making simplified chunks from them. You can try different algorithms and see which works best by running an actual script or make a wandering around script, either way have reflection measure accuracy and keep it from getting lost. There's more about how to use a simplified chunk system, but this post is really meant to be about the prep work needed for multiple types of simplification; how to make the clean chunks.

I'm still not sure exactly how it would work when walking. If the chunks are saved as bitmaps and the center point is in the name, would the center point be coordinates of the world map? After all, we would want this to work without reflection, otherwise I don't really see the point in a TON of work if it wouldn't work without reflection.

In general, this all seems like a lot of work and dedication. :) I'm going to move this back to the SL section and create a new thread that is actually dealing with walking organization. This has become more of a ``future" of MSI walking. :)

From: Boreas
1) Whether the walking system ends up being automatically updated by reflection, backed up by reflection, both, or neither, it should be made in a reflection friendly way so that you have options (ie maybe one day being able to plug the same TPA into WalkPathColor as WalkPathReflection).

I agree, and this shouldn't be hard to do either.. It would be one of the easier parts

From: Boreas
The clean world map must not contain place names, drop/npc(except ones that don't wander)/player dots or symbols (approximate tile locations of symbols can be recorded in a file elsewhere). The map should be divided into square chunks, file names being something like CleanMap-01-03, with the numbers being the X,Y coords of the chunk (CleanMap-02-03 is the chunk to the east). The square chunks should start and end on tiles edges. The length of the size of the square should be divisible by 5 pixels (or however big a tile is), and further divisible by 2 or 3 tiles (so that it can be further divided into 4 or 9 mini chunks that also start and end on tiles if needed). The diagonal should be close (while still fitting the previous spec) to the diameter of the minimap, but not larger (see the small square here). The center of one of the chunks will be a known tile (or 4), so that pixel<->tile calculations may be made anywhere. If a java guru can get a clean extended minimap from the client, then awesome, just make the chunks and skip the next paragraph.

That's a good way to do it :) It's like minecraft.. :p
There would be max 4 chunks visible on the minimap at any times
And I'm not sure about getting a 'clean extended minimap from the client' but we could do it manually… Would take some time though..