Page 2 of 2 FirstFirst 12
Results 26 to 34 of 34

Thread: Is this useful?

  1. #26
    Join Date
    Dec 2013
    Location
    Pitcairn Island
    Posts
    288
    Mentioned
    20 Post(s)
    Quoted
    166 Post(s)

    Default

    Quote Originally Posted by One Kid View Post
    What is the difference, or should I say reason for using this over record with all the values you need? Just curious.
    There is no logical reason. If anything, it is more effort this way to achieve the same result.

    IMO, if you're going to load colors from file, the colors should be raw, and not CTS1/CTS2 (hue, sat, tol, etc). The main advantages of loading raw color info from file is nobody (scripter or user) has to touch any color values. However, if you go CTS1/2 you still have to copy all the individual color setting values over from ACA into the file (so you might as well just copy them over to the script).

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

    Default

    I think some people are missing the 'point' of using a file, it has nothing to do with speed


    Storing info in files(were talking strictly about storing stuff in files using this system or not) allows the writer to do 2 things:

    1) store a lot of variables information information outside of the script that would otherwise take up lots of space. This way if you have, say, a combat script with information 50 monsters all that information doesn't take up 800 lines of the script. There is no real advantage to this point other than the script being easier to read

    2) You can 'update' a script in 1 compile time. What i mean by this is, let's say your monster/object color get outdated. Just grab the file string from a webpage and save it. or, let's say I have a combat bot and I am constantly adding new monsters. Bam, user compiles and 10 new monsters are added. As tls said storing info in a file also allows a user to create their own objects and save them locally




    Now all this script does is offers the scripter a way to read the information in a somewhat organized manner.

  3. #28
    Join Date
    Dec 2007
    Posts
    2,112
    Mentioned
    71 Post(s)
    Quoted
    580 Post(s)

    Default

    Quote Originally Posted by rj View Post
    Now all this script does is offers the scripter a way to read the information in a somewhat organized manner.
    This for sure. Most people cant be bothered looking through a script to change color info. Easier for it to be in a file external to the script.

  4. #29
    Join Date
    Sep 2008
    Location
    Not here.
    Posts
    5,422
    Mentioned
    13 Post(s)
    Quoted
    242 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    Bad idea imp, because you're going to have to open the file every single time, read what you want, close; repeat. Updates to files aren't dynamic. Also opening a file while in use can be a problem.
    Are you really saying that opening, reading, and closing a file is a bad idea while running a script?

  5. #30
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by tls View Post
    Are you really saying that opening, reading, and closing a file is a bad idea while running a script?
    That's exactly what I'm saying. Are you actually suggesting that it isn't?


    If the script has to load colour info from the file EVERY loop, it has to open it every loop, close it every loop, in order to avoid sharing violations (and it has to do it quickly before the other program attempts to touch the file). Two programs cannot open the same file at the same time without proper synchronization (none of which Simba has). The first program might not see the modifications of the second program (notepad or w/e editor). What if you write to the file and save while the other program is reading?

    You WILL have syncing issues.

    Some text editors lock files for read/write access. What's going to happen when Simba tries to read it and can't? Your script is going to fail.
    What happens when the person doing the modification presses Ctrl+S to save before completing all modifications? The script will read a half-modified file.


    On Windows you CAN get the error: "The process cannot access the file because it is being used by another process". Even if the file was opened with FILE_SHARE_READ.



    https://msdn.microsoft.com/en-us/library/aa363858.aspx

    You cannot request a sharing mode that conflicts with the access mode that is specified in an existing request that has an open handle. CreateFile would fail and the GetLastError function would return ERROR_SHARING_VIOLATION.

    In other words, if the file was opened with Simba with FILE_SHARE_READ and notepad attempts to open it with GENERIC_READ, it will FAIL to open. If the file succeeded in opening with notepad first with GENERIC_READ and Simba tries to open it with FILE_SHARE_READ, it will FAIL to open. BOTH programs have to open it with the same flags or one of them risks getting a sharing violation.
    Last edited by Brandon; 02-07-2016 at 04:08 AM.
    I am Ggzz..
    Hackintosher

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

    Default

    Quote Originally Posted by Brandon View Post
    Are you actually suggesting that it isn't?


    If the script has to load colour info from the file EVERY loop, it has to open it every loop, close it every loop, in order to avoid access violations. Two programs cannot open the same file at the same time without proper synchronization (none of which Simba has). The first program might not see the modifications of the second program (notepad or w/e editor). What if you write to the file and save while the other program is reading?

    You WILL have syncing issues.

    Some text editors lock files for read/write access. What's going to happen when Simba tries to read it and can't? Your script is going to fail.
    What happens when the person doing the modification presses Ctrl+S to save before completing all modifications? The script will read a half-modified file.
    shouldn't the scripter just load all the information on startup? Not much use in constantly reading the files, all access violations aside seems like it would be redundant

    edit: just read tls's post about the goblin colors, doesn't really seem like theres much use to keep a script that's not working right running so that you can fix it without having to re-run it

  7. #32
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by rj View Post
    shouldn't the scripter just load all the information on startup? Not much use in constantly reading the files, all access violations aside seems like it would be redundant

    edit: just read tls's post about the goblin colors, doesn't really seem like theres much use to keep a script that's not working right running so that you can fix it without having to re-run it

    Other developers on this thread was suggesting that you can dynamically change the behaviour of the script without re-running the script by modifying the file, while the script is running (without stopping it).

    That's comes with a lot of risk. Yeah, I'm suggesting that the scripter load from the file once (at the start), and forget about it after. Otherwise load from the file whenever necessary, but don't go modifying it knowing that the script is currently using it, in hopes to gain some dynamic behaviour.
    Last edited by Brandon; 02-07-2016 at 04:02 AM.
    I am Ggzz..
    Hackintosher

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

    Default

    Quote Originally Posted by Brandon View Post
    Other developers on this thread was suggesting that you can dynamically change the behaviour of the script without re-running the script by modifying the file, while the script is running (without stopping it).

    That's comes with a lot of risk. Yeah, I'm suggesting that the scripter load from the file once (at the start), and forget about it after. Otherwise load from the file whenever necessary, but don't go modifying it knowing that the script is currently using it, in hopes to gain some dynamic behaviour.
    Oh, well I'm not sure what their on about

    Quote Originally Posted by rj View Post
    Now all this script does is offers the scripter a way to read the information in a somewhat organized manner.

  9. #34
    Join Date
    Sep 2008
    Location
    Not here.
    Posts
    5,422
    Mentioned
    13 Post(s)
    Quoted
    242 Post(s)

    Default

    Obviously the goblin example is trivial, but if the logic is 100% and its just data changing, then loading from file is a fine idea(I have used this before to dynamically load client hooks after reloading SMART).

    Brandon, you are arguing over a use I did not mention. I clearly stated that the script would only load the data from file on a specific trigger(in that case a form button click). There is absolutely NOTHING wrong with that. The script user should know not to modify it WHILE triggering the load, that's just....duh.

Page 2 of 2 FirstFirst 12

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
  •