Results 1 to 15 of 15

Thread: objects.simba (smartcolors.simba)

  1. #1
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default objects.simba (smartcolors.simba)

    So, Zyt3x convinced me to be in favor of a database, I'll address that a little here, as well as what I think should happen with objects/smartcolors.simba.

    • Completely replace the current objects.simba with a combination of MSI's object finding and smartcolors.simba. Will keep the name objects.simba, though.

    • Have a global type, TRSObject, that can be imported to scripts/SRL files if needed (i.e. bank.simba could utilize object functions).

    • Since SmartColors updates a global SC array during runtime, the final array can be uploaded to a database periodically throughout a script, or at the end. This would ensure everyone is using the most up to date object records. I'm not going to get into details about a database, but I just want you guys to think about it.

    • For bank.simba, TRSObject could be used something like this:
      Simba Code:
      // any file that requires object finding; will use bank.simba or this example

      {$include_once objects.simba}

      const
        BANK_VARROCK_EAST = 0;

      function __getBankObject(bank: integer): TObject; // TObject will be in the object.simba file
      begin
        case bank of
          BANK_VARROCK_EAST:
            with result do
            begin
              // attributes here
            end;

        end;
      end;

      function openBank(bank: integer): boolean;
      begin
        clickObject(__getBankObject(bank));
      end;

      // whatever other bank functions here

      begin
      end.


    Basically the new objects.simba will just be an intelligent object finding library. Scripters can choose whether or not to use it, of course.

    Thoughts?

  2. #2
    Join Date
    Aug 2007
    Location
    Colorado
    Posts
    7,421
    Mentioned
    268 Post(s)
    Quoted
    1442 Post(s)

    Default

    I've never seen MSI's previous object-finding routines because I've never used it. I'm definitely for this idea though.

    Current projects:
    [ AeroGuardians (GotR minigame), Motherlode Miner, Blast furnace ]

    "I won't fall in your gravity. Open your eyes,
    you're the Earth and I'm the sky..."


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

    Default

    Nice thread, I'll start coding and planning something tonight

  4. #4
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default

    For objects.simba? Or a database? @Zyt3x;
    Last edited by Coh3n; 02-15-2013 at 03:24 PM.

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

    Default

    Yes

  6. #6
    Join Date
    Aug 2007
    Location
    Colorado
    Posts
    7,421
    Mentioned
    268 Post(s)
    Quoted
    1442 Post(s)

    Default

    If we have a standard format for TObject then I'd surely like to help with the database.

    Current projects:
    [ AeroGuardians (GotR minigame), Motherlode Miner, Blast furnace ]

    "I won't fall in your gravity. Open your eyes,
    you're the Earth and I'm the sky..."


  7. #7
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default

    Quote Originally Posted by Zyt3x View Post
    Yes
    Sooo, both?

    Quote Originally Posted by Flight View Post
    If we have a standard format for TObject then I'd surely like to help with the database.
    That's the plan. It can likely be done with items as well as I know @WT-Fakawi; and @BraK; have an idea for an items.simba include.

  8. #8
    Join Date
    Mar 2006
    Location
    Behind you
    Posts
    3,193
    Mentioned
    61 Post(s)
    Quoted
    63 Post(s)

    Default

    An Items include isn't really going to do any good. what needed is going to be self updating object handling procedures. I'm sure @WT-Fakawi; could talk on this process for a long time to come. Basically reading an object that's there and having it update it's own file that would be specific on the users computer.

    This system wouldn't really be in any relative order and it would only load specific object for each script. WT has used this system several times in the past in his script for object handling.

    "Sometimes User's don't need the Answer spelled out with Code. Sometimes all they need is guidance and explanation of the logic to get where they are going."

  9. #9
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default

    Quote Originally Posted by BraK View Post
    An Items include isn't really going to do any good. what needed is going to be self updating object handling procedures. I'm sure @WT-Fakawi; could talk on this process for a long time to come. Basically reading an object that's there and having it update it's own file that would be specific on the users computer.

    This system wouldn't really be in any relative order and it would only load specific object for each script. WT has used this system several times in the past in his script for object handling.
    I know, that's what I meant. Instead of a local file, though, it would be better to upload items to an online database so everyone can take advantage of it. But yes, it would be self generated, like objects.simba.
    @WT-Fakawi; I know you've mentioned it many times; but I still don't understand how this could be more human-like. Care to elaborate?

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

    Default

    Remember that we create the database as smart as we want it to be. If we want to store "similar" items/objects together, then we could do that; it's all just a matter of how much time we want to spend on it. I'd be willing to spend quite some time on it, myself.

    I think this is worth a go.

  11. #11
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default

    @Zyt3x; you can work on a database if you wish; you seem to have thought about it a lot more. I'm going to work on getting SRL-6 to a beta stage. A database can really be added at any time, assuming it'll utilize SRL's object/item types.

    Are you going to write code for objects.simba as well? I don't mind doing it since I likely know MSI's object routines better than you do (since I wrote a lot of it). I think I might look at text.simba first, though since a lot of things require uptext and chooseOption. I'll probably make a thread about it soon.

  12. #12
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default

    Moving this to the public -- do you think it's a good idea to have such a objects library in SRL? Or should that be left up to the scripter? Are the mainscreen object finding functions enough?

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

    Default

    Ooooooh, Coh3n leaking WT-Fawki's scripts to the public ;O That doesn't happen often.

    @ Public :
    What we're talking about here is a smart database over objects and possibly items, locations, npcs and locations that will maintain it's integrity by automatically adjusting to color updates much like MSI did with Rasta Magician's smartcolors.simba code.

    Benefits of having such a database:
    - Scripters will have more time creating the actual script, rather than collecting colors and making DTMs and so forth
    - The database can more easily be linked to the SRL Stats system, meaning more accurate data collection for the stats
    - The database can (possibly) eventually (maybe) become a RuneScape Wiki (mayhaps) of some sorts, meaning not only botters will benefit from it, but also the greater public (?)

  14. #14
    Join Date
    Apr 2008
    Location
    Marquette, MI
    Posts
    15,252
    Mentioned
    138 Post(s)
    Quoted
    680 Post(s)

    Default

    That was totally by accident.

  15. #15
    Join Date
    Sep 2012
    Location
    Here.
    Posts
    2,007
    Mentioned
    88 Post(s)
    Quoted
    1014 Post(s)

    Default

    Quote Originally Posted by Coh3n View Post
    That was totally by accident.
    Don't worry. Already copied it

    (jk, I read it and left it)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 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
  •