SRL Archive - General

Hello! :)

Before I start I want to say that this is just for discussion. I've been thinking about it the last few days and just want to see what everyone thinks. I think we need to start thinking about what is best for MSI in the future rather than preserving MSI's past and current state. Yes, I'm talking about replacing color with reflection. Before you go ripping my head off, just think about the pros and cons. Oh, and just for the record, I don't particularly like the idea, but I'm thinking about MSI's future rather than what I want.

PROS:

• Reflection can do everything color can plus more with next to no effort. Why is this good?
-> Because more can get done in shorter amounts of time.
• The majority of people choose reflection scripting over color simply because it's easier and it always works without error. What does that mean?
-> Currently, there are only a few of us who know MSI code well enough to maintain. -> We aren't going to be around forever and let's face it, more people are willing to contribute using reflection than color.
• Much, much, much easier to maintain. Right now it's hard for the few of us to keep up with bug reports, suggestions, and planned features. It just leads to frustration and (at least personally) leaves us thinking, "Wow, I could have done in 1 line with reflection what I just did in 50 lines with color, and it probably works better."
• I think the most important thing: community involvement. Sure, we get tons of feedback (bugs, suggestions, requests, etc.), but there has been less than a few people who have actually contributed a decent amount of code toward MSI. I am pretty confident that community contributions will increase if reflection was to be used.

CONS:

• We all know it's possible that Jagex may make an update that could potentially break reflection, but I highly doubt that reflection would be "unfixable."
• Are there any cons to reflection other than it could break?
• Sadly, color botting may slowly die. :(

I don't want anyone thinking this is what I want to do, it's just something that I want people to think about. The reason this came to my mind is because scripting is slowly getting more and more boring for me, and I was thinking about what MSI would be like if I suddenly left, and honestly, I didn't like it.

We have to think about keeping MSI alive rather than keeping it the way we want. We may not particularly like it, but it very well may be what's best for MSI and it's figure.

MSI is an amazing concept and I honestly don't know if there's any script (for any bot) that's quite like it. That's what's so amazing about it, it's unique. It's not going to be known as color script, it's going to be know as a script that does EVERYTHING. Let's be realistic, this

From: Rasta Magician

MSI's aim is to have a do-it-all-everywhere script. Does this sound ambitious? It sure as hell is. It would be the ultimate script, untraceable, impossible to detect and you could just run it, return a few years later and have a char at all 99 levels. Now doesn't that sound amazing?

isn't even visible with strictly color.

Finally, we talked about reflection/color hybrid. I've pretty much kept my real opinion about this quite as I think it's, well, pointless. Reflection doesn't fail if used properly. If reflection fails, why would color work? Not to mention the color part of the "hybrid" would be left in the dust; the only people willing to develop it would be the old school scripters, rather than new members.

Again, this is just for discussion. I honestly think it may be necessary. Yes, this may be bad timing, with the update coming and everything, but that's just it's just being discussed. I had a lot of thoughts and I thought you guys should read them. ;)

Cheers,
Cohen

E: Just another thing, reflection is already being phased in, whether you see it or not. Eventually, I think it's going to take over regardless. Just my opinion.

Without getting into an essay (it's late) I'll just state that I agree.

It definitely isn't what everyone wants to see, simply because we all know that colour is more reliable to not break forever, like the RuneTek engine. If reflection breaks again for a year, it could be the end of MSI, lots of people would be gone, nobody would be around to make sure that things are maintained.

But on the plus side, we make MSI a project which never fails when used with reflection, and SRL basically becomes a powerhouse, IMO. Nobody else has a do it all script this good.

From: 3Garrett3
If reflection breaks again for a year, it could be the end of MSI, lots of people would be gone, nobody would be around to make sure that things are maintained.

Well that's something I'm interested in. I'd eventually like to learn how reflection interacts with the client and exactly how it works.

I know you know my opinions on this, but just to make them public…

I'm somewhat of a color elitist. With that being said, I realize that fighting to be 100% color is pointless, and honestly, selfish.

First thing's first. No one knows what Jagex is going to include in the update with free trade being re-introduced. Last time reflection was broken for quite sometime, and no one can guarantee that won't happen again. To me, that's unacceptable for MSI.

As far as needing to switch to mainly Reflection to get the community to contribute, that's honestly pathetic. This community was built on color and has come this far with that mindset. I don't think we should have to change to accommodate to a new lazier generation.

You say you lose interest in coding for MSI in color, but honestly, I find Reflection coding quite boring. I don't want to write 4 lines and have a whole functioning function/script with no effort. What's fun about that? where is the challenge?
[/selfish rant]

I do agree that the future of MSI will most likely be dependent on Reflection. As upsetting as that is, I accept it. I personally am not going to change and am not going to let MSI stop supporting color. Plain and simple, as long as I'm around MSI will have color code.

I just feel that we would be recreating an RSBot type thing by switching MSI to 100% Reflection, which is honestly the last thing I want to do. Don't bother flaming that sentence with "RSBot isn't Reflection blah blah blah", I really don't care.

From: Coh3n

If reflection fails, why would color work?

Reflection is broken or hooks are down. I will very honestly admit the maintenance of Reflection has been much better lately. Like I mentioned before though, no one can guarantee this update won't break it again.

Unfortunately my roommates won't shut the hell up and are yelling a conversation right next to me so it's pretty hard to focus on this right now, but I guess I can just leave it at that for now. I have absolutely NOTHING against Reflection and fully support using it as a TOOL. I don't want to use it as the core of our code and I'll leave it at that for now to see what other people have to say.

From: NCDS

You say you lose interest in coding for MSI in color, but honestly, I find Reflection coding quite boring. I don't want to write 4 lines and have a whole functioning function/script with no effort. What's fun about that? where is the challenge?
[/selfish rant]

I didn't mean to say that reflection would be more fun for me. I should have said that I can still develop and maintain MSI without having to consider the color side of it (which would take hours and hours compared to some reflection code). That way I may actually have the time to learn something I'm more interested in.

From: NCDS

I do agree that the future of MSI will most likely be dependent on Reflection. As upsetting as that is, I accept it. I personally am not going to change and am not going to let MSI stop supporting color. Plain and simple, as long as I'm around MSI will have color code.

Again, I didn't mean to say that it would be completely replaced (even though I think I did say that :p). I think just the major parts would need replacing (objects, animations, items, etc.).

From: NCDS

I just feel that we would be recreating an RSBot type thing by switching MSI to 100% Reflection, which is honestly the last thing I want to do. Don't bother flaming that sentence with "RSBot isn't Reflection blah blah blah", I really don't care.

Like I said, I don't believe it's about how it's coded, but what it can actually do.

From: NCDS

Reflection is broken or hooks are down. I will very honestly admit the maintenance of Reflection has been much better lately. Like I mentioned before though, no one can guarantee this update won't break it again.

Well yeah, obviously, but I meant when it's working. ;)

From: Coh3n
I didn't mean to say that reflection would be more fun for me. I should have said that I can still develop and maintain MSI without having to consider the color side of it (which would take hours and hours compared to some reflection code). That way I may actually have the time to learn something I'm more interested in.


Again, I didn't mean to say that it would be completely replaced (even though I think I did say that :p). I think just the major parts would need replacing (objects, animations, items, etc.).


Like I said, I don't believe it's about how it's coded, but what it can actually do.


Well yeah, obviously, but I meant when it's working. ;)

Yeah , a lot of that wasn't directed right at you, but just stating my opinion on it. Your one of my closest friends on here and I'm with you with MSI till the end, regardless of what direction we go in. :)

From: NCDS
Yeah , a lot of that wasn't directed right at you, but just stating my opinion on it. Your one of my closest friends on here and I'm with you with MSI till the end, regardless of what direction we go in. :)

Thanks, I'm glad you feel that way. :)

I didn't read the whole post, but I'll just start with that the hell bit you?

All MSI needs for it to be maintained is color tweaks on our records database.

That's all MSI needs.

For MSI to be improved it needs more than that.

And perhaps reflection is exactly what it needs.

function FindMSIObj(Obj: TMSIObj): boolean;
var
  ColorResult, RefResult: TPoint;
begin
  //get the point?

  if not InCircle(ColorResult, RefResult, 10) then
  begin
    MSI_SubDebug('Color too far from Ref: 10');
    TrackR(FUNC_MSIFindObj, false);
    MoveAndClick(RefResult);
  end else begin
 //
end;

so first of all, nothing needs replacing. Some may need a little editing.
Then, this gives everyone a chance to not only learn reflection, but hybridity as we already have colour.
And finally, this open another whole dimension for MSI.

Also, my position on reflection is that reflection should not be used to replace color.
IMO Reflection should be used for 3 things:
To Build Tools for colour or the user
To do things colour can't do or can't do invisibly (eg: read equipment or stats without changing tabs)
And to Perfect colour through hybridity.

And ok, to pump out fast code.

But NEVER, EVER, EVER mention replacing colour to me again. Especially if you've been having a good read around the forums you'll notice that colour is the very reason SRL is the oldest cheating community alive.

~RM

~RM

From: Sir R. Magician
I didn't read the whole post, but I'll just start with that the hell bit you?

All MSI needs for it to be maintained is color tweaks on our records database.

That's all MSI needs.

For MSI to be improved it needs more than that.

And perhaps reflection is exactly what it needs.

function FindMSIObj(Obj: TMSIObj): boolean;
var
  ColorResult, RefResult: TPoint;
begin
  //get the point?

  if not InCircle(ColorResult, RefResult, 10) then
  begin
    MSI_SubDebug('Color too far from Ref: 10');
    TrackR(FUNC_MSIFindObj, false);
    MoveAndClick(RefResult);
  end else begin
 //
end;

~RM

I'm sorry, but I didn't understand that post at all?

From: Sir R. Magician
I didn't read the whole post, but I'll just start with that the hell bit you?

All MSI needs for it to be maintained is color tweaks on our records database.

That's all MSI needs.

For MSI to be improved it needs more than that.

And perhaps reflection is exactly what it needs.

function FindMSIObj(Obj: TMSIObj): boolean;
var
  ColorResult, RefResult: TPoint;
begin
  //get the point?

  if not InCircle(ColorResult, RefResult, 10) then
  begin
    MSI_SubDebug('Color too far from Ref: 10');
    TrackR(FUNC_MSIFindObj, false);
    MoveAndClick(RefResult);
  end else begin
 //
end;

~RM

What bit me is the fact that for the last year basically all I've done it develop MSI. No offense to you guys, but the fact is I've written 90% of it. Obviously, MSI wouldn't be where it is now without everyone's help, but it wouldn't be here now if it wasn't for me either. I do not want to see MSI die simply because of lack of developers. Yes, I would like to move on to different things, but I can't. There's no one to take my place. If I leave, yes I'm sure it can be maintained, but it won't expand unless you or NCDS somehow get the same amount of spare time as me. Reflection is easier to develop, PEOPLE ALWAYS TAKE THE EASY WAY OUT. The majority does anyway. People will create bots that work. Color scripting is frustrating, especially for a new user. Think about if you just joined looking for some RS bots, would you learn color or reflection?

You know what, fuck it, Nava told me this a while ago and he's right. When it stops being fun, it's not worth it.

From: NCDS
I'm sorry, but I didn't understand that post at all?

try again

Coh3n, don't go bursting bubbles just yet. Don't think you're the only one handling mantles here.

Here's my edit / continuation:

From: RM


so first of all, nothing needs replacing. Some may need a little editing.
Then, this gives everyone a chance to not only learn reflection, but hybridity as we already have colour.
And finally, this open another whole dimension for MSI.

Also, my position on reflection is that reflection should not be used to replace color.
IMO Reflection should be used for 3 things:
To Build Tools for colour or the user
To do things colour can't do or can't do invisibly (eg: read equipment or stats without changing tabs)
And to Perfect colour through hybridity.

And ok, to pump out fast code.

But NEVER, EVER, EVER mention replacing colour to me again. Especially if you've been having a good read around the forums you'll notice that colour is the very reason SRL is the oldest cheating community alive.

~RM

Then, to get the community involved you have to actually get the community involved. I think you already saw the other thread ;)

~RM

It's just frustrating, that's all.

And the reason I said replace color is because if we start using reflection more, color will be forgotten and there'll just be unused code sitting there not serving a purpose. Unless of course it's written to automatically maintain itself.

The only problem I see with the other thread is MSI getting bloated with shitty, unorganized code, unless someone was go go through it all and organize it, and I'm telling you right now it's not going to be me.

SLs say yes or no.

SLs also set the quality limit and there's a tracker for quality.

SLs can also ask the user to post debug to prove things work.

I've set down the rule that all files have to be uploaded.

And finally SLs have the last say.

So don't fuck me over. nickrules' code was just fine.

THIS is a community project. Not the whole community is perfect at scripting. Some people need practice.

So don't go calling code shitty.

CStrike's code was too shitty but he still made a worldwalker and developed a good chunk of reflection, whether java or ps reflection.

I'm not saying take all the code. I'm saying take the code that works, and on top of that there's the EXTRAS system which allows you to enable and disable code. MSI was built to accept user contributions.

~RM

From: Sir R. Magician
SLs say yes or no.

SLs also set the quality limit and there's a tracker for quality.

K, I thought the title meant say yes or no to your idea, not what get's added. My mistake.

From: Sir R. Magician

So don't fuck me over. nickrules' code was just fine.

Uhm, what?

From: Sir R. Magician

CStrike's code was too shitty but he still made a worldwalker and developed a good chunk of reflection, whether java or ps reflection.

Again, what?

When I said shitty I didn't mean to imply any code currently in MSI is shitty. And when I posted that I didn't realized what your title meant. I thought you wanted everything added as long as it worked.

And now everything's clarified :D

~RM

I'm basically a retired cranky old man, but I'll throw in my 2 million cents anyway and you can take what you want. What goals you have for MSI is completely up to you guys, but what I would like to see in MSI and all scripts, SRL, and Simba, is a creating a thriving community. More specifically, undetectable of course, army/break support, AI (not technically AI, but you know what I mean), a variety of scripts, ease of use, and progress reports measured in days and weeks (or just being able to auto 24x7, and only stopping when the user chooses to take breaks for antiban). It seems to me that working towards a goal of a 3 month progress report can't be a bad thing, whether we reach that point or not.

As for color vs reflection, in a broad sense, they are both the same thing. Every you need to click on in runescape has two attributes (not counting OpenGL); color and ID. Both of these are controlled by jagex, not us, and can change at their whim. Color and reflection are the same thing because they both use one of these attributes, and break when that attribute changes. Color has autocolors and algorithms, reflection has updaters. Obviously in a more narrow sense, there are differences. You can write reflection code faster than color. Reflection breaks more often than color, but can be fixed faster than color most of the time.

Getting tired, so here's a list of things I'd like to see, you can probably guess the reasoning

Scripts that can continue through an update, so something to reload the client at the appropriate time.
Hooks and color records updating during runtime with auto downloading INI files.
Tracking and Smartcolors almost everywhere (seed colors update with INI during runtime for major changes).
A webwalker with dynamic path creation, multi-floor, and door/gate/etc support (maybe teleports and min combat too).
A color version of GetMyPos.
Multiple scripts/locations for each player within a single run.
Blacklists, not just color counts, but like Nielsie's system, or the same principles applied to DDTMs instead of TPAs if you want.
Reflection color hybrid (see below) for as much as possible.
Some parts reflection only, especially new things, but those skills/locations/features can be disabled while hooks are being updated, and other skills/locations can be used with color until then.

Probably forgetting a few things but whatever.

To be clear, the way to combine color and reflection is like this: try color if available, check with reflection if available (if answers differ, use reflection answer without even moving the mouse to color answer). If both available, keep track of accuracy, Smartcolors, etc, the color improves itself. If there is no color version and hooks are down, switch to a skill/location (color version of getmypos and webwalk) that has good color accuracy and was listed by the user as an available activity, when hooks are back, switch to reflection only activity. You can have some functions that are only color, some that are only reflection, and some that are both. That's perfectly fine, it doesn't have to be all hybrid. The key is if a particular skill/location combo contains any functions that are only reflection, mark it in the Tscriptrecord or whatever 'reflection', and do the same for color. That way, if a player in a skill/location marked 'color' is failing to find something after X tries, or if a player in a skill/location marked 'reflection' is playing when hooks are down, switch to something else. Just make sure that there is a color webwalk (or at least from lumby tele) to at least a few skills/locations that work well while the hooks are down. Allow the user to select multiple skills/locations for each player, and suggest that if their primary is not already one of these, they should pick one of them as a secondary.

Anyways, that's a lot of stuff, AFAIK most of it is being worked on or planned. The end result is a long way off, and that's fine, it's just something to work toward, and even getting part way there will be great and only benefit the community. The point is, don't do something that works backwards from this. Don't make it so that MSI can't do much when hooks are down. By all means encourage people to contribute new functions in only reflection, reflection only functions are great. Other people can then make color versions in whatever time frame, no rush, or never make a color version at all, that's fine too. Just make sure that at least some of the skills/locations can be run without these reflection only functions.

Note this was written between midnight and 1:19 am, so excuse the grammar.

Thank you, Boreas, that smartened me up. You're absolutely right.

No problem. Your original post was already smart on allowing reflection only functions for suggestions, contributions, planned features, requests.

Okay, so does everyone still agree on this?

Using reflection as a backup for colour is 100% pointless in my humble opinion. What does it lead to? You write a 80% reliable 200-line colour walking routine, write a 100% reliable 10-line reflection routine and you prefer the 80% reliable one just because it's colour. Isn't it pointless to use 100% accuracy in only 20% of cases, especially when it saves you hours of coding? The other way around is pretty pointless too because no one feels like writing colour when reflection just works.
Let's be realistic: those "automatic colour accuracy improvement rate tracking things" are just a lot of work and will never be written anyway (prove me wrong). The only downside of reflection is that it requires a more of maintaining (in the form of updating the script to the radically changing include, updating the include) but if maintained is a very stable way of creating scripts.
So please go either reflection or colour. Everything in-between just isn't worth the (double) effort.

From: Markus
Using reflection as a backup for colour is 100% pointless in my humble opinion. What does it lead to? You write a 80% reliable 200-line colour walking routine, write a 100% reliable 10-line reflection routine and you prefer the 80% reliable one just because it's colour. Isn't it pointless to use 100% accuracy in only 20% of cases, especially when it saves you hours of coding? The other way around is pretty pointless too because no one feels like writing colour when reflection just works.
Let's be realistic: those "automatic colour accuracy improvement rate tracking things" are just a lot of work and will never be written anyway (prove me wrong). The only downside of reflection is that it requires a more of maintaining (in the form of updating the script to the radically changing include, updating the include) but if maintained is a very stable way of creating scripts.
So please go either reflection or colour. Everything in-between just isn't worth the (double) effort.

That was pretty much my entire point of this thread. You just said it better.

Idk what to do. This is why we discuss I guess. :p

Lol, auto updating records are not hard to do at all.

That's the very primitive concept of SmartColors.

edit:

type
  TSmartColor = record;
  Color: integer;
  count: integer;

  TSmartColorArray = array of TSmartColor;

FindColorsTolerance(TPA, RoadColor, 10)
Colors := GetColors(TPA);

//count occurances of each color to find out which ones are the most unique

for i:= 0 to high(Colors)
-- Sort uniqueness
-- put it into TSmartColorArray

//TSmartColorArray should then be called to identify the road

FindSCA(which: TSmartColorArray)

~RM

From: Markus
Using reflection as a backup for colour is 100% pointless in my humble opinion. What does it lead to? You write a 80% reliable 200-line colour walking routine, write a 100% reliable 10-line reflection routine and you prefer the 80% reliable one just because it's colour. Isn't it pointless to use 100% accuracy in only 20% of cases, especially when it saves you hours of coding? The other way around is pretty pointless too because no one feels like writing colour when reflection just works.
Let's be realistic: those "automatic colour accuracy improvement rate tracking things" are just a lot of work and will never be written anyway (prove me wrong). The only downside of reflection is that it requires a more of maintaining (in the form of updating the script to the radically changing include, updating the include) but if maintained is a very stable way of creating scripts.
So please go either reflection or colour. Everything in-between just isn't worth the (double) effort.

Using a 100% reflection 20% of the time as a failover is pointless, yes. I am suggesting using reflection 98% of the time, but during that time also check the color so that we are not left with nothing during the 2%. Even if the color is only 40% accurate and didn't take 200 lines, and didn't have the automatic improving thing, at least there's something. Whether it's double effort is hard to say, if some people are going to write color methods no matter what, and some people are going to make reflection methods no matter what, it's just putting them together. In any case, the bot/script that you can run all the time seems like something worth shooting for.

From: Sir R. Magician
Lol, auto updating records are not hard to do at all.

That's the very primitive concept of SmartColors.

edit:

type
  TSmartColor = record;
  Color: integer;
  count: integer;

  TSmartColorArray = array of TSmartColor;

FindColorsTolerance(TPA, RoadColor, 10)
Colors := GetColors(TPA);

//count occurances of each color to find out which ones are the most unique

for i:= 0 to high(Colors)
-- Sort uniqueness
-- put it into TSmartColorArray

//TSmartColorArray should then be called to identify the road

FindSCA(which: TSmartColorArray)

~RM

No, not hard, but sometimes a pain in the ass, and could prove to not be worth it if reflection is always used anyway. But if we can find a way for MSI to continue running through updates and until the hooks are updated, I think it would all be worth it.

Also on reflection working 100%……. color doesn't need to be 100%. It's not like objects are only one pixel large.

~RM

Oh god.

I was fearing this post would come someday. I would quit MSI scripting if it's turned into 100% reflection. Actually… >40% Reflection and I'll quit…

From: Sir R. Magician
Also on reflection working 100%……. color doesn't need to be 100%. It's not like objects are only one pixel large.

~RM

I don't understand your point here.. Actually I don't even understand what you mean. I was talking about reflection working 100% of the time.

@Zyt3x: I find that to be very immature, no offense.

From: Coh3n
@Zyt3x: I find that to be very immature, no offense.

How come?
I just like color, is all.

From: Zyt3x
How come?
I just like color, is all.

Because, you would quit if there was a big change to MSI you don't like.

From: Coh3n
Because, you would quit if there was a big change to MSI you don't like.

If by big, you mean (gigantic) re-make, then yes.
And if there was a big change in SRL that I didn't like (I.E, SRL moving to another game that I don't like) then I'd quit SRL too…

Just reminding everyone that reflection broke for about 8 months..

Do not replace color with reflection, but add reflection too if you like.
One con in reflection is that Jagex is damn cunning with IDs.
In the Varrock East mine the other rocks have ID 1231 (example) while they are mineable, but the others next to those rocks have the same ID when they have already been mined.

That'd make us have to add a record for every object – not just every object type.
That'd mean

TMSIObject = record
  Tile: TTile;
  ID: Integer;
  Action: string;
  etc. etc.
end;

with MSI_Objects[OBJ_ROCK_VEM_1] do ...
with MSI_Objects[OBJ_ROCK_VEM_2] do ...
with MSI_Objects[OBJ_ROCK_VEM_3] do ...
with MSI_Objects[OBJ_ROCK_VEM_4] do ...
with MSI_Objects[OBJ_TREE_VE_1] do ...
with MSI_Objects[OBJ_TREE_VE_2] do ...
with MSI_Objects[OBJ_TREE_VE_3] do ...
with MSI_Objects[OBJ_TREE_VE_4] do ...

It is very possible that there will be many more traps like these soon enough.

I suggest Reflection actually becomes stable before you go that route. I'm fairly certain all memory errors / "code:8" errors are directly related to reflection. That being said, 100% is surely possible, it is how we've done it for years. Runescape only got easier; not harder. (Except for some random events, mordaut basically)

From: Zyt3x
If by big, you mean (gigantic) re-make, then yes.
And if there was a big change in SRL that I didn't like (I.E, SRL moving to another game that I don't like) then I'd quit SRL too…

That's not the same thing at all. You could maybe compare it to MSI moving to python, but not a new game entirely. And it just shows that you aren't as dedicated to MSI as one may have thought.

From: Nava2
Just reminding everyone that reflection broke for about 8 months..

Yeah, but AFAIK it was because there wasn't anyone around capable of updating it.

From: marpis
Do not replace color with reflection, but add reflection too if you like.
One con in reflection is that Jagex is damn cunning with IDs.
In the Varrock East mine the other rocks have ID 1231 (example) while they are mineable, but the others next to those rocks have the same ID when they have already been mined.

That'd make us have to add a record for every object – not just every object type.
That'd mean

TMSIObject = record
  Tile: TTile;
  ID: Integer;
  Action: string;
  etc. etc.
end;

with MSI_Objects[OBJ_ROCK_VEM_1] do ...
with MSI_Objects[OBJ_ROCK_VEM_2] do ...
with MSI_Objects[OBJ_ROCK_VEM_3] do ...
with MSI_Objects[OBJ_ROCK_VEM_4] do ...
with MSI_Objects[OBJ_TREE_VE_1] do ...
with MSI_Objects[OBJ_TREE_VE_2] do ...
with MSI_Objects[OBJ_TREE_VE_3] do ...
with MSI_Objects[OBJ_TREE_VE_4] do ...

It is very possible that there will be many more traps like these soon enough.

That's just a huge pain in the ass.

I'd also like to remind people that I was just stating my thoughts, I don't necessarily like the idea. I do like, however, Boreas thoughts on the topic. For those who didn't see it:

From: Boreas
I'm basically a retired cranky old man, but I'll throw in my 2 million cents anyway and you can take what you want. What goals you have for MSI is completely up to you guys, but what I would like to see in MSI and all scripts, SRL, and Simba, is a creating a thriving community. More specifically, undetectable of course, army/break support, AI (not technically AI, but you know what I mean), a variety of scripts, ease of use, and progress reports measured in days and weeks (or just being able to auto 24x7, and only stopping when the user chooses to take breaks for antiban). It seems to me that working towards a goal of a 3 month progress report can't be a bad thing, whether we reach that point or not.

As for color vs reflection, in a broad sense, they are both the same thing. Every you need to click on in runescape has two attributes (not counting OpenGL); color and ID. Both of these are controlled by jagex, not us, and can change at their whim. Color and reflection are the same thing because they both use one of these attributes, and break when that attribute changes. Color has autocolors and algorithms, reflection has updaters. Obviously in a more narrow sense, there are differences. You can write reflection code faster than color. Reflection breaks more often than color, but can be fixed faster than color most of the time.

Getting tired, so here's a list of things I'd like to see, you can probably guess the reasoning

Scripts that can continue through an update, so something to reload the client at the appropriate time.
Hooks and color records updating during runtime with auto downloading INI files.
Tracking and Smartcolors almost everywhere (seed colors update with INI during runtime for major changes).
A webwalker with dynamic path creation, multi-floor, and door/gate/etc support (maybe teleports and min combat too).
A color version of GetMyPos.
Multiple scripts/locations for each player within a single run.
Blacklists, not just color counts, but like Nielsie's system, or the same principles applied to DDTMs instead of TPAs if you want.
Reflection color hybrid (see below) for as much as possible.
Some parts reflection only, especially new things, but those skills/locations/features can be disabled while hooks are being updated, and other skills/locations can be used with color until then.

Probably forgetting a few things but whatever.

To be clear, the way to combine color and reflection is like this: try color if available, check with reflection if available (if answers differ, use reflection answer without even moving the mouse to color answer). If both available, keep track of accuracy, Smartcolors, etc, the color improves itself. If there is no color version and hooks are down, switch to a skill/location (color version of getmypos and webwalk) that has good color accuracy and was listed by the user as an available activity, when hooks are back, switch to reflection only activity. You can have some functions that are only color, some that are only reflection, and some that are both. That's perfectly fine, it doesn't have to be all hybrid. The key is if a particular skill/location combo contains any functions that are only reflection, mark it in the Tscriptrecord or whatever 'reflection', and do the same for color. That way, if a player in a skill/location marked 'color' is failing to find something after X tries, or if a player in a skill/location marked 'reflection' is playing when hooks are down, switch to something else. Just make sure that there is a color webwalk (or at least from lumby tele) to at least a few skills/locations that work well while the hooks are down. Allow the user to select multiple skills/locations for each player, and suggest that if their primary is not already one of these, they should pick one of them as a secondary.

Anyways, that's a lot of stuff, AFAIK most of it is being worked on or planned. The end result is a long way off, and that's fine, it's just something to work toward, and even getting part way there will be great and only benefit the community. The point is, don't do something that works backwards from this. Don't make it so that MSI can't do much when hooks are down. By all means encourage people to contribute new functions in only reflection, reflection only functions are great. Other people can then make color versions in whatever time frame, no rush, or never make a color version at all, that's fine too. Just make sure that at least some of the skills/locations can be run without these reflection only functions.

Note this was written between midnight and 1:19 am, so excuse the grammar.

From: Coh3n
That's not the same thing at all. You could maybe compare it to MSI moving to python, but not a new game entirely. And it just shows that you aren't as dedicated to MSI as one may have thought.

I have no idea how you got that from me not wanting MSI to go 100% reflection… <_<

Reflection is just not as reliable as you think, and it breaks every update. There's just too many cons for me to like it.

From: Nava2
Just reminding everyone that reflection broke for about 8 months..

That's my main point in this. I really don't feel this discussion can go anywhere really until post free trade/wildy update, as this could very well happen again for all we know.

From: Zyt3x
I have no idea how you got that from me not wanting MSI to go 100% reflection… <_<

Reflection is just not as reliable as you think, and it breaks every update. There's just too many cons for me to like it.

Just the fact that you would quit if that's what it comes down to. Trust me, I would pick color over Reflection any day, but like I stated in my first post in this thread; it's selfish to hold back MSI simply because of your personal preference.

I also said that I would never let color be extinct in MSI, and I will hold to that.

Wizzup brings up a good point as well. Many Reflection random solvers return false positives due to poor methods. I don't want MSI relying on such poor methods as that in it self decreases the reliability and 'value' of what we have accomplished here already.

Not to mention MSI was set out to be a 100% color AIO script, which we've already gone against by using Reflection for walking (which I'm not opposed to what so ever), and we will be going against it even more by going more hybrid. We do need to keep in mind our user base however. A lot of people use MSI, and honestly, it's very rewarding seeing 30 hour reports being posted. Now, if we take an approach like Boreas suggested we could have week+ long reports possibly even longer.

MSI is technically a community project, though very little of the community actually contributes which is all the more reason we need our SL's to be actively developing and supportive of whatever decision is made.

I could go on about this for hours, but again, there really is no point in really getting into it until we see what happens with the upcoming update as no one knows what Jagex will be changing.

From: Coh3n

Sadly, color botting may slowly die. :(

Not looking for an argument, but no it won't. It is the oldest, most solid, most challenging and above all most beautiful technique.

I find no pleasure in reading out the gamecode.

I tried it, but didn't like it. Too unstable. Reflection/injection/bytecode used to break twice a week. Offline for at least 20 hours because maintained by few vague people. Too difficult for me to understand by myself. Usually leaves the scene within a year, because of lawsuits by Jagex.

There is definately a negative side to reflection. I wouldn't put all my money on it.

From: WT-Fakawi
Not looking for an argument, but no it won't. It is the oldest, most solid, most challenging and above all most beautiful technique.

How many new scripters chose to learn color over reflection?

New scripters learning reflection and color not dieing don't have to be mutually exclusive.

From: Coh3n
How many new scripters chose to learn color over reflection?

But should we change our ways just to accommodate a new lazier generation?

From: Boreas
New scripters learning reflection and color not dieing don't have to be mutually exclusive.

From: NCDS
But should we change our ways just to accommodate a new lazier generation?

So right now there's very few people that still script in color. Those people aren't going to be around forever. If reflection doesn't break, eventually there'll be next to no color scripters, and therefore no one to maintain the color side of MSI.

From: Coh3n
So right now there's very few people that still script in color. Those people aren't going to be around forever. If reflection doesn't break, eventually there'll be next to no color scripters, and therefore no one to maintain the color side of MSI.

Just a shitty situation I guess. Lets just see what happens with this update and go from there.

Lol. MSI will give people a reason to script in colour.

Also, with auto-updating records it will no longer be a question of colour or reflection.

It'll be a question of logics.

All who have spoken so far I believe have a preference for colour. It doesn't mean we are unable to learn and use reflection - quite the opposite in fact.

just like Naike is currently head of reflection and he is perfectly capable of colour. Just like pyroryan and Ben. Just like Wizzup. Just like EC.

It's not a question of colour or reflection. We just actually have a great base of people.

From: Sir R. Magician
Lol. MSI will give people a reason to script in colour.

Also, with auto-updating records it will no longer be a question of colour or reflection.

It'll be a question of logics.

All who have spoken so far I believe have a preference for colour. It doesn't mean we are unable to learn and use reflection - quite the opposite in fact.

just like Naike is currently head of reflection and he is perfectly capable of colour. Just like pyroryan and Ben. Just like Wizzup. Just like EC.

It's not a question of colour or reflection. We just actually have a great base of people.

Yeah right now. What I'm trying to say is it won't be like that forever.

Hey I just wanted to post what I told Coh3n yesterday;

Axel Selmer-Anderssen (02:10):
After thinking about what you and NCDS said in the thread I see you guys are correct…
I still don't want MSI to go 100% reflection, but if it does, I'll handle it and keep on developing
Cohen Adair (02:11):
No one WANTS to see that happen
I doubt it will, I just threw those things out there for people to think about
I didn't mean for it to sounds like that's what I wanted
Axel Selmer-Anderssen (02:12):
Right

RM, you talk about these auto-updating records, and you've thrown out mini snippits of code and such, but we still don't have them. I have no idea how to write them, which is why I would say they would be hard to work into MSI. You mentioned that they aren't hard, but we haven't gotten passed the talking stage about them yet. If they are that great and that unhard, couldn't they be high up on your priority list? I know that you don't have much time but I'd love to see them here, especially if we can lower the amount of reflection code that is the base of MSI.

From: 3Garrett3
RM, you talk about these auto-updating records, and you've thrown out mini snippits of code and such, but we still don't have them. I have no idea how to write them, which is why I would say they would be hard to work into MSI. You mentioned that they aren't hard, but we haven't gotten passed the talking stage about them yet. If they are that great and that unhard, couldn't they be high up on your priority list? I know that you don't have much time but I'd love to see them here, especially if we can lower the amount of reflection code that is the base of MSI.

I think the debugging system is much more important for a sucesfull SRL 5, and quite honestly MSI's debugging will probably end up in SRL and reflection has already said they'd want to try implementing it if it goes into SRL.

My priority right now is hibridity :)

I'm sure you guys can figure it out, and mini scripts are the building base.

I've left the names of some functions that are needed and ideas in the code.

I don't raelly have the time to do it all, but just like it happened for MSI we're just laying foundations here.


A very very very long tiem ago I told you that MSI was a development ground. Many things that were discussed for the original SRL 5 ended up in MSI - and guess what - they were succesfull.

The current debug system developed from Nava's debug system and the talking in dev forums.

From: Sir R. Magician
A very very very long tiem ago I told you that MSI was a development ground. Many things that were discussed for the original SRL 5 ended up in MSI - and guess what - they were succesfull.

The current debug system developed from Nava's debug system and the talking in dev forums.

LoL I had no idea you used my debug system :)

From: 3Garrett3
RM, you talk about these auto-updating records, and you've thrown out mini snippits of code and such, but we still don't have them. I have no idea how to write them, which is why I would say they would be hard to work into MSI. You mentioned that they aren't hard, but we haven't gotten passed the talking stage about them yet. If they are that great and that unhard, couldn't they be high up on your priority list? I know that you don't have much time but I'd love to see them here, especially if we can lower the amount of reflection code that is the base of MSI.

When I finish with the walking, at least the color point records will be automatically updated (take a look at my generator if you haven't already). I still need some input here, though before I can finish.

In the meantime I can just have it use either reflection/color, and figure out hybrid later (that's if we can't figure out a solution soon).

E: Here's an idea of how to save/load the records. And to update them you just reset the variables during runtime, then call the save method when the script is done so it saves all the changes.

// Loads all the walk points from the WalkPoints.txt file
procedure LoadAllWalkPoints();
var
  i: Integer;
begin
  if (not FileExists(PATH_RECORD_WALKPOINT)) then
    Exit;

  SetLength(gbl_WalkPoints, StrToInt(ReadINI('POINT_COUNT', 'PointCount', PATH_RECORD_WALKPOINT)));

  for i := 0 to High(gbl_WalkPoints) do
    with gbl_WalkPoints[i] do
    begin
      Name := ReadINI(IntToStr(i), 'Name', PATH_RECORD_WALKPOINT);
      Color := StrToInt(ReadINI(IntToStr(i), 'Color', PATH_RECORD_WALKPOINT));
      Tolerance := StrToInt(ReadINI(IntToStr(i), 'Tolerance', PATH_RECORD_WALKPOINT));
      SortFrom.x := StrToInt(ReadINI(IntToStr(i), 'SortFrom.x', PATH_RECORD_WALKPOINT));
      SortFrom.y := StrToInt(ReadINI(IntToStr(i), 'SortFrom.y', PATH_RECORD_WALKPOINT));
      RWalkParams := StrToIntArr(ReadINI(IntToStr(i), 'RWalkParams', PATH_RECORD_WALKPOINT));
    end;
end;

// Saves all the points to a file
procedure SaveAllWalkPoints();
var
  i: Integer;
begin
  ClearFile(PATH_RECORD_WALKPOINT);

  WriteINI('POINT_COUNT', 'PointCount', IntToStr(Length(gbl_WalkPoints)), PATH_RECORD_WALKPOINT);

  for i := 0 to High(gbl_WalkPoints) do
    with gbl_WalkPoints[i] do
    begin
      WriteINI(IntToStr(i), 'Name', Name, PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'Color', IntToStr(Color), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'Tolerance', IntToStr(Tolerance), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'SortFrom.x', IntToStr(SortFrom.x), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'SortFrom.y', IntToStr(SortFrom.y), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'RWalkParams', IntArrToStr(RWalkParams), PATH_RECORD_WALKPOINT);
    end;
end;                                     

Coh3n, does ur ColorWalking tool make it aim for the tile you are on?

eg is the color walk always supposed to aim for reflection tile x.y ? (i think the answer is yes, just checking)

@Nava:
I had looked at your output and found it really confusing, then I sort of got it and still found it messy and by the time I got my debugging working I realized I had pretty much just simplified yours into something that looked better than >> and << :p

the way yours indented didnt quite make sense in my mind, although I found it genious that you were showing in such an obvious way where each function started and ended :)

~RM

From: Coh3n
When I finish with the walking, at least the color point records will be automatically updated (take a look at my generator if you haven't already). I still need some input here, though before I can finish.

In the meantime I can just have it use either reflection/color, and figure out hybrid later (that's if we can't figure out a solution soon).

E: Here's an idea of how to save/load the records. And to update them you just reset the variables during runtime, then call the save method when the script is done so it saves all the changes.

// Loads all the walk points from the WalkPoints.txt file
procedure LoadAllWalkPoints();
var
  i: Integer;
begin
  if (not FileExists(PATH_RECORD_WALKPOINT)) then
    Exit;

  SetLength(gbl_WalkPoints, StrToInt(ReadINI('POINT_COUNT', 'PointCount', PATH_RECORD_WALKPOINT)));

  for i := 0 to High(gbl_WalkPoints) do
    with gbl_WalkPoints[i] do
    begin
      Name := ReadINI(IntToStr(i), 'Name', PATH_RECORD_WALKPOINT);
      Color := StrToInt(ReadINI(IntToStr(i), 'Color', PATH_RECORD_WALKPOINT));
      Tolerance := StrToInt(ReadINI(IntToStr(i), 'Tolerance', PATH_RECORD_WALKPOINT));
      SortFrom.x := StrToInt(ReadINI(IntToStr(i), 'SortFrom.x', PATH_RECORD_WALKPOINT));
      SortFrom.y := StrToInt(ReadINI(IntToStr(i), 'SortFrom.y', PATH_RECORD_WALKPOINT));
      RWalkParams := StrToIntArr(ReadINI(IntToStr(i), 'RWalkParams', PATH_RECORD_WALKPOINT));
    end;
end;

// Saves all the points to a file
procedure SaveAllWalkPoints();
var
  i: Integer;
begin
  ClearFile(PATH_RECORD_WALKPOINT);

  WriteINI('POINT_COUNT', 'PointCount', IntToStr(Length(gbl_WalkPoints)), PATH_RECORD_WALKPOINT);

  for i := 0 to High(gbl_WalkPoints) do
    with gbl_WalkPoints[i] do
    begin
      WriteINI(IntToStr(i), 'Name', Name, PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'Color', IntToStr(Color), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'Tolerance', IntToStr(Tolerance), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'SortFrom.x', IntToStr(SortFrom.x), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'SortFrom.y', IntToStr(SortFrom.y), PATH_RECORD_WALKPOINT);
      WriteINI(IntToStr(i), 'RWalkParams', IntArrToStr(RWalkParams), PATH_RECORD_WALKPOINT);
    end;
end;                                     

You know that would be SUPER slow right?

You would be better off loading everything into a JSON type nature, then parsing it all at once. Otherwise, you are going to do ReadINI for each member and waste time having Simba search continuously for each attribute of the record.

So reading all the points as you come across them into one piece vs. reading them all individually.

You could also just store all the pieces into one INI attribute using Implode/fmt and Explode.

Better keep them in separate attributes, good call on the ReadInis :)

if you implode the ini it'll become less flexible, which is bad :p

I'm also starting to think we might want to use xml in the future rather than inis………but I need to learn more about that before I start making any suggetions

From: Sir R. Magician
Coh3n, does ur ColorWalking tool make it aim for the tile you are on?

eg is the color walk always supposed to aim for reflection tile x.y ? (i think the answer is yes, just checking)

Yeah, it gets all the information from the tile you want to walk to (i.e. if you're in VE Bank, you want to walk to the tile near the gate. It will get the color/radial and the attributes are set).

It's actually stupidly simple. The most complicated part is using cosine law to get the radial from the player to the tile, and even that's for the failsafe function.

From: Nava2
You know that would be SUPER slow right?

You would be better off loading everything into a JSON type nature, then parsing it all at once. Otherwise, you are going to do ReadINI for each member and waste time having Simba search continuously for each attribute of the record.

So reading all the points as you come across them into one piece vs. reading them all individually.

You could also just store all the pieces into one INI attribute using Implode/fmt and Explode.

You and I have very different perception of what is slow. :rolleyes: Also, I have no idea what JSON type nature is.

RM made a good point though. The way I have it makes it so records can easily be added manually if needed. It's also very easy to read (not sure if what you're saying would be, but just saying).

I think nava's main point was to only read the ini once, or at least only read it once per object

From: Sir R. Magician
I think nava's main point was to only read the ini once, or at least only read it once per object

Yeah, but I don't know how to do that while still keeping it somewhat organized. I'm actually not sure how to do that at all.

Yeh nor am I lol. But I wasn't sure you had got the point :p My bad.

I guess that by using explosion it would be easier to pull info. I guess we should go hybrid.

Pull out of a string, and when you want to update data just push it into the structured ini.

And we should probably do that at the end of the run..

UpdateRecords();
StructureToString();

What do you think?

I'd like to know exactly how much time we would be saving in the long run? Like whats the time difference if we were loading 10 records opposed to 100. I mean, if it's < 1s I wouldn't say it's worth the trouble. =\

From: Coh3n
I'd like to know exactly how much time we would be saving in the long run? Like whats the time difference if we were loading 10 records opposed to 100. I mean, if it's < 1s I wouldn't say it's worth the trouble. =\

Oh trust it, push and pull really is worth the trouble.

For speed and for organizational purposes. Otherwise it would just be bad database handling

~RM

Okay, I'll have to look into it before I add the system. I'd still like the file to be in the same format, but I should be able to have it read the file only once.

E: Yeah, I have no idea how I would do this. Nava, any suggestions? :p

Don't use the ini structure.

From: Nava2
Don't use the ini structure.

I like the INI structure though. It's organized and easy to edit. That's one of the main reasons I like using them.

From: Coh3n
I like the INI structure though. It's organized and easy to edit. That's one of the main reasons I like using them.

http://www.json.org/

Parsers are *readily* available.

From: Nava2
http://www.json.org/

Parsers are *readily* available.

+ http://en.wikipedia.org/wiki/JSON

From: Nava2
http://www.json.org/

Parsers are *readily* available.

Looks neat. Obviously I don't know how I would make it worth with Simba, but it's something to look in to. For now, I'm going to leave it the way it is, simply so I can get the walking system released sooner and because I have a lot of other things that need to be done as well, but once we start loading all our records from files, I'll be something to look in to.

http://code.google.com/p/superobject/

Its quite pythony! :)

http://www.progdigy.com/?page_id=6

dude….

text := ReadIni(pull, recordString);
text[] := explode(':', text);

writeln(text[x_NAME]);
writeln(text[y_LEVEL]);
writeln(text[z_REALITY);

UpdateRecords(TEXT_ARRAY, text[]);
end;

begin
  for i:= 0 to high(Text[]) do
    s := s + Text[i];

  WriteToIni(RecordString, s);
end;

~RM
end;

From: Sir R. Magician
dude….

text := ReadIni(pull, recordString);
text[] := explode(':', text);

writeln(text[x_NAME]);
writeln(text[y_LEVEL]);
writeln(text[z_REALITY);

UpdateRecords(TEXT_ARRAY, text[]);
end;

begin
  for i:= 0 to high(Text[]) do
    s := s + Text[i];

  WriteToIni(RecordString, s);
end;

~RM
end;

That would mean changing the structure of the file would it not? I think that could work, but it would read the file for every record, instead of reading the file just once.

Bumping this. I really don't know what to do about this. I hate to say it, but with all the graphics changes, it makes color in some areas impossible to compete with Reflection. Just posting to open discussion again.

From: Coh3n
Bumping this. I really don't know what to do about this. I hate to say it, but with all the graphics changes, it makes color in some areas impossible to compete with Reflection. Just posting to open discussion again.

Hard to say as we haven't been able to try with the new TLoc stuff implemented. I got a god bit done last night and will do the same tonight.


I think we have to see what we can do with the different angles and stuff first. I won't resort to reflection unless it is absolutely necessary to complete the task.

I'd really like to see colour remain, willing to script too, in a … month from now or so.

With or without Wizzup? on the team, I'm confident that reflection isn't needed (but with Wiz, it's a lot easier with color :))

From: NCDS
Hard to say as we haven't been able to try with the new TLoc stuff implemented. I got a god bit done last night and will do the same tonight.


I think we have to see what we can do with the different angles and stuff first. I won't resort to reflection unless it is absolutely necessary to complete the task.

We'll see how the TLoc stuff goes. I'm pretty confident it will make things better.

From: Wizzup?
I'd really like to see colour remain, willing to script too, in a … month from now or so.

I'd love to see the same.

It is, however, quite annoying when we spend so much time doing things in color when it can be done (in a lot of cases better) in one line of reflection.

From: Coh3n
It is, however, quite annoying when we spend so much time doing things in color when it can be done (in a lot of cases better) in one line of reflection.

Yeah… This is the main reason why people use reflection over color these days, it makes our life easier in many ways…

From: Zyt3x
Yeah… This is the main reason why people use reflection over color these days, it makes our life easier in many ways…

And that's what's upsetting because it's hard to find developers when everyone wants to take the easy way out.

However, since I made the "MSI Needs Devs" thread, a few people have contributed a little. Troll, for example, is doing really well adding Runecrafting. :)