Page 4 of 32 FirstFirst ... 2345614 ... LastLast
Results 76 to 100 of 792

Thread: [OSR]Reflection Include

  1. #76
    Join Date
    Feb 2006
    Location
    Australia
    Posts
    628
    Mentioned
    15 Post(s)
    Quoted
    105 Post(s)

    Default

    Quote Originally Posted by Sk1nyNerd View Post
    i didnt say i didnt like it, simply there was/is no walking method for you to use when you dont need the minimap to walk. theres no point on clicking the minimap to walk somewhere when youre destination is 3tiles away.

    ill check out the includes again, didnt realize new walking methods where added, thanks
    You can stay up-to-date using this link: https://code.google.com/p/osrreflection/source/list
    I know what you mean, but using the mainscreen to walk hasn't been very successful, there is a lot of stuff which can get in the way, or it could just walk to the wrong tile (due to screen shifting, the tile grid won't always line up with the map).. In either case, I'd suggest using the minimap, even to walk only 3 tiles. R_ChooseOptionTileUptext or R_ChooseOptionTileColour might be worth looking at if you're trying to perform an action on the tile..

  2. #77
    Join Date
    Oct 2006
    Posts
    6,752
    Mentioned
    95 Post(s)
    Quoted
    532 Post(s)

    Default

    Hooks updated to Revision 41
    “The long-lived and those who will die soonest lose the same thing. The present is all that they can give up, since that is all you have, and what you do not have, you cannot lose.” - Marcus Aurelius

  3. #78
    Join Date
    Feb 2013
    Location
    Narnia
    Posts
    615
    Mentioned
    8 Post(s)
    Quoted
    252 Post(s)

    Default

    can i make a recommendation to replace all the functions that have (option: string, blahblah); with (button: variant, blahblah);

    example1: change

    Simba Code:
    R_ChooseOptionTile(Option: String; Tile: TPoint): Boolean;

    to

    Simba Code:
    R_ChooseOptionTile(button: variant; Tile: TPoint): Boolean;

    it makes more sense to allow the freedom of the user to choose if they want to click left or right and if they right click they can just use the chooseoptions function.

    prevents repetitive right clicking and option choosing when the user just wants to click left.

    (sorry for the double post elfyyy and krazy, didnt think to put in the thread)

    View my OSR Script Repository!


    Botted to max
    Guides: How to Report Bugs to the Scripter
    ~~~~ Moved to Java. Currently Lurking ~~~~

  4. #79
    Join Date
    Feb 2006
    Location
    Australia
    Posts
    628
    Mentioned
    15 Post(s)
    Quoted
    105 Post(s)

    Default

    I answered this in your PM, @Sk1nyNerd
    R_ChooseOptionTile is named as such, because it is only intended for ChooseOption.. Scripters should be capable of making a clicktile function using the resources we have provided.


    Good news everyone! As of 2 hours ago, I uploaded our first official AntiRandom support. I made solvers for the Mime and Forester randoms using reflection, we have detection using reflection for a few more. The way it works, is instead of calling FindNormalRandom; for randoms, you simply call R_SolveRandoms; and any randoms which aren't solved in reflection will use the SRL solvers.
    Last edited by Krazy_Meerkat; 02-24-2014 at 11:53 AM.

  5. #80
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post
    Good news everyone! As of 2 hours ago, I uploaded our first official AntiRandom support. I made solvers for the Mime and Forester randoms using reflection, we have detection using reflection for a few more. The way it works, is instead of calling FindNormalRandom; for randoms, you simply call R_SolveRandoms; and any randoms which aren't solved in reflection will use the SRL solvers.
    Just keep the name as R_FindNormalRandoms and R_FindNonInventoryRandoms. And random solving from reflection include shouldn't call anything from SRL-OSR regarding randoms, make scripters call both functions.
    There used to be something meaningful here.

  6. #81
    Join Date
    Feb 2006
    Location
    Australia
    Posts
    628
    Mentioned
    15 Post(s)
    Quoted
    105 Post(s)

    Default

    Quote Originally Posted by Frement View Post
    Just keep the name as R_FindNormalRandoms and R_FindNonInventoryRandoms. And random solving from reflection include shouldn't call anything from SRL-OSR regarding randoms, make scripters call both functions.
    SRL must be included anyway (The aim of this include is NOT to be seperate from SRL). For the hooks to be checked, the SMART window must already be open. If I had made scripters call both functions, we would be having complaints about the SRL solvers interfering with the reflection solvers. Tbh, most people wouldn't even bother with using randoms if it meant they had to design their own AntiRandom framework.
    Last edited by Krazy_Meerkat; 02-24-2014 at 12:24 PM.

  7. #82
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post
    SRL must be included anyway (The aim of this include is NOT to be seperate from SRL). For the hooks to be checked, the SMART window must already be open. If I had made scripters call both functions, we would be having complaints about the SRL solvers interfering with the reflection solvers. Tbh, most people wouldn't even bother with using randoms if it meant they had to design their own AntiRandom framework.
    Simba Code:
    R_FindNormalRandoms;
    FindNormalRandoms;

    After Reflection has solved a random, there is no random for SRL-OSR to solve, I don't see how they would be interfering with each other?

    P.S. You should handle constructive criticism a bit better, I found your reputation comment quite childish.
    There used to be something meaningful here.

  8. #83
    Join Date
    Jan 2007
    Posts
    8,876
    Mentioned
    123 Post(s)
    Quoted
    327 Post(s)

    Default

    @Krazy_Meerkat; I think you're overreacting here. What exactly are your arguments? The last post was nothing but flame towards Frement.

  9. #84
    Join Date
    Sep 2012
    Location
    Netherlands
    Posts
    2,752
    Mentioned
    193 Post(s)
    Quoted
    1468 Post(s)

    Default

    Quote Originally Posted by Zyt3x View Post
    @Krazy_Meerkat; I think you're overreacting here. What exactly are your points? The last post was nothing but flame towards Frement.
    isn't frement overreacting in the first place..

  10. #85
    Join Date
    Aug 2012
    Location
    The Dark Tower
    Posts
    154
    Mentioned
    5 Post(s)
    Quoted
    56 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post

    Good news everyone! As of 2 hours ago, I uploaded our first official AntiRandom support. I made solvers for the Mime and Forester randoms using reflection, we have detection using reflection for a few more. The way it works, is instead of calling FindNormalRandom; for randoms, you simply call R_SolveRandoms; and any randoms which aren't solved in reflection will use the SRL solvers.
    Oh so wonderful. Declaring 1 procedure for randoms unstead of several. This also explains why I had to swap SetupSRL and SetupReflection in my scripts to get reflection working :P
    Pakki thanks yews all

    Then I find out I was supposed to be doing this the entire time - nothing to see here...
    Last edited by Pakyakkistan; 02-24-2014 at 01:46 PM.

  11. #86
    Join Date
    Jan 2007
    Posts
    8,876
    Mentioned
    123 Post(s)
    Quoted
    327 Post(s)

    Default

    Quote Originally Posted by hoodz View Post
    isn't frement overreacting in the first place..
    As far as I can see, Frement has two posts in this thread; neither of which are flaming anyone and neither of which are worded in an aggressive tone.

  12. #87
    Join Date
    Feb 2006
    Location
    Australia
    Posts
    628
    Mentioned
    15 Post(s)
    Quoted
    105 Post(s)

    Default

    Quote Originally Posted by Zyt3x View Post
    As far as I can see, Frement has two posts in this thread; neither of which are flaming anyone and neither of which are worded in an aggressive tone.
    Frement should've sent a PM. He posted his opinion on something he did not fully understand. I don't want any flaming on the forums or in this thread. But I also wouldn't like to be told what to do by someone who doesn't understand the situation..
    Quote Originally Posted by Pakyakkistan View Post
    Oh so wonderful. Declaring 1 procedure for randoms unstead of several. This also explains why I had to swap SetupSRL and SetupReflection in my scripts to get reflection working :P
    Pakki thanks yews all

    Then I find out I was supposed to be doing this the entire time - nothing to see here...
    I'm glad you like it Pak, I'll certainly be working on solving more randoms with reflection. Considering this is the 1st revision with AntiRandoms, you can expect that we will add much more functionality to AntiRandoms.simba in time. It's quite rewarding to finally start using reflection solvers.
    Last edited by Krazy_Meerkat; 02-27-2014 at 01:51 PM.

  13. #88
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post
    Frement should've sent a PM. He posted his opinion on something he did not fully understand. I don't want any flaming on the forums or in this thread. But I also wouldn't like to be told what to do by someone who doesn't understand the situation..
    "So quick to attack me frement, I voted yes for your [hidden] app." ~ This was the "childish" rep post of mine. I have nothing to hide. Now can we please stay on-topic in this thread.
    Clearly my understanding of the situation is greater then yours, by replacing FindNormalRandoms with R_SolveRandoms in scripts will cause problems. Lets say a player dies, this random is not checked in your R_SolveRandoms, you disregarded this totally. And you are using R_CombatRandoms instead of SRL_CombatRandoms, but you haven't mentioned this at all, instead you just told to use R_SolveRandoms function, which will now cause combat scripts to run away from fights.
    Last edited by Frement; 02-24-2014 at 02:44 PM.
    There used to be something meaningful here.

  14. #89
    Join Date
    Feb 2006
    Location
    Australia
    Posts
    628
    Mentioned
    15 Post(s)
    Quoted
    105 Post(s)

    Default

    Quote Originally Posted by Frement View Post
    Clearly my understanding of the situation is a bit higher then yours, by replacing FindNormalRandoms with R_SolveRandoms in scripts will cause problems. Lets say a player dies, this random is not checked in your R_SolveRandoms, you disregarded this totally. And you are using R_CombatRandoms instead of SRL_CombatRandoms, but you haven't mentioned this at all, instead you just told to use R_SolveRandoms function, which will now cause combat scripts to run away from fights.
    I discussed specifically including FindDead; with elfyyy and we both came to the conclusion that it causes a lot of problems. It's not hard to do a co-ordinate check anyway. Yes I have added our own boolean R_CombatRandoms for combat randoms (in the next revision I will be adding the reflection version of RunAway) The boolean is false by default and it would not run away at all (this feature is not complete, hence I did not mention it).
    Calling R_SolveRandoms; then FindNormalRandoms; would waste memory and time by double-checking for randoms, it could possibly return a false positive and it seems very sloppy and lazy to do it that way.

  15. #90
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post
    I discussed specifically including FindDead; with elfyyy and we both came to the conclusion that it causes a lot of problems. It's not hard to do a co-ordinate check anyway. Yes I have added our own boolean R_CombatRandoms for combat randoms (in the next revision I will be adding the reflection version of RunAway) The boolean is false by default and it would not run away at all (this feature is not complete, hence I did not mention it).
    Calling R_SolveRandoms; then FindNormalRandoms; would waste memory and time by double-checking for randoms, it could possibly return a false positive and it seems very sloppy and lazy to do it that way.
    The problem still exists, currently a script that worked before, if a player dies, the player is not set to false, because that random event is not searched, replacing FindNormalRandoms with R_SolveRandoms, in the event of players death, the script continues with the player that died. And I still don't understand why there is the need for another boolean? Why not use the one already used and provided by SRL-OSR include.
    There used to be something meaningful here.

  16. #91
    Join Date
    Feb 2006
    Location
    Australia
    Posts
    628
    Mentioned
    15 Post(s)
    Quoted
    105 Post(s)

    Default

    Quote Originally Posted by Frement View Post
    The problem still exists, currently a script that worked before, if a player dies, the player is not set to false, because that random event is not searched, replacing FindNormalRandoms with R_SolveRandoms, in the event of players death, the script continues with the player that died. And I still don't understand why there is the need for another boolean? Why not use the one already used and provided by SRL-OSR include.
    Well I see the problem as, scripts with death-walking will fail if they are forced to logout on death. What is stopping you from calling FindDead; yourself? We can't please everyone, and I'm against forcing the FindDead; method on users.
    I wanted to use the SRL combat randoms boolean, but I felt that it was just cleaner to use a seperate boolean.
    Last edited by Krazy_Meerkat; 02-24-2014 at 03:29 PM.

  17. #92
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post
    Well I see the problem as, scripts with death-walking will fail if they are forced to logout on death. What is stopping you from calling FindDead; yourself? We can't please everyone, and I'm against forcing the FindDead; method on users.
    I wanted to use the SRL combat randoms boolean, but I felt that it was just cleaner to use a seperate boolean.
    If you had read the function, you'd know there is a check, similar to SRL_CombatRandoms, it's called Reincarnate.

    Simba Code:
    Reincarnate := True;
    There used to be something meaningful here.

  18. #93
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Krazy_Meerkat View Post
    Well I see the problem as, scripts with death-walking will fail if they are forced to logout on death. What is stopping you from calling FindDead; yourself?
    You should really read the posts before you respond. Reincarnate is a boolean that will not logout the player or set inactive.

    Nothing is stopping me from calling FindDead myself, but is that really the scripters job, if it belongs to antirandoms?

    And I can't be wrong on my initial post, because it was an opinion, which still stands, why change the name of the function if it does almost exactly what it used to do, but more accurately?
    There used to be something meaningful here.

  19. #94
    Join Date
    Feb 2012
    Location
    US
    Posts
    83
    Mentioned
    0 Post(s)
    Quoted
    17 Post(s)

    Default

    Awesome job with the randoms, after reading the code that goes into solving those bad boys I am thoroughly impressed.

    Not to jump in on this and take sides, but I like the fact that both of you are discussing the pros/cons of design choices out in the open and not in PM. It helps people such as myself who aren't intimately involved with development understand what certain things do and why (when documentation/commenting is sometimes scarce...). I found it interesting, and now my knowledge of how the antirandoms work is a little bit better!

    Beyond that, I've read this entire thread a few times over at this point, and I'm very interested in learning how those hooks work (I have looked at the files too). At the very least, what all of those seemingly random variable names + integers actually mean--I read about javahacking as well, though I'm still not approved to actually join those forums yet. I'm not looking for someone to hold my hand, I'll gladly go research on my own, if there is a place to do so.

    A few of the things I'd like to do are reminiscent of the old reflection clients that ended up being shut down; and yeah yeah I know, "most bots should be color here at villavu", etc. etc. But I see no reason to limit the capabilities to color; take for example the many monsters of security stronghold: the same EXACT colors as their surroundings. Sometimes color just can't do everything I want it to.
    Zaros

  20. #95
    Join Date
    Sep 2010
    Posts
    5,762
    Mentioned
    136 Post(s)
    Quoted
    2739 Post(s)

    Default

    How about a
    R_FindNonInventoryRandoms;
    and R_FindNormalRandoms;

    Obviously R_FindNormalRandoms would include R_FindNonInventoryRandoms;

  21. #96
    Join Date
    Feb 2013
    Location
    Narnia
    Posts
    615
    Mentioned
    8 Post(s)
    Quoted
    252 Post(s)

    Default

    Quote Originally Posted by Officer Barbrady View Post
    How about a
    R_FindNonInventoryRandoms;
    and R_FindNormalRandoms;

    Obviously R_FindNormalRandoms would include R_FindNonInventoryRandoms;
    i agree.

    why dont you just merge the current solved osr randoms in color with the new solved randoms in reflection. remove and replace the randoms that are being upgraded. avoids the whole problem of calling both methods of random solving and can be done rather quickly

    View my OSR Script Repository!


    Botted to max
    Guides: How to Report Bugs to the Scripter
    ~~~~ Moved to Java. Currently Lurking ~~~~

  22. #97
    Join Date
    Nov 2007
    Location
    46696E6C616E64
    Posts
    3,069
    Mentioned
    44 Post(s)
    Quoted
    302 Post(s)

    Default

    Quote Originally Posted by Officer Barbrady View Post
    How about a
    R_FindNonInventoryRandoms;
    and R_FindNormalRandoms;

    Obviously R_FindNormalRandoms would include R_FindNonInventoryRandoms;
    Careful, I almost started world war 3 because I suggested that.
    There used to be something meaningful here.

  23. #98
    Join Date
    Sep 2010
    Posts
    5,762
    Mentioned
    136 Post(s)
    Quoted
    2739 Post(s)

    Default

    Quote Originally Posted by Sk1nyNerd View Post
    i agree.

    why dont you just merge the current solved osr randoms in color with the new solved randoms in reflection. remove and replace the randoms that are being upgraded. avoids the whole problem of calling both methods of random solving and can be done rather quickly
    OSR and reflection should be separate but compatible with each other ie can use reflection && color together, that was if either of them break it won't take down the whole project

  24. #99
    Join Date
    Feb 2013
    Location
    Narnia
    Posts
    615
    Mentioned
    8 Post(s)
    Quoted
    252 Post(s)

    Default

    Quote Originally Posted by Officer Barbrady View Post
    OSR and reflection should be separate but compatible with each other ie can use reflection && color together, that was if either of them break it won't take down the whole project
    i dont understand, are you infavor of what i said or is there a problem with what i said and that wont work??

    Im saying put all of the current color solved randoms in the R_FindNormalRandoms so all you have to do is call R_FindNormalRandoms if you are using the reflection include

    using R_FindNormalRandoms therefore completely eliminates the need to call FindNormalRandoms, no?

    View my OSR Script Repository!


    Botted to max
    Guides: How to Report Bugs to the Scripter
    ~~~~ Moved to Java. Currently Lurking ~~~~

  25. #100
    Join Date
    Sep 2010
    Posts
    5,762
    Mentioned
    136 Post(s)
    Quoted
    2739 Post(s)

    Default

    Quote Originally Posted by Sk1nyNerd View Post
    i dont understand, are you infavor of what i said or is there a problem with what i said and that wont work??

    Im saying put all of the current color solved randoms in the R_FindNormalRandoms so all you have to do is call R_FindNormalRandoms if you are using the reflection include

    using R_FindNormalRandoms therefore completely eliminates the need to call FindNormalRandoms, no?
    Why put all the color randoms in R_FindNormalRandoms; the point of R_FindNormalRandoms; is to call reflection randoms, not color randoms. If we called the color randoms in the reflection randoms that would be misleading If one wanted to call both then they could simply do

    Simba Code:
    procedure findAllRandoms;
    begin
      findNormalRandom;
      R_FindNormalRandoms;
    end;

    Shouldn't be hard at all for somebody who is scripting

Page 4 of 32 FirstFirst ... 2345614 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •