Results 1 to 9 of 9

Thread: Framework

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

    Default Framework

    I will briefly outline what I want the scripting framework to do, especially.

    (1) Libraries like Math, String, File... which provide a standardized set of functions specific to their fields.
    I'm awaiting an update from Razo, after which I'll be able to finish this part once and for all so I can move
    on to the more interesting bits

    (2) A tighter client-server relationship for modding. Specifically, a primitive account system will allow modders
    to attach global or server-specific retrievable data or key binds to the clients themselves (identified by login,
    represented as objects in script) rather than a fleeting player entity. I want to add some statistical data by default.
    Depending on the schedule, this may be basic kills/deaths stuff or this may be an integrated 'elgbot'
    (if Elgan lets me ).

    (3) Some new server functionality. For instance, a built in CVar parser which will parse the new contents of a cvar
    and pass them on as arguments to a specific scriptthread. Also, executing a script via console will be possible.
    Also a dynamic local storage system, based on the localStorage object of HTML5/Javascript.

    (4) A standard HUD system which sees each player as a pool of 256 elements that can be allocated and released.
    Individual elements have priority over global elements, so in time of shortage, global elements may be temporarily
    overridden for a specific client. This way modders need never worry about huddraw indexes or conflicts again.

    (5) Server-side menu system. Menu's are represented as objects with child menu's, tabs, pages, buttons...
    Ideally, one can use a tool (i.e. a serverside-menu ^^) to construct these menu's and they are then saved
    to file. I'm not planning on supporting dynamic changes to menu's (are written only once), but if someone has
    a good argument for it, I'm all ears.

    I'm hoping to have mouse support (hardest part really) for this, otherwise, you'll have to up, down, left, right
    or tab your way through the menu.

    (6) Weapon control. Unfortunately, being able to access each item/weapon a player has still only allows us to
    set certain properties but not 'get' them. On the upside, you'll be able to change any TIKI setting on the fly.
    There will be support for 'weapon configuration files' wherein you change settings of a specific weapon (or
    prohibit it) either in a global scope or by gametype, by mod or by map.

    (7) Mod control. One can use the auto-execution folders to run their mods instead of using the dmprecache,
    or one can use a mod configuration file to detail the mod's behaviour. In the latter case, the framework will
    then auto-execute the main script based on the info. This includes but is not limited to:
    whether a mod is a gametype, when it may run (global, gametype, mod, map), path to possible .ini file etc...

    (8) Map control. Finally some standardized functionality so a modder can change maps (retaining player state or not),
    restart map, restart round, end round (with draw, allieswin or axiswin), ignore the timelimit etc...
    In addition, I'm hoping to introduce dynamic sector locations (like North, East, Southwest) for any map to which one
    can easily add custom locations that mods like Freeze-Tag can use to identify a location in the map.

    I will also support a map configuration file which defines cvars that need to be applied for specific maps; also
    path of the file defining the locations, full name of the map...



    This isn't set in stone yet. While we may quibble over the details, I think most of us can agree that the framework
    should at least do that. Nonetheless, anyone have thoughts or suggestions?

    But we may be focussing on modders too much and not on players. Which is why I want add an simple 'match'
    environment of which a basic set of restrictions can be customized (like mods that are allowed to run, number of
    players on each active team, number of spectators...) and violation of any restriction will result in a specific
    effect (like pausing the match/round, kicking the violator etc...).

    However I'm not too familiar with clans, so I need some input on this from Steve and other people who are familiar with
    or member of clans.

    Let the discussion begin!
    Morpheus Script (MoH) => You try to shoot yourself in the foot only to discover that MorpheusScript already shot your foot for you.

  2. #2
    Administrator JoTo's Avatar
    Join Date
    May 2010
    Location
    www.scapp.net
    Posts
    1,953

    Default

    Not sure if I have understand 2) and the purpose of it.

    To 7). Does it include a kinda plug 'n play system for mods ?
    Example to make clear what I believe needs to get sorted:
    I recently tried to adjust a rifle/sniper server to a rifle only server with a set of mods allready on the server, I found 3 different state file sets and 2 different weapon control scripts and on a quick sight I was not able to tell which one exactly is used. (Ofc digging deeper and add debug lines etc would have revelead it, but I had no time to spend hours on this). If at least the overwriting of different state files could be solved, it would be nice I think.

  3. #3
    Banned
    Join Date
    May 2010
    Location
    fuck off?
    Posts
    1,145

    Default

    I guess great minds do think a like because I was just thinking of posting the other day about having a proper elgbot framework,

    because I keep seeing the same things done over and over...
    elgbot defines all its events in arrays and all its settings in arrays. I did it that way so it can easily be extended or changed.
    I was thinking it could be set to execute event files so that it is more framework like and executes an event so people can just use a register to ask for a callback upon a player getting a certain set amount of kills...
    then there is saving which should be more modular so that a "clan" "match" type mod could make use of it without rewriting the same things over and over which I keep seeing.

    I already said how to properly integrate rewards using the arrays, but a register, framework may be better...so I was thinking...the same...elgbot style to be intergrated.

    apart from the files.scr being old I think elgbot was quite gold...there was 1 update someone did to it,..forget what?



    don't forget how files.scr, does it need a per map or so?
    admin pro loaded settings not just per map but per game type too... You just had to turn on per game type or per map...per mod, and create a specifically named settings file...which actually I got asked how to do quite alot so it was useful for many.


    with the GUI stuff I would say don't bother, The way I had, gave you a handle, so people could make their own dynamic menus quite easily. Like the video, I could change one line and make it even more dynamic from the callback script. but still, I would leave this for now, and with the client add lots of URC's and develop ways to use those properly. whack them in a client download. Which would allow people to create much richer, better menus serverside utilising the client pk3. until then...no client pk3? o well, they have to wait.

  4. #4
    Banned
    Join Date
    May 2010
    Location
    fuck off?
    Posts
    1,145

    Default

    actually I don't think mods should have to conform , it just doesnt work,

    framework there if they need to use common things, but otherwise..just drop it in.

    also math.scr should be maths.scr ....end of discussion

  5. #5
    Banned
    Join Date
    May 2010
    Location
    fuck off?
    Posts
    1,145

    Default

    and yes I have been going on about a framework to standardise things since AdminPro was first released, wanting people to use "libraries"...moaning about it for over 10 years I guess? but...now its come to it and I think it should be done in a particular coding style otherwise not mixed up.,
    I don't think it should be over complicated at all, and I don't think it should be "install mod blah" or get settings per whatever like admin pro, just give them the abilities and functions to load their own things if need be.


    no special dirs or installation ways or mod creation defaults, and things to learn,

    just a list of functions that could be useful like strings.scr etc

    settings? fine..

    local.blah = getMySetting "file" "dir" "setting"
    saves, gets

    per map?
    local.blah = getMySettingPerMap "file" "dir" "setting"

    done...


    don't think we need to build a framework...just a list of useful libraries with docs on how to use them.

  6. #6
    Banned
    Join Date
    May 2010
    Location
    fuck off?
    Posts
    1,145

    Default

    as you can seee, still have a lot to say but whatever, I fell out of the discussion before because I feel like I started all this and its heading in weird directions, but still amazing work, just mohaa isnt what it was and new mods need to pop in and use the new stuff, not conform like an emo kid.

    like just loads of register event things as framework , rest as util, library files.

    files.scr, load of libraries and functions on loading, and give people the tutorials on how to use it,

    Clan Match mod thing? its got to be done, a main thing,
    but its a pk3, seperate mod, like a plugin
    same with gun settings,
    elgbot too..

    and it needs to use a lot of the "framework"; gun settings, they call files.scr, strings, cvar even whatever libs...and does its own thing, loaded by events from events.scr or whatever and an /autoload/.scr thing

    the mod for clan, so much potential.... loads to it, loads of events to register, elgbot events, then combined with the guns pk3, it makes it even better, combine it with elgbot.pk3...even better.

    elgbot, stripped..core in a "framework"...then it just hooks the enets...its seperate pk3 which gets callbacks and plays the sounds and stuff.

    elgbot stats? another pk3!...this calls the events...and builds and creates stats.... menus and displays


    all just plug and play mods which without the framework do nothing, but call scripts within it to do a lot.

    less intergrated is actually better..because people have no idea...trust

    now yeah, I moan a lot, and unless I'm requested on chat to explain anything, going to not visit this thread again :P

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

    Default

    Yeah, I was worrying about that; about the framework needing to be used by everyone otherwise all hell breaks loose.
    Indeed, modders do not need to conform.

    Your take on it just needing to be a bunch of libraries with functions that do things is rather refreshing. I was already
    worrying about framework settings and some way for the admins to communicate with it via cvars etc...

    Just a collection of libraries with functions people can use is much more simple and appealing to the user.
    Morpheus Script (MoH) => You try to shoot yourself in the foot only to discover that MorpheusScript already shot your foot for you.

  8. #8
    Administrator JoTo's Avatar
    Join Date
    May 2010
    Location
    www.scapp.net
    Posts
    1,953

    Default

    You 2 should team up and produce admin pro next generation to be honest.

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

    Default

    Sor, we already have Script Libs almost done. I'd drop Weapon Controls or integrated stats etc. and make them as new mods that use our Framework. But I'd still make a support for localStorage and everything else that can be seen as a tool for developer and not a "mod feature". And I think that server-side menus or map control can be considered as a tool.

Posting Permissions

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