SRL Archive - MSI Suggestions

[ADMIN]Anything below here is old, and is what was originally planned for this feature![/ADMIN]

If you haven't already, please read MSI & Reflection.

MSI intends to use reflection as a backup for color.

Here we will discuss all the planning for the hybrid system. Where do you think it should be used? How do you think it should be done? How do you think it should be organized?

Here's my thoughts so far:

• Will first be used for waiting functions (WaitWhileMining, WaitWhileChopping, etc.) and then expanded into item/object finding, and maybe eventually into walking. There are some possible scenarios for this:
1. Color thinks we're chopping, so we check with reflection. Reflection says we're chopping; therefore, the color routines work and we're still chopping.
2. Color thinks we're chopping, so we check with reflection. Reflection says we're not chopping; therefore, the color routines failed and we gather extensive debug information - screenshots, colors, etc. - and update them during runtime.
3. Color thinks we aren't chopping, so we check with reflection. Reflection says we are chopping; therefore, the color routines failed.
4. Both color and reflection say we aren't chopping; therefore, we aren't chopping.
The same concept can be applied to item and object finding (with slight variations, of course).
• We'll create a new function in Debug.simba that handles extensive color information gathering - screenshots, mostly - to be called upon when color routines fail.
• We'll use MSI's tracking system more so we can see how the color routines are doing, and update them if needed. I also think we can use Reflection to improve this system as well. We can track the tile that was clicked and make sure the color tracking is still tracking that tile. If it's not, we adjust it accordingly.
• An ID attribute will be added to the TItem & TMSObject records. An ID array will need to be added to the TScript record to hold the default IDs for each script.
• Since there are different animations for different pickaxes, hatchets, etc., I think we should use a global 2D array that holds the different animations.

MSI_Animations[SKILL_WOODCUTTING] := [123, 456, 789];
MSI_Animations[SKILL_MINING] := [987, 654, 321];

• We'll need an MSI_IsAnimating function, unless there's already one in Reflection. There is a function in reflection called R_IsAnimating or something along those lines.
• The item finding routines will have to be slightly edited to work with IDs, but that shouldn't be difficult at all.
• Probably the most tedious part of all - IDs will need to be collected for ALL MSI items and objects used throughout our scripts. There is now functions in Reflection that can get the IDs of items and objects based on their names. :)
• It also may not be a bad idea to have a Reflection.simba file that holds the strictly reflection routines.

Thoughts, suggestions?

You will have to make IDArrays for the objects. Glad you guys are finally doing this.

When exactly did we decide on this :confused:

If you want I can make a flawless chopping function for example based on the OP. And by flawless I truly flawless.

From: mormonman
You will have to make IDArrays for the objects. Glad you guys are finally doing this.

Okay, thanks. I'll update the first post.

From: NCDS
When exactly did we decide on this :confused:

http://villavu.com/forum/showthread.php?p=751253#post751253

From: cstrike
If you want I can make a flawless chopping function for example based on the OP. And by flawless I truly flawless.

OP?

And any contributions will help. :)

From: Coh3n

http://villavu.com/forum/showthread.php?p=751253#post751253

Looks to me like you and RM agreed upon it, and that's about it.


:/

From: NCDS
Looks to me like you and RM agreed upon it, and that's about it.


:/

No offence, but we can't wait for everyone to reply when some people aren't active for weeks at a time. If you don't agree on the system, feel free to post your opinion. :)

Things can always change. I don't see any disadvantages to the system as it's incorporating the best of both worlds. Color is still the main method of autoing, but it will be made better by using reflection in this way.

From: Coh3n
No offence, but we can't wait for everyone to reply when some people aren't active for weeks at a time. If you don't agree on the system, feel free to post your opinion. :)

I had posted in that thread a few times. I never said I agree with it, simply because I don't.

From: Coh3n

Things can always change. I don't see any disadvantages to the system as it's incorporating the best of both worlds. Color is still the main method of autoing, but it will be made better by using reflection in this way.

Do you honestly think people will continue to code in color though if we support Reflection for everything?

Personally I don't tink it should be used anywhere that it's not necessary. For instance, WaitWhileChopping. What's wrong with the current one?? I would say it works great honestly.

I'm not trying to come off pissy or as an ass at all, sorry if that's what it seems like. I just think this should have really been discussed more thoroughly /agreed upon in the SL forums, not just random peoples opinions.

If you need any help figuring out how something would work in reflection, feel free to drop me a PM on the forums, MSN, or on IRC and I'll try to help you guys answer any questions you might have.

Also, getting the ids of items is trivial enough with my cache editor, so I'll be happy to provide those for you guys if you're interested. Objects and npcs may be a little more difficult because the organization of npcs and objects with their 'parents' is slightly different.

From: Coh3n
OP?

Your opening post ;)

And any contributions will help. :)

:)


Also Method is pretty much God. He knows everything you'd ever need to know about reflection.

Instead of MSI_R_WaitWhileChopping(Fishing/Mining etc) I think it should be

MSI_R_WaitWhileAnim(Anim : Integer);

Thats really all I thought about involving this subject :)

From: Method
If you need any help figuring out how something would work in reflection, feel free to drop me a PM on the forums, MSN, or on IRC and I'll try to help you guys answer any questions you might have.

Also, getting the ids of items is trivial enough with my cache editor, so I'll be happy to provide those for you guys if you're interested. Objects and npcs may be a little more difficult because the organization of npcs and objects with their 'parents' is slightly different.

Okay thanks a lot, I'll keep that in mind. :)

[QUOTE=Camaro';751274]Instead of MSI_R_WaitWhileChopping(Fishing/Mining etc) I think it should be

MSI_R_WaitWhileAnim(Anim : Integer);

Thats really all I thought about involving this subject :)[/QUOTE]
Okay not a bad idea, thanks. :)

@NCDS: We'll continue this on MSN. Give me few to get on.

From: Coh3n
@NCDS: We'll continue this on MSN. Give me few to get on.

I'm quite interested too, to be honest. I liked MSI a lot for it's colour approach to a lot of things.

From: Wizzup?
I'm quite interested too, to be honest. I liked MSI a lot for it's colour approach to a lot of things.

To sum up, Reflection won't be replacing color. All scripts that have color walking will still work without reflection. Reflection will be used "in the background" as an aid for tracking our color routines. It will be used more or less as a confirmation that color worked, and if it didn't, the script won't fail because of it. Instead, it will gather the necessary debug information so we can improve the color routines later.

From: Coh3n
To sum up, Reflection won't be replacing color. All scripts that have color walking will still work without reflection. Reflection will be used "in the background" as an aid for tracking our color routines. It will be used more or less as a confirmation that color worked, and if it didn't, the script won't fail because of it. Instead, it will gather the necessary debug information so we can improve the color routines later.

It'll be interesting to see this develop then. I really wonder if MSI can keep up using colour first; instead of just relying on reflection. :)

From: Wizzup?
instead of just relying on reflection. :)

Will NEVER happen.

Was my exact concern, but should be all cleared up now :)

From: Wizzup?
It'll be interesting to see this develop then. I really wonder if MSI can keep up using colour first; instead of just relying on reflection. :)

I'm updating the announcement right now. NCDS said he got the wrong idea from the threads. That's my fault. I'm going to make it more clear right now. I'll edit this post in a couple minutes.

E: Added this to the announcement. Hopefully it clears up some confusion.

From: Coh3n
[INDENT]IMPORTANT:

Of course, the user will still have to choice between color and reflection. You can use strictly color, or the hybrid system. It is important to keep in mind that reflection is NOT replacing color in any way. Reflection will be used in the background as an aid to help us track and improve our color routines. We are in no way relying on reflection.

MSI currently gets 5-10 hour progress reports on one character, no problem. We aren't looking for longer reports, we looking for efficiency. We don't want our tracking system to accidentally be tracking the wrong tree and stand there doing nothing for 30+ seconds. We want to know exactly why it tracked the wrong tree so we can fix it.

I just want to avoid any confusion. Reflection IS NOT replacing color, it's improving color.[/INDENT]

E: @cstrike: We don't need a chopping function, sorry. What we need is a function to determine whether or not the player is chopping. There may already be an IsAnimating function in the reflection include, I'm not entirely sure.

E2: Updated the first post to clear some things up. Please read again if you were thinking of contributing.

From: Coh3n

E: @cstrike: We don't need a chopping function, sorry. What we need is a function to determine whether or not the player is chopping. There may already be an IsAnimating function in the reflection include, I'm not entirely sure.

Best way to check animation would be to find all the different animations for each axe, make a TIntArray out of it and then use something like "if GetAnimation is InIntArray(animationArray) then … "

I was honestly hoping to see how far MSI could go with just color :(. Oh well, I guess the best of both worlds will improve botting!

From: pyroryan
I was honestly hoping to see how far MSI could go with just color :(. Oh well, I guess the best of both worlds will improve botting!

We will still be using colour, the main point is that reflection will be able to (hopefully) eventually fix all the little technical problems which may arise during colour coding. Examples include a slight offset problem in the search area, maybe the tBox is too big and the original coder didn't see a problem that will occur, etc.

Also, as a side note, this would greatly improve Fishing.simba, which I doubt has had much development. I'm pretty much in hibernation underneath all this work, but Christmas break is coming up (Dec 17) so be prepared for way more participation from me between then and January.

From: cstrike
Best way to check animation would be to find all the different animations for each axe, make a TIntArray out of it and then use something like "if GetAnimation is InIntArray(animationArray) then … "

Wait… there's a different animation for every hatchet?

From: pyroryan
I was honestly hoping to see how far MSI could go with just color :(. Oh well, I guess the best of both worlds will improve botting!

What Garrett said. :)

Some people seem to be getting the wrong idea. If you haven't reread the announcement since I updated it, please do.

From: Coh3n
Wait… there's a different animation for every hatchet?

I think so :(
I know there is a different animation for each pickaxe.

Though they tend to be in a close range from bronze–>rune, but dragon or other axes will be some huge weird number like 11251 instead of 1533 or 1535.

From: cstrike
I think so :(
I know there is a different animation for each pickaxe.

Though they tend to be in a close range from bronze–>rune, but dragon or other axes will be some huge weird number like 11251 instead of 1533 or 1535.

That has to be one of the weirdest things I've every heard… Why not just one animation for mining? It's the same for all pickaxes with the exception of dragon.

From: pyroryan
I was honestly hoping to see how far MSI could go with just color :(. Oh well, I guess the best of both worlds will improve botting!

People will be able to run MSI without using the Hybrid version still.

Getting all the info shouldn't be a big problem.

We can run MSI (colour) and make it spit out the reflection information we need.

Afterall if reflection can be used as a backup for color, color can be used as a backup for reflection. ;)

~RM

From: Coh3n
That has to be one of the weirdest things I've every heard… Why not just one animation for mining? It's the same for all pickaxes with the exception of dragon.

If im not mistaken, its because of the axe. Because the user is holding a different axe, it has to be a different animation.

Or maybe im just a stupid person who thinks he knows things he doesn't ;)

But yeah, its pretty stupid.

Moving on to the original topic, I'm fine with this, as long as color is still used primarily.

As for getting IDs, the RS item DB contains the items ID. IDs can also be dumped with reflection or rsbot.

From: nickrules
If im not mistaken, its because of the axe. Because the user is holding a different axe, it has to be a different animation.

Well yeah, the the animation itself looks exactly the same.

From: Sir R. Magician
Afterall if reflection can be used as a backup for color, color can be used as a backup for reflection. ;)

~RM

That's what I think is bad with this whole idea…
People will eventually stop developing color stuff and purely rely on reflection

From: Zyt3x
That's what I think is bad with this whole idea…
People will eventually stop developing color stuff and purely rely on reflection

People already do.

~RM

From: Sir R. Magician
People already do.

~RM

I though we agreed that was a bad thing?

Are we moving to reflection only?

whaaaat? ._.

From: Zyt3x
I though we agreed that was a bad thing?

Are we moving to reflection only?

whaaaat? ._.

He was most likely stating a fact. We've been able to move to reflection for a while now, those who have stayed with colour until now are likely to continue with it, regardless of the option for reflection.

From: Zyt3x
I though we agreed that was a bad thing?

Are we moving to reflection only?

whaaaat? ._.

From: 3Garrett3
He was most likely stating a fact. We've been able to move to reflection for a while now, those who have stayed with colour until now are likely to continue with it, regardless of the option for reflection.

There won't be any Reflection option. The user will be able to choose between the way it is now, or more Reflection failsafes (hybrid).

From: NCDS
There won't be any Reflection option. The user will be able to choose between the way it is now, or more Reflection failsafes (hybrid).

From: Sir R. Magician
Afterall if reflection can be used as a backup for color, color can be used as a backup for reflection. ;)

~RM

I guess RM just confused me then… :P
Then it's all fine :)

From: NCDS
There won't be any Reflection option. The user will be able to choose between the way it is now, or more Reflection failsafes (hybrid).

I meant from a scripter point of view.

If anyone is looking to help out with this, some easy things that can be done are:

• Item IDs need to be gathered for the MSI items.

const
  PICKAXE_BRONZE  = 10;
  PICKAXE_IRON    = 11;
  PICKAXE_STEEL   = 12;
  PICKAXE_MITHRIL = 13;
  PICKAXE_ADAMANT = 14;
  PICKAXE_RUNE    = 15;
  PICKAXE_DRAGON  = 16;

  HATCHET_BRONZE  = 20;
  HATCHET_IRON    = 21;
  HATCHET_STEEL   = 22;
  HATCHET_MITHRIL = 23;
  HATCHET_ADAMANT = 24;
  HATCHET_RUNE    = 25;
  HATCHET_DRAGON  = 26;

  LOGS_NORMAL     = 30;
  LOGS_OAK        = 31;
  LOGS_WILLOW     = 32;
  LOGS_MAPLE      = 33;
  LOGS_YEW        = 34;
  LOGS_MAGIC      = 35;

  ORE_CLAY        = 40;
  ORE_COPPER      = 41;
  ORE_TIN         = 42;
  ORE_IRON        = 43;
  ORE_SILVER      = 44;
  ORE_COAL        = 45;
  ORE_GOLD        = 46;
  ORE_MITHRIL     = 47;
  ORE_ADAMANTITE  = 48;
  ORE_RUNITE      = 49;

  FISH_SMALLNET       = 60;
  FISH_CRAYPOT        = 61;
  FISH_ROD_BAIT       = 62;
  FISH_BAIT           = 63;
  FISH_ROD_FLY        = 64;
  FISH_HARPOON        = 65;
  FISH_CAGE           = 66;

  FISH_RAW_SHRIMP     = 70;
  FISH_RAW_CRAYFISH   = 71;
  FISH_RAW_SARDINE    = 72;
  FISH_RAW_HERRING    = 73;
  FISH_RAW_ANCHOVIE   = 74;
  FISH_RAW_TROUT      = 75;
  FISH_RAW_PIKE       = 76;
  FISH_RAW_SALMON     = 77;
  FISH_RAW_TUNA       = 78;
  FISH_RAW_LOBSTER    = 79;
  FISH_RAW_SWORDFISH  = 80;

  FISH_COOKED_SHRIMP    = 100;
  FISH_COOKED_CRAYFISH  = 101;
  FISH_COOKED_SARDINE   = 102;
  FISH_COOKED_HERRING   = 103;
  FISH_COOKED_ANCHOVIE  = 104;
  FISH_COOKED_TROUT     = 105;
  FISH_COOKED_PIKE      = 106;
  FISH_COOKED_SALMON    = 107;
  FISH_COOKED_TUNA      = 108;
  FISH_COOKED_LOBSTER   = 109;
  FISH_COOKED_SWORDFISH = 110;

  GEM_SAPPHIRE = 120;
  GEM_EMERALD  = 121;
  GEM_RUBY     = 122;
  GEM_DIAMOND  = 123;

  MISC_BIRD_NEST = 130;
  MISC_FEATHER   = 131;

  STAFF_AIR   = 150;
  STAFF_WATER = 151;
  STAFF_EARTH = 152;
  STAFF_FIRE  = 153;

  // These constants have to match the rune constants in SRL's magic.simba
  MSI_RUNE_AIR    = 160; // Has 'MSI_' because there are other rune constants in SRL
  MSI_RUNE_BODY   = 161;
  MSI_RUNE_MIND   = 162;
  MSI_RUNE_EARTH  = 163;
  MSI_RUNE_FIRE   = 164;
  MSI_RUNE_WATER  = 165;
  MSI_RUNE_CHAOS  = 166;
  MSI_RUNE_LAW    = 167;
  MSI_RUNE_COSMIC = 168;
  MSI_RUNE_DEATH  = 169;
  MSI_RUNE_NATURE = 170;
  MSI_RUNE_BLOOD  = 171;
  MSI_RUNE_SOUL   = 172;
  MSI_RUNE_ASTRAL = 173;           

• All the animatons need to be collected for Mining, Fishing, Woodcutting, and Alching.
• Object IDs need to be collected for all MSI's objects (although this is probably going to be the last thing implemented).

const
  TREE_NORMAL = 10;
  TREE_OAK    = 11;
  TREE_WILLOW = 12;
  TREE_MAPLE  = 13;
  TREE_YEW    = 14;
  TREE_MAGIC  = 15;

  ROCK_CLAY       = 20;
  ROCK_TIN        = 21;
  ROCK_COPPER     = 22;
  ROCK_IRON       = 23;
  ROCK_SILVER     = 24;
  ROCK_COAL       = 25;
  ROCK_GOLD       = 26;
  ROCK_MITHRIL    = 27;
  ROCK_ADAMANTITE = 28;
  ROCK_RUNITE     = 29;

  MSI_BANK_VE = 30;  // Includes the 'MSI_' because there are bank constants in SRL's Bank.scar
  MSI_BANK_VW = 31;
  MSI_BANK_DB = 32;
  MSI_BANK_GE = 33;
  MSI_BANK_FE = 34;
  MSI_BANK_EV = 35;
  MSI_BANK_SV = 36;

  DBOX_PS = 40;

  FISHSPOT_NET     = 50;
  FISHSPOT_BAIT    = 51;
  FISHSPOT_LURE    = 52;
  FISHSPOT_CAGE    = 53;
  FISHSPOT_HARPOON = 54;

  COOKSPOT_FIRE   = 60;
  COOKSPOT_RANGE  = 61;

  OBJ_BIRD_NEST       = 70;                 

I'm sure I forgot something, so please let me know if I did. :)

Cheers,
Coh3n

const
  PICKAXE_BRONZE  = 1265;
  PICKAXE_IRON    = 1267;
  PICKAXE_STEEL   = 1269;
  PICKAXE_MITHRIL = 1273;
  PICKAXE_ADAMANT = 1271;
  PICKAXE_RUNE    = 1275;
  PICKAXE_DRAGON  = 15259;

  HATCHET_BRONZE  = 1351;
  HATCHET_IRON    = 1349;
  HATCHET_STEEL   = 1353;
  HATCHET_MITHRIL = 1355;
  HATCHET_ADAMANT = 1357;
  HATCHET_RUNE    = 1359;
  HATCHET_DRAGON  = 6739;

  LOGS_NORMAL     = 1511;
  LOGS_OAK        = 1521;
  LOGS_WILLOW     = 1519;
  LOGS_MAPLE      = 1517;
  LOGS_YEW        = 1515;
  LOGS_MAGIC      = 1513;

  ORE_CLAY        = 434;
  ORE_COPPER      = 436;
  ORE_TIN         = 438;
  ORE_IRON        = 440;
  ORE_SILVER      = 442;
  ORE_COAL        = 453;
  ORE_GOLD        = 444;
  ORE_MITHRIL     = 447;
  ORE_ADAMANTITE  = 449;
  ORE_RUNITE      = 451;

  FISH_SMALLNET       = 303;
  FISH_CRAYPOT        = 13431; // crayfish cage
  FISH_ROD_BAIT       = 304;
  FISH_BAIT           = 313;
  FISH_ROD_FLY        = 309;
  FISH_HARPOON        = 311;
  FISH_CAGE           = 301; // lobster pot

  FISH_RAW_SHRIMP     = 317;
  FISH_RAW_CRAYFISH   = 13435;
  FISH_RAW_SARDINE    = 327;
  FISH_RAW_HERRING    = 345;
  FISH_RAW_ANCHOVIE   = 321;
  FISH_RAW_TROUT      = 335;
  FISH_RAW_PIKE       = 349;
  FISH_RAW_SALMON     = 331;
  FISH_RAW_TUNA       = 359;
  FISH_RAW_LOBSTER    = 377;
  FISH_RAW_SWORDFISH  = 371;

  FISH_COOKED_SHRIMP    = 315;
  FISH_COOKED_CRAYFISH  = 13433;
  FISH_COOKED_SARDINE   = 325;
  FISH_COOKED_HERRING   = 347;
  FISH_COOKED_ANCHOVIE  = 319;
  FISH_COOKED_TROUT     = 333;
  FISH_COOKED_PIKE      = 351;
  FISH_COOKED_SALMON    = 329;
  FISH_COOKED_TUNA      = 361;
  FISH_COOKED_LOBSTER   = 379;
  FISH_COOKED_SWORDFISH = 373;

  GEM_SAPPHIRE = 1607; // 1623 uncut
  GEM_EMERALD  = 1605; // 1621 uncut
  GEM_RUBY     = 1603; // 1619 uncut
  GEM_DIAMOND  = 1601; // 1617 uncut

  MISC_BIRD_NEST = 130; // 5070-5075, 7413, 11966 (you may need to investigate these)
  MISC_FEATHER   = 314;

  STAFF_AIR   = 1381;
  STAFF_WATER = 1383;
  STAFF_EARTH = 1385;
  STAFF_FIRE  = 1387;

  // These constants have to match the rune constants in SRL's magic.simba
  MSI_RUNE_AIR    = 556; // Has 'MSI_' because there are other rune constants in SRL
  MSI_RUNE_BODY   = 559;
  MSI_RUNE_MIND   = 558;
  MSI_RUNE_EARTH  = 557;
  MSI_RUNE_FIRE   = 554;
  MSI_RUNE_WATER  = 555;
  MSI_RUNE_CHAOS  = 562;
  MSI_RUNE_LAW    = 563;
  MSI_RUNE_COSMIC = 564;
  MSI_RUNE_DEATH  = 560;
  MSI_RUNE_NATURE = 561;
  MSI_RUNE_BLOOD  = 565;
  MSI_RUNE_SOUL   = 566;
  MSI_RUNE_ASTRAL = 9075;

As noted, there are a few discrepancies. Some items also can have a few IDs (like the bird's nest). Objects are the same way, so you'll need to be able to properly handle that.

From: Method
As noted, there are a few discrepancies. Some items also can have a few IDs (like the bird's nest). Objects are the same way, so you'll need to be able to properly handle that.

That's awesome, Method, thanks a lot! :)

How come some items have multiple IDs? I'm just curious. It won't be any more difficult to handle. Same with Objects. I'm not sure if you answered this, but is there a different object ID for every tree? If so, we'll just have to go to each location and gather the object IDs. This will have to be discussed further as to the best way of going about it. I was hoping it would be as easy as adding an ID attribute to the TMSObject record. :(

Also, is RSBot still the easiest method for gathering IDs?

E: I changed some of the constant names. Thanks for clearing that up. :)

From: Coh3n
How come some items have multiple IDs? I'm just curious. It won't be any more difficult to handle. Same with Objects.

I know that there are multiple bird's nests because you can receive different ones with different items inside and they have different appearances. One contains herb seeds, another tree seeds (this might be the same as the other), one rings, and others eggs.

As for objects, there are usually multiple objects for the same sort of object (like trees or rocks, for example) when they have different models. Not all trees or rocks look the exact same, so more than one object exists for the same "actual object". Each will have a different model than the others.

From: Coh3n
I'm not sure if you answered this, but is there a different object ID for every tree? If so, we'll just have to go to each location and gather the object IDs. This will have to be discussed further as to the best way of going about it. I was hoping it would be as easy as adding an ID attribute to the TMSObject record. :(

Not every tree of the same type will have a different id, but there will likely be several different ones between multiple trees of the same type in an area, and perhaps more throughout the entire world. You'll need to make sure you cover them all for the particular area you're in.

From: Coh3n
Also, is RSBot still the easiest method for gathering IDs?

It probably will be, because you can turn on a debug setting and see everything visually. Running a script with Simba to do the same thing will take more time and require more work.

All makes sense. Thanks a lot for the help. :)

Soon you may have access to all the ID's from a list… hold tight, it may come soon ;)

From: cstrike
Soon you may have access to all the ID's from a list… hold tight, it may come soon ;)

That would certainly make my job a lot easier. :D

From: Coh3n

Since there are different animations for different pickaxes, hatchets, etc., I think we should use a global 2D array that holds the different animations.

MSI_Animations[SKILL_WOODCUTTING] := [123, 456, 789];
MSI_Animations[SKILL_MINING] := [987, 654, 321];

We'll use MSI's tracking system more so we can see how the color routines are doing, and update them if needed. I also think we can use Reflection to improve this system as well. We can track the tile that was clicked and make sure the color tracking is still tracking that tile. If it's not, we adjust it accordingly.

I've updated the first post in various areas. This one I'd like you to take note of.

E: The hybrid walking has now been committed. The users now have the choice to use reflection, color, or hybrid walking systems.

From: Coh3n
That would certainly make my job a lot easier. :D

What ID's are you in need of?
:)

-Boom

From: Coh3n

We'll need an MSI_IsAnimating function, unless there's already one in Reflection.

Probably the most tedious part of all - IDs will need to be collected for ALL MSI items and objects used throughout our scripts. There is now functions in Reflection that can get the IDs of items and objects based on their names. :)

We can cross out the first point ^ because there is already R_IsAnimating or something along those lines. If not, it would be a simple check of

If Not inIntArray(AnimationArray, GetAnimation) Then //This means we have paused in fishing

^This example directly from my Karamja fisher. It compares your current animation with a given AnimationArray, which I have set as a constant. We could make this animation array specific based on what the user is doing, or make it general for each skill.

Also, you said it would make it easier if we have a list of ID's but you have the second point ^ crossed out with a solution already ;)

From: 3Garrett3
We can cross out the first point ^ because there is already R_IsAnimating or something along those lines. If not, it would be a simple check of

If Not inIntArray(AnimationArray, GetAnimation) Then //This means we have paused in fishing

^This example directly from my Karamja fisher. It compares your current animation with a given AnimationArray, which I have set as a constant. We could make this animation array specific based on what the user is doing, or make it general for each skill.

Also, you said it would make it easier if we have a list of ID's but you have the second point ^ crossed out with a solution already ;)

SRL/SRL/Core/Animation.scar

Everything in there works great, pointless to use Reflection where it's not needed. (coming from a color scripts point of view)

From: NCDS
SRL/SRL/Core/Animation.scar

Everything in there works great, pointless to use Reflection where it's not needed. (coming from a color scripts point of view)

I was just making a response to his point ;).

E: I just tried altering our current pixel shift data to work with Animating. It didn't work, returned false each time. I'm saying that it would be extremely more reliable to use Reflection.

From: Cstrike
Soon you may have access to all the ID's from a list… hold tight, it may come soon ;)

Oh hey old friend. :)

~RM

From: Sir R. M8gic1an
Oh hey old friend. :)

~RM

That post was from before he left. ;)

From: NCDS
That post was from before he left. ;)

It's not hard to debug shit anyways ;) and if we do get a debug-submitting system it'll be even easier :)

~RM

From: 3Garrett3
I was just making a response to his point ;).

E: I just tried altering our current pixel shift data to work with Animating. It didn't work, returned false each time. I'm saying that it would be extremely more reliable to use Reflection.

If you were trying with fishing then that's probably why. The fishing movements are weird and would be harder to make work properly, but I think think it could be done. Oh and just edit the first post if I made some mistakes.

And, I'm pretty sure reflection has a database that stores all item/object IDs.

From: Coh3n
If you were trying with fishing then that's probably why. The fishing movements are weird and would be harder to make work properly, but I think think it could be done. Oh and just edit the first post if I made some mistakes.

And, I'm pretty sure reflection has a database that stores all item/object IDs.

Yeah, I was saying that for fishing the best option is to use reflection. I'll strike it out in your list since there is already a function in reflection for it.

Yes, they do. You had that written in the first post, but replied to CStrike's post (a long time after he posted it) that it would be useful, I was just reminding you.

From: 3Garrett3
Yeah, I was saying that for fishing the best option is to use reflection. I'll strike it out in your list since there is already a function in reflection for it.

I still think it can be tweaked to make it work, but the hybrid animating system will be the same as the walking (as will all hybrid systems), so the color methods will be confirmed with reflection anyway.

From: 3Garrett3

Yes, they do. You had that written in the first post, but replied to CStrike's post (a long time after he posted it) that it would be useful, I was just reminding you.

Yeah, should probably take out that the IDs need to be gathered since they no longer do. E: I see you've already done that. :p

E: Revisiting this, I just thought, something like this may work for objects and item finding.

function MSI_FindItem(item: TItem): boolean;
var
  x, y: integer;
begin
  if (findDTM(x, y, item.dtm, MIX1, MIY1, MIX2, MIY2)) then
    if (isItemIDAt(item.name)) then
    begin
      writeln('found item ('+item.name+')');
      result := true;
    end;
end;

There are Reflection functions that can find at item by name, right?

E: Now that reflection is dead, it's safe to say that this probably won't be happening. :p