SRL Archive - News and General

It's time someone organised the Reflection effort and I'll have a go at it. Thread is open for discussion, but don't mix RRL in it. (I will only mention it in this post to criticize the stance it takes)

What I observe:

• People want to use reflection, for walking and for object finding.
• The include is not stable enough to do proper object finding. I don't think the walking has problems.
• No one is responsible for maintaining the include as it is.
• There's a complete lack of leadership and direction.

Looking at these facts, I propose the following:

• People who were previously responsible / maintainers explain what went wrong and how it went wrong. For example, why does no one really work on it now?
• People who care for SRL Reflection step up and a small team is formed. We want people who have time, not just knowledge. Knowledge can be acquired with time, time can't be acquired with knowledge.

Having assembled a small team, we can start with the one of the following plans:

• Debug the old code, using http://villavu.com/forum/showthread.php?t=62231 (I really can't believe no one did this, it's probably quite trivial to fix the leaks with this tool)
• Remove / comment all non working code. Strip the include. Keep only trivial things like Walking and small helper functions: reflection_GetUpText, etc. Once this is stable, it's possible to re-add features like object finding. Whilst adding this, use the memory debugging tool. The idea is simple. Start with a base that works, so script can build upon this stable base. Features that are missing are not an issue, the scripter will simply have to do without object finding.

Personally, I think Reflection should be a simple and stable add-on that scripters can use. Object finding and random solving is not part of a simple add on. The entire random solving is quite pointless IMO and simply created to ``show'' that reflection is superior to colour.

It is pointless to to replace SRL's complete functionality (something RRL is doing) and I will not back this. Reflection has over time been used more and more, which is fine. However, if you intend to write a SRL like include completely with reflection then I think there's no place for that. We're essentially still a colour bot. What distinguishes us from other communities is that we're not all into this client hacking approach and instead prefer our more complicated colour techniques. It's a hobby, not a business.

So, we'll have to start off with the following questions:

• Who's working on it at the moment?
• Who's in charge, at the moment?
• What code does not work / possibly doesn't work.

And … who would like to work on SRL-Reflection? I personally don't really qualify due to lack of time. I'll probably have some time to at least develop tools like the memory debugger and give some directions when and if required.

I personally enjoy the current setup. Except for the memory leaks and the anti-random solver occasionally breaking due to RS updates, it's "perfect" the way it is. I like all the "bloat" it has; makes stuff easier and simpler with less work needed for the scripter.

Just want to disagree with one small thing - your stance on random solvers being part of the include.
It's well known that reflection has the capacity to solve randoms better and more reliably than color. Why would we pass up this functionality just because 'we are a colour bot?' If we have the capacity to use reflection to solve randoms I think we should use it. If scripters don't want to use the ref. randoms they don't have to. But I think the choice should be there.

From: Iamadam
Just want to disagree with one small thing - your stance on random solvers being part of the include.
It's well known that reflection has the capacity to solve randoms better and more reliably than color. Why would we pass up this functionality just because 'we are a colour bot?' If we have the capacity to use reflection to solve randoms I think we should use it. If scripters don't want to use the ref. randoms they don't have to. But I think the choice should be there.

Well, a few things are happening:

FUD about srl-reflection is spread. The people who spread it are partially right (it does leak memory which is ugly), but the include really isn't that bad.

I can't stand this FUD and I think it doesn't do justice to all the time people have spent on the srl-reflection include.

I'm not suggesting to completely wipe the random solving and everything for ever - but I think that if we find it required to completely rewrite the include then we'll have to drop a lot at first. Plus, I do think it's advantageous to let SRL do the random solving initially. Why? Because the entire community is built around SRL. If Reflection scripts let SRL do the solving then colour only scripts will benefit by this as well. I mean no harm to SRL-Reflection, I just think it should be a bit more SRL-oriented. That's why I write addon, not an entire include on it's own. The way it was currently written is to show how Reflection is better than colour. Obviously it's true that it is possible to acquire 100% accuracy with Reflection, it's not something SRL as a community really stands for. To me, anyway. To my knowledge the SRL random solvers work quite well.

Reflection is really useful for it's accurate walking but we've got SPS which is colour and has almost the same accuracy. SPS's flaw is the filesize… :<

From: Floor66
Reflection is really useful for it's accurate walking but we've got SPS which is colour and has almost the same accuracy. SPS's flaw is the filesize… :<

We can surely solve that, but I believe that should be in another thread. :)

I was considering doing something similar recently. As it stands now, the state of the include is a mess and the memory leaking is an obvious issue. I think it'd be useful to strip the include of everything, excluding the hooks file, and remake the include providing the basic functionality required for a reflection script to work well. Off the top of my head, this includes: object, npc, item, and player finding, interface finding and interaction, menu interaction, and walking functionality. From there, if desired, we could expand the include to include whatever else was important to scripters, like random finding or functions for other specific things (like banking, interacting with the inventory, etc.). The point of this restructure, however, would be the get the core functionality working properly before trying to complicate the include with more code.

As for the questions you asked in your post:

• Most recently, it looks like mainly pyroryan and mormonman have been the ones working on it.
• I'm not sure if anyone is officially considered the leader, but I would guess that person would be pyroryan.
• Someone who uses the include more would probably have to give you this answer. It's clear that there are memory leaks in the include, though.

Sorta offtopic, but, Object memleaks appear to be fixed. Though there are probably more, any others that you know off the top of your head? Objects were the main leak for me.

Separate random finding from the reflection include. Just stick it in with the SRL random finding. i.e. Use something like "if Reflection then". Reflection include should only be basic functionality as Method said.

Use the {$IFDEF UseReflection}?

From: Floor66
Use the {$IFDEF UseReflection}?

Thanks :) that's what I meant.

I will participate in this even though apparently I was the one who created the memory leak in objects. I do not, however, agree with you on randoms, as that is one of the main reason's many people include reflection. They want randoms to be solved and with color that just isn't happening.

I could try and help, I spend a lot of time on here doing nothing that important so why not?

From: mormonman
I will participate in this even though apparently I was the one who created the memory leak in objects. I do not, however, agree with you on randoms, as that is one of the main reason's many people include reflection. They want randoms to be solved and with color that just isn't happening.

Not particularly disagreeing with what you said, but apart from Mordaut I'd say SRL has the randoms pretty stable?

From: Wizzup?
Not particularly disagreeing with what you said, but apart from Mordaut I'd say SRL has the randoms pretty stable?

Last I checked, detection was the biggest issue.

I've always been a reflection skeptic, and have always felt that color could do anything just as well as reflection. Walking and randoms can be done with color. However, there is one thing that reflection does that color simply cannot do efficiently, and that is to find stacked ground items.

I hope that reflection will continue to include item finding, because it really is the "killer app" that it alone offers at this point.

I think the include needs a complete rewrite, much like Method stated. I've merely been around as a guide and small fixes. I wish I had more time to sit down and code..

My life is too busy at the moment. :(

Just throwing this out there, I'm available to do work…

"It's a hobby, not a business." I would just like to say I love you Wizzup?.

I'm not available to do work because I work IRL. Maybe I'll have some time soon.

From: TomTuff
Just throwing this out there, I'm available to do work…

The beauty of git, you can submit patches. :)

Just fork the repository.

I'm going to try and commit some more time to managing the commits etc.

From: TomTuff
Just throwing this out there, I'm available to do work…

What Nava said. It's actually so easy once you get the hang of it. That's exactly how IPwnz has been contributing to MSI.

I think I'm going to clear up some clutter in Interfaces. That is the messiest one.

From: mormonman
I will participate in this even though apparently I was the one who created the memory leak in objects. I do not, however, agree with you on randoms, as that is one of the main reason's many people include reflection. They want randoms to be solved and with color that just isn't happening.

Reflection randoms are hardly, if at all, better than color solvers at this point.

I'll give a couple examples just to back up this statement; not detecting solved random, not detecting in random, still have seen it fail multiple randoms.

Color solvers are not perfect, but I don't think the Reflection ones are any better.

From: Coh3n
What Nava said. It's actually so easy once you get the hang of it. That's exactly how IPwnz has been contributing to MSI.

Yep, just learn how to do branch merging to update your forked repository with the latest stuff in the main, then do a pull request once you've done commits in your own repo that you want in the main. :) After the initial install of git (which can be a bit of a hassle), then managing repositories is so incredibly easy you won't believe it.

From: NCDS
Reflection randoms are hardly, if at all, better than color solvers at this point.

I'll give a couple examples just to back up this statement; not detecting solved random, not detecting in random, still have seen it fail multiple randoms.

Color solvers are not perfect, but I don't think the Reflection ones are any better.

+1, this has been my experience as well.

There is no excuse for reflection random solving to fail. At all.

From: Iamadam
There is no excuse for reflection random solving to fail. At all.

True to an extent.

Laughed at how this almost became a thread for GIT supporters :p

I'm not sure what needs fixing exactly, someone point me a direction and I'll see what I can do. Objects?

From: TomTuff
True to an extent.

Laughed at how this almost became a thread for GIT supporters :p

I'm not sure what needs fixing exactly, someone point me a direction and I'll see what I can do. Objects?

Clean and reorganize.

From: Iamadam
There is no excuse for reflection random solving to fail. At all.

You can go and solve Prison 100% then. I will be waiting. Lol. Good luck with the amount of time Jagex gives you, and how the NPC IDs change every time.

From: Nava2
Clean and reorganize.

I suggest you organise what has to be done. Make a list, say how you'd like to see it. Then you can ask people to do it. If people have little experience with reflection don't make them ``clean up'', as their definition of cleaning will be different from yours.

I recall some of the ref random solvers were reused code and weren't exactly fail-safe like their color counterparts… While there are a couple that are really reliable.

From: Harry
You can go and solve Prison 100% then. I will be waiting. Lol. Good luck with the amount of time Jagex gives you, and how the NPC IDs change every time.

It's possible.

From: mormonman
It's possible.

I understand, I was just saying his comment of "no excuse" is silly, when he isn't bothering to attempt it.. ;)

Is anything materialising?

From: Wizzup?
Is anything materialising?

I was thinking, some one said that the main problem of color randoms is the detection, so why not do a hybrid type of thing in SRL's color random solvers.

Something like

If NPCHooksUpdated then
  DetectRandomsUsingRefNPCS
else
  DetectColor;//this is what currently gets called

It cant hurt and will definitely only do good for the random solving.

Probably better to make that into a DEFINE/IFDEF, Camaro', because SRL-Reflection is separate from SRL. Else you'd have to include reflection in any script that you use SRL in. But I like the idea.

[QUOTE=Camaro';791618]I was thinking, some one said that the main problem of color randoms is the detection, so why not do a hybrid type of thing in SRL's color random solvers.

Something like

If NPCHooksUpdated then
  DetectRandomsUsingRefNPCS
else
  DetectColor;//this is what currently gets called

It cant hurt and will definitely only do good for the random solving.

That's something that the Reflection include can do, but I don't see a point of adding that to SRL.

When I said materialising, I meant: Is there a concrete plan now? Or are people still just randomly doing bits when they have time?

No plans yet, but I think they should be made before we do anything. Clear goals should be set, so that we don't make the mess worse.

Reflection has a lot of useless functions, e.g shit like r_ChooseOption and similar stuff just makes it messy…

From: n3ss3s
Reflection has a lot of useless functions, e.g shit like r_ChooseOption and similar stuff just makes it messy…

Actually I like to use the reflection variety of ChooseOption and IsUptext for my reflection backups - my logic is that if color failed, why re-use color again in case that's what's failing?

When hooks are up to date, R_IsUpText Always works. IsUpText doesn't, appostrophes confuse it, and backgrounds confuddle it. Why use something that works 99% of the time, when there is something that works 100% of the time.

From: Bad Boy JH
When hooks are up to date, R_IsUpText Always works. IsUpText doesn't, appostrophes confuse it, and backgrounds confuddle it. Why use something that works 99% of the time, when there is something that works 100% of the time.

Because it doesn't work 100% of the times? When hooks are outdated it wont work…

From: Zyt3x
Because it doesn't work 100% of the times? When hooks are outdated it wont work…

This is like saying that searching for uptext in the wrong spot with the wrong color won't produce valid results all of the time. Of course all of the prerequisites have to be met in order for this to work. That much should be obvious and is irrelevant to this discussion.

Actually I like to use the reflection variety of ChooseOption and IsUptext for my reflection backups - my logic is that if color failed, why re-use color again in case that's what's failing?

Why use color in a reflection script?

From: Method
This is like saying that searching for uptext in the wrong spot with the wrong color won't produce valid results all of the time. Of course all of the prerequisites have to be met in order for this to work. That much should be obvious and is irrelevant to this discussion.

So you're saying Reflection work 100% of the time, because we leave out all the times it doesn't work..?

From: Zyt3x
So you're saying Reflection work 100% of the time, because we leave out all the times it doesn't work..?

No, I'm telling you to compare the two methods for doing whatever it is they do when they both have the capacity to function. You're comparing the accuracy of uptext detection using color techniques to the percentage of time that uptext detection using reflection techniques is available, which is rather silly.

edit: And yes, you might as well leave out the time that reflection needs to be updated, because that is irrelevant to how well the uptext detection works. Like I said before, you're comparing apples and oranges here.

From: Method
No, I'm telling you to compare the two methods for doing whatever it is they do when they both have the capacity to function. You're comparing the accuracy of uptext detection using color techniques to the percentage of time that uptext detection using reflection techniques is available, which is rather silly.

No I don't.. I simply stated that him saying "Reflection works 100% of the time" is wrong. You can't deny that.

From: Zyt3x
No I don't.. I simply stated that him saying "Reflection works 100% of the time" is wrong. You can't deny that.

From: Bad Boy JH
When hooks are up to date, R_IsUpText Always works. IsUpText doesn't, appostrophes confuse it, and backgrounds confuddle it. Why use something that works 99% of the time, when there is something that works 100% of the time.

It seems pretty clear to me that Bad Boy JH's statement hinges on "when hooks are up to date". As I mentioned in my previous post, you're comparing two incomparable things.

If reflection hasn't been updated after a client update, you can't declare that the reflection method for grabbing the uptext works worse than or less frequently than the color method for doing the same thing because you can't measure both of them. I think you simply misinterpreted Bad Boy JH's statement and thought that it implied reflection techniques are always available to use, even if the list of fields is not updated.

From: Method
It seems pretty clear to me that Bad Boy JH's statement hinges on "when hooks are up to date". As I mentioned in my previous post, you're comparing two incomparable things.

If reflection hasn't been updated after a client update, you can't declare that the reflection method for grabbing the uptext works worse than or less frequently than the color method for doing the same thing because you can't measure both of them. I think you simply misinterpreted Bad Boy JH's statement and thought that it implied reflection techniques are always available to use, even if the list of fields is not updated.

Yeah, obviously I'm confused here…

But since color doesn't rely on hooks, doesn't that make the statement "When hooks are updated" just silly?

That's like me saying "When the color function doesn't work, we'll just have to update something and it will work." aka "Color finding works 100% of the time."

From: Zyt3x
Yeah, obviously I'm confused here…

But since color doesn't rely on hooks, doesn't that make the statement "When hooks are updated" just silly?

That's like me saying "When the color function doesn't work, we'll just have to update something and it will work." aka "Color finding works 100% of the time."

No, it doesn't make that statement silly. Having a list of up-to-date field names to find things of interest is just a prerequisite for any reflection algorithm to have the capacity to function, just as any color algorithm needs to be able to 'see' the screen and read data from it. Being able to function doesn't necessarily imply that something will always function properly.

No, it's not. The difference is that the algorithm for finding the uptext using reflection techniques doesn't need to be updated to work 100% of the time. If you want to improve uptext detection using color techniques, it's likely you'll need to modify the algorithm used to do so or write something that does the same thing differently.

From: Method
No, it doesn't make that statement silly. Having a list of up-to-date field names to find things of interest is just a prerequisite for any reflection algorithm to have the capacity to function, just as any color algorithm needs to be able to 'see' the screen and read data from it. Being able to function doesn't necessarily imply that something will always function properly.

No, it's not. The difference is that the algorithm for finding the uptext using reflection techniques doesn't need to be updated to work 100% of the time (or however accurately it does work). If you want to improve uptext detection using color techniques, it's likely you'll need to modify the algorithm used to do so or write something that does the same thing differently.

Since when did we start talking about the algorithm?
I'm talking about the reflection uptext finding in general.

From: Zyt3x
That's like me saying "When the color function doesn't work, we'll just have to update something and it will work." aka "Color finding works 100% of the time."

Well then I guess it needs to be updated because it doesn't work 100% of the time.

ANYWAYS…back on topic. Wizzup, could you add a list to the first post and then we can add suggestions on what needs to be done? My first suggestion, Interfaces.

Holy fucking shit.

Since when did we start talking about the algorithm?
I'm talking about the reflection uptext finding in general.

Method uses algorithm as a synonym for method (no pun intended), not a mathematical algorithm.


Extra 2 cents - Finding uptexts with reflection is stupid as shit because the color one is 100%.

From: n3ss3s
Holy fucking shit.



Method uses algorithm as a synonym for method (no pun intended), not a mathematical algorithm.


Extra 2 cents - Finding uptexts with reflection is stupid as shit because the color one is 100%.

Not for me it isn't..

Example:
Uptext is 'Craft-rune Altar / 2 more options'

WriteLn(rs_GetUpText) prints 'Cra^-rune Altar / 2 more options'

From: n3ss3s
Method uses algorithm as a synonym for method (no pun intended), not a mathematical algorithm.

I know what he meant

From: Ogre
Not for me it isn't..

Example:
Uptext is 'Craft-rune Altar / 2 more options'

WriteLn(rs_GetUpText) prints 'Cra^-rune Altar / 2 more options'

ft would be one of the more tricky combinations for OCRs… use (IsUpText("rune") and IsUpText("ltar"))

Just to answer Method once more: IsUpText() works 100% too, when you think about it that way.

Can we please STOP the Reflection Vs. Color argument in this thread and get back on focus?

From: n3ss3s
ft would be one of the more tricky combinations for OCRs… use (IsUpText("rune") and IsUpText("ltar"))

I know how to deal with it. I'm just saying, I wouldn't call it 100% accurate.

Though it does at least seem to be consistent which is very good.

From: TomTuff
Can we please STOP the Reflection Vs. Color argument in this thread and get back on focus?

This never was a Reflection vs. color argument…

E: The one who de-repped me for this: I agree. Sorry about it.. Some real life issues I have to take care of…
E2: If you'd like to talk to me/help me then I'd very much appreciate it :)

From: Zyt3x
No I don't.. I simply stated that him saying "Reflection works 100% of the time" is wrong. You can't deny that.

Reflection Accuray: 100%
Color Accuracy: 97%

Color Availability: 100%
Refelction Availability: 95%

Reflection - 100*95= 9 500
Color - 97*100 = 9 700

Results out of 10 000

Which is why I still support hybridity.

~RM

I think the point "When Hooks are updated" was there as a point against removing R_IsUpText from the include. Cause if hooks aren't updated, you can't use the reflection include at all, so if you think about it, there was a decent point in what I said.

Not keep the off-topiness going or anything, but i gotta ask a few thing..
RRL is the thing Timer's tryin to do right? (think i read he was banned or somethin too)

@everyone arguing about the percentage of success for both color and ref: who cares?

@Wizzup?: So what I'm getting from this is you want to keep this community from splitting correct? Happens a lot in community type settings… Neighborhoods, churches, businesses, etc…

All over what works better? really guys? I thought we CS majors were supposed to be smart… I agree with wizzy, people(general public) want reflection to do what color cant. Which is fine because that's what it should be. But there's no need for making reflection functions to replace color functions, even if they're not 100% accurate, instead work on improving existing color functions and creating ref things that color seems to fail at. I'd hate to see this community split over reflection…

( If it does: I'm color all the way ;) )

We should always have the 100% accurate reflection versions of the color functions.
We should strive to do the best color and reflection can do. Its the only logical thing to do, I don't see why its a discussion.

we should have, and USE both. Both have great potential, together they should be nigh unbeatable.
I am not anti-colour, or really pro-reflection. I am anti-destruction of good work and potential failsafes.

From: Nose Smasher
@Wizzup?: So what I'm getting from this is you want to keep this community from splitting correct? Happens a lot in community type settings… Neighborhoods, churches, businesses, etc…

All over what works better? really guys? I thought we CS majors were supposed to be smart… I agree with wizzy, people(general public) want reflection to do what color cant. Which is fine because that's what it should be. But there's no need for making reflection functions to replace color functions, even if they're not 100% accurate, instead work on improving existing color functions and creating ref things that color seems to fail at. I'd hate to see this community split over reflection…

( If it does: I'm color all the way ;) )

I doubt it will split, but that's obviously not what we want. We're far from splitting and I don't think we'll ever reach that point.

SRL has split before. In summer 2006 more or half the community was more active over at KYAB for a few weeks.

It didn't last for obvious reasons.

^^ sounds like today with RSbot :p

no worries wizzy, I'm sure once reflection has some direction people will be happy again (:

From: IceFire908
SRL has split before. In summer 2006 more or half the community was more active over at KYAB for a few weeks.

It didn't last for obvious reasons.

brings back memories of rage quits and i remember a massive thread on the subject of reflection

why did kyab never last? it could have been pretty good imo

From: Bonfield
brings back memories of rage quits and i remember a massive thread on the subject of reflection

why did kyab never last? it could have been pretty good imo

Because SMART had all the advantages that KYAB had. Plus, KYAB was developed by BenLand but at the time that ``solarwind'' took over it kind of went downhill. Solar had no real understanding as to how KYAB worked and meanwhile Ben was working on SMART which had all the advantages KYAB had, but not the disadvantages.

Actually KYAB died because solarwind couldn't fix KYAB and he kept telling people either he was fixing it or that it wasn't broken.

Going to go ahead and dig this up. What's the status of reflection reorg? I'm just now getting into some free time and reactivated my RS accounts. I'd like to help out on this, but I warn you, it's been awhile since I've done work in pascal. I think the last script I made was a merchanter way back before the GE and free trade ban.

I've been checking out the reflection subforum and searching a bit but things still seem pretty unorganized and slightly out of date. Is there an IRC server to discuss this stuff real time?

BG: 22, CS major, looking to get involved.

Ransom

From: Ransom
I don't always censor quotes. But when I do, I prefer nonsense.

#srl, #srl-reflection. Not sure how often people check #srl-reflection though.

Both on irc.rizon.net.

You sir, are the most interesting man in the world. Much luffs

Currently, reflection is quite underdeveloped and the staff team has been cut in half since it was reintroduced (drags11, naike, and cstrike are no longer active). Pyroryan keeps the hooks updated, other than that, reflection for the most part has come to a halt.

Welcome back to the cheating scene :)

Sigh, I'll see what I can do. Though no promises as to my activity since I do have more of a life now than before (however small of an increase, it still counts!! :P). But maybe I'll find some time soon after a few of these projects I'm doing for school to get back into it. We'll see.

From: drags111
Sigh, I'll see what I can do. Though no promises as to my activity since I do have more of a life now than before (however small of an increase, it still counts!! :P). But maybe I'll find some time soon after a few of these projects I'm doing for school to get back into it. We'll see.

Damn I'm magic, the day after I say you aren't active anymore, you post :)