Page 1 of 3 123 LastLast
Results 1 to 10 of 30

Thread: Rules of Scripting

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Banned
    Join Date
    May 2010
    Location
    fuck off?
    Posts
    1,145

    Default Rules of Scripting

    Here I think certain rules of scripting should be established.

    I like what Sor has done with maths.scr, func_maths.rar.


    All these scripts should go inside "/reborn" dir
    All the scripts instead of global/, go in reborn.

    All should have version number and date dated, with edits by user at the top
    Comments in the scripts saying exactly what version it is

    All "functions" should start using camelCase?
    All the functions should be capitalised
    local.lala = reborn/strings.scr::trimAllTheSpacesFromString local.lol

    File names should be lower case
    only bBecause I think it makes it easier to write,,
    local.lala = reborn/strings.scr::TrimAllTheSpacesFromString local.lol
    vs
    local.lala = reborn/Strings.scr::TrimAllTheSpacesFromString local.lol


    Quick links in a listener to the script parts

    level.script.function etc

    Variable names should show their type
    int = local.iVariable
    float = local.fVariable
    string = local.sVariable
    entity = local.eVariable
    player = local.pVariable
    type ./ template = local.tVariable

    Scripts

    strings.scr
    maths.scr
    files.scr

    maybe a Ihuddraw thing, we have lots of conflicts there?
    I envisioned something like
    local.hudID = waitexec reborn/hud.scr::GetNextHudID

    and GetNextHudID would simply keep track of id's
    GetNextHudID:
    level.ids++
    end level.ids



    Many new mods will need updating.

    Thoughts?
    Last edited by Elgan; September 16th, 2012 at 05:54 PM.

  2. #2
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Filenames should be lowercase, and if they are made of two words, I'd use underscore _ .

    I'd start functions with lowercase but make them camelcase, so it's basically what you wrote Elgan, but just start from lowercase:

    local.lala = waitexec reborn/some_file.scr::doSomeStuff local.player[2]

    This is a Java-like casing. Classes in Java are camelcase and start with first capital in uppercase, while methods/functions have first letter in lowercase.

    Code:
    class ThisIsMyClass {
          public String getSomeData() {
                 return "data";
          }
    }
    
    class App {
    
          public static void main(String[] args) {
             ThisIsMyClass thisIsMyClass = new ThisIsMyClass();
    
             String data = thisIsMyClass.getSomeData();
             system.out.printl(data);
    
          }
    
    }
    Something like this.

    Also I'd skip the comments about edits in the file header, because we have this in Git commit comments, together with date and time, and diff. But on the other hand, I don't have anything against if you really want them included in the scripts.

    I think that the idea with storing functions in level variable is pretty nice, because it can make scripts shorter, and also it provides a nice possibility to override standard functions with own implementations and writing script-hooks instead of modifying original libs.

    Fragment from math.scr
    Code:
    level.MATHS[avg] = global/func_maths.scr::calcAvg
    Then later in the script you do:

    Code:
    local.average = waitexec level.MATHS[avg] local.numberArray 0
    And modders can write hooks and their own implementations:

    Code:
    local.orig_avg = level.MATHS[avg];
    
    level.MATHS[avg] = global/my_avg_that_calls_orig_avg.scr::avg
    But instead of level.MATHS[avg] I'd do the same you did with files.scr so we would have

    level.maths.avg, or $math.avg

    This would be pretty cool.
    Currently I've added scripts but they need rewriting to match our coding standards.

  3. #3
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Also we need to edit files.scr so it supports whole file limit instead of only 10 files. There's a CVar that keeps track of opened files. You can check it in the Wiki.
    I'd also re-do some functions to work faster. I will add some functions for reading whole file into string to the engine so it will be faster. I'll also add fileExists function.

    We'll need to edit maths.scr, and I'll add some math functions to the engine so they will be faster (like sqrt and so on), and maths.scr will just use them and act as a wrapping library for them.

  4. #4
    Developer Sor's Avatar
    Join Date
    Aug 2010
    Location
    The Medieval City of Bruges
    Posts
    747

    Default

    Quote Originally Posted by Elgan View Post
    All these scripts should go inside "/reborn" dir
    All the scripts instead of global/, go in reborn.

    All should have version number and date dated, with edits by user at the top
    ...

    All "functions" should start capitalised? or lower?
    ...

    File names should be lower case
    ...
    I agree. Though the rule about avoiding lowercase function/thread names, I'm not sure if it really matters. I write them without underscores and in lowercase, but I capitalize every word that is attached to a previous word so I don't get confused during a bout of late-night coding. (EDIT: Had no idea it was called camelcase )

    Filenames should definately be in lowercase though. If you forget to put a capital letter mohaa won't recognize what you're trying to open and execute, unlike when you are executing threads.

    Quote Originally Posted by Elgan View Post
    Sor added this...
    I actually did it because it is less effort to write and easier to remember commonly-used functions that way. It's quite convenient.

    Quote Originally Posted by Elgan View Post
    Scripts
    strings.scr
    maths.scr
    files.scr
    I've written a func_strings.scr as well and I'm already in the preparations to write a func_file. But I suggest to add your versions, Elg, or compare the two maybe. My versions will be a little too "biased" as they're written with a specific project in mind.

    I see the ihuddraw idea you proposed isn't as invasive as it sounded. This sounds like a simple way to manage the huddraw. However, not only all mods with ihuddraw would have to be re-written (giving level vars to their indexes, as they will no longer be fixed numbers) but also all normal huddraw mods will need to be edited in the same way as they use the same indexes. Not too sure about that... at the same time I know what an uncontrollable mess huddraw has been in the modding community. We could include it and it may be used as a standard from then on. Someone still has to do something about all the other mods employing huddraw functions.

    Quote Originally Posted by RazoRapid
    Also I'd skip the comments about edits in the file header, because we have this in Git commit comments, together with date and time, and diff. But on the other hand, I don't have anything against if you really want them included in the scripts.
    True, although I think Elgan intended it to be more an insurance when the file is actually out there and other modders start editing bits of the files and suddenly we've got 3 or 4 nearly identical copies of the same script. This is often the case with widely-used mods & scripts.

  5. #5
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    getNextHuddrawId is simple yet awesome thing! We should add it and use it. I don't mind updating some commonly used mods to look and work better. All in all it will be as easy as Find/Replace job in most cases with things like these.

    We may also consider using simplified hungarian notation, because it will help to know what is the basic type of the variable and then it helps because you know you have to actually cast that value and so on.

    local.aVariable -> arrays
    local.iVariable -> integers
    local.fVariable -> floats
    local.vVariable -> vector
    local.sVariable -> string
    local.bVariable -> boolean (int of value 0 or 1)
    local.cVariable -> char (string with length equal 1)
    local.mVariable -> mixed (structure, like local.player, local.file and so on)

    What do you think about it?
    Imho it would help if you have to deal with such variable and you need to cast it.

    When you see local.vVariable you know it's a Vector and you know you can use some vector operations on it right away, instead of searching through hundreds of code lines to find out the line where the variable actually gets initialized with vector.

    Elgan, if you can please create guidelines and we can start using them.

    Sor, I'd change the array local.MATHS[xxx] to local.maths.xxx or $maths.xxx, or $std.maths.xxx, or $stdlib.maths.xxx, or $reborn.maths.xxx or $rebornlib.maths.xxx

    I really like $stdlib.libname.functionname, $std.libname.functionname, or just $libname.functionname. This will make it clear, clean, and beautyful in my opinion And we'll still keep everything in reborn folder just like now.

  6. #6
    Developer Sor's Avatar
    Join Date
    Aug 2010
    Location
    The Medieval City of Bruges
    Posts
    747

    Default

    Quote Originally Posted by Razo[R]apiD View Post
    getNextHuddrawId is simple yet awesome thing! We should add it and use it. I don't mind updating some commonly used mods to look and work better. All in all it will be as easy as Find/Replace job in most cases with things like these.

    We may also consider using simplified hungarian notation, because it will help to know what is the basic type of the variable and then it helps because you know you have to actually cast that value and so on.

    local.aVariable -> arrays
    local.iVariable -> integers
    local.fVariable -> floats
    local.vVariable -> vector
    local.sVariable -> string
    local.bVariable -> boolean (int of value 0 or 1)
    local.cVariable -> char (string with length equal 1)
    local.mVariable -> mixed (structure, like local.player, local.file and so on)

    What do you think about it?
    Imho it would help if you have to deal with such variable and you need to cast it.

    When you see local.vVariable you know it's a Vector and you know you can use some vector operations on it right away, instead of searching through hundreds of code lines to find out the line where the variable actually gets initialized with vector.
    Sounds neat but how do you translate that into the scripting engine? We cannot check the name of a variable, it's just there. In other words the variable name has no variable. The alternative is adding derivatives of the local. variable class for each particular kind of variable, but I think that would be a clumsy and messy approach. Rather than talking about the technical issues, I don't see much practical use. At the price of making our functions essentially failproof, we'd have to accommodate for each of these outcomes while it is more efficient to write functions to act on what kind of variable is expected to pass through. I admit not everyone succeeds in actually and effectively doing this.

    On the other hand, this can allow the existence of functions that are able to perform 2 different tasks with two different types of input (or just additional 'contextual' input for a function without having to conform to the rigid variable arrangements) but using the same variables. Something like:
    Code:
    func var1 var2:
    if (var1 == float) {
       store in fvar
       if (var2 == vector) {
          store var2 in vvar
       }
    } else if (var1 == vector) {
       store in vvar
       if (var2 == float) {
           store in fvar
       }
    }
    //do stuff
    Quote Originally Posted by Razo[R]apiD View Post
    Sor, I'd change the array local.MATHS[xxx] to local.maths.xxx or $maths.xxx, or $std.maths.xxx, or $stdlib.maths.xxx, or $reborn.maths.xxx or $rebornlib.maths.xxx

    I really like $stdlib.libname.functionname, $std.libname.functionname, or just $libname.functionname. This will make it clear, clean, and beautyful in my opinion And we'll still keep everything in reborn folder just like now.
    I considered it before, but where I'll use them I'll be using a lot of ents by default so I passed on it, but now I'll switch over to this. Using Listeners (usable post-spawn) and SimpleEntities (usable pre-prespawn) as placeholders for the data structs we wish to use, we can add dynamic and flexibility to global variables. I've found that those particular types of entities are not accounted for in the engine's free-edict cap, which crashes a map when approximately 1024 entities are being rendered at once. In other words, that's good news I prefer $libname.functionname, though. Concise and simple.
    Quote Originally Posted by Razo[R]apiD
    Idea about Huddraw IDs. We could make 2 functions, one to get iHuddraw Id and another one for global huddraw. We could divide all 255 indexes into 2 groups, so we would have 125 indexes for iHuddraw, and 125 indexes for huddraw, and 5 indexes reserved for reborn engine.

    And mods would use getters to get id's only from certain id groups, so they wouldn't overwrite another huddraws and ihuddraws and huddraws wouldn't get mixed.
    And when the limit gets exceeded, it would return -1 or 256 which should be handled by the mod or will just make huddraw and ihuddraw spawn an error in console.
    I'm for this idea of splitting those indexes up. I'm using the same method to assign indexes to huddraw functions in my projects so will switch over when this is incorporated.
    But I wonder how we are going to receive a -1 or 256 error response in script? We could make the huddraw functions return a var when they're used with a specific index, but just using a new cmd to check if the index is already in use.
    'In use' as in the sense of 'have there been any huddraw commands executed on that particular index so far'.

    Quote Originally Posted by armageddon
    I also like the idea of access all of the functions by means of level. variables...but, is there a limit to level variables? 256?
    Maximum of 1024 variables times the maximum of 1024 variables (if each of those first variables were an array) and so on, basically. This goes for each variable class (game, level, group, local). Variables galore I'd say.
    For the Listener/SimpleEntity variable structs. I believe each entity can have a maximum of 1024 variables (disregarding base entity variables like .origin, . angles, .targetname...). But I do not know yet how many of such entities we can spawn.
    Though, I know for sure it is at least twice the cap of aforementioned free edicts for rendered and more complex entities.

    Quote Originally Posted by Razo[R]apiD
    I'm adding additional functions to the engine this evening.
    Which ones are you adding, Razo?

    Quote Originally Posted by Razo[R]apiD
    Elgan please summarize the rules and we can start doing something.
    On the same subject, what are we going to do with those rules? While I'm sure the most active scripters on here would conform without a hitch, I don't think everyone will. I do think more people would 'conform' or, rather, 'benefit' from the new functions and placeholders we're adding to make their job easier, than to a set of rules for how they do their job.
    The problem with rules is they have to be enforced, or the rules won't be able to serve their purpose. Speaking of purpose, it doesn't seem worth it to go to such lengths for.

    What would be nice though is adding a comment to end (or start) of a script, when it was last edited and who 'used' (or execute the file) by means of computer name or something. Kind of like what ms word does these days.
    And if it really must, we can write a function that converts every thread name in a specific script into camelCase (but it only really works if all scripts linked to it have the same done) or have the engine do it at start up while at the same time have it check the filename for uppercase chars.
    Last edited by Sor; September 16th, 2012 at 03:43 PM.

  7. #7
    Über Prodigy & Developer Razo[R]apiD's Avatar
    Join Date
    May 2010
    Location
    Poland, Lublin
    Posts
    3,257

    Default

    Idea about Huddraw IDs. We could make 2 functions, one to get iHuddraw Id and another one for global huddraw. We could divide all 255 indexes into 2 groups, so we would have 125 indexes for iHuddraw, and 125 indexes for huddraw, and 5 indexes reserved for reborn engine.

    And mods would use getters to get id's only from certain id groups, so they wouldn't overwrite another huddraws and ihuddraws and huddraws wouldn't get mixed.
    And when the limit gets exceeded, it would return -1 or 256 which should be handled by the mod or will just make huddraw and ihuddraw spawn an error in console.

  8. #8
    Developer Todesengel's Avatar
    Join Date
    Dec 2013
    Location
    St. Louis, Missouri, USA
    Posts
    276

    Default

    Quote Originally Posted by Razo[R]apiD View Post
    Idea about Huddraw IDs. We could make 2 functions, one to get iHuddraw Id and another one for global huddraw. We could divide all 255 indexes into 2 groups, so we would have 125 indexes for iHuddraw, and 125 indexes for huddraw, and 5 indexes reserved for reborn engine.

    And mods would use getters to get id's only from certain id groups, so they wouldn't overwrite another huddraws and ihuddraws and huddraws wouldn't get mixed.
    And when the limit gets exceeded, it would return -1 or 256 which should be handled by the mod or will just make huddraw and ihuddraw spawn an error in console.
    Yes I know this is a very old post, but I'm interested in the topic

    Did getiHuddrawId and allocating the indexes ever get implemented? I didn't see it anywhere... One of the mods I'm working on uses ihuddraw_xxxx referencing hard-coded indexes, and figured while I was in there I'd change to getting an index as described above. I am new to using huddraw stuff, so hope I'm understanding the intention/purpose above correctly.

    Todesengel

  9. #9
    Developer RyBack's Avatar
    Join Date
    Apr 2014
    Location
    In Front of the screen
    Posts
    1,603

    Default

    Quote Originally Posted by Todesengel View Post
    Yes I know this is a very old post, but I'm interested in the topic

    Did getiHuddrawId and allocating the indexes ever get implemented? I didn't see it anywhere... One of the mods I'm working on uses ihuddraw_xxxx referencing hard-coded indexes, and figured while I was in there I'd change to getting an index as described above. I am new to using huddraw stuff, so hope I'm understanding the intention/purpose above correctly.

    Todesengel
    Well no, but ihuddraw doesn't work like that anyways.
    The only difference between huddraw and ihuddraw is the "i' and the player argument.
    Internally huddraw broadcasts the hud message to all clients, while ihuddraw broadcasts the hud message to one single client. the first 5 indices are indeed reserved for reborn but otherwise ihuddraw has the same range as huddraw.
    So you can huddraw a string with id 15 to all clients, then ihuddraw to a specific client another string with index 15 and it will be only different for that specific client only.

    TL;DR
    huddraw is basically ihuddraw to all clients.

  10. #10

    Default

    Very nice ideas guys!

    I like the idea of splitting the ihud/huddraw indexes. Then one could make a reference to it - ie: local.killsHud = getNextIHud;
    Then we would just use local.killsHud whenever we need to manipulate that one ihud. etc...

    I also like the idea of access all of the functions by means of level. variables...but, is there a limit to level variables? 256?

Posting Permissions

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