• Print

Author Topic: 12/3/06 Meeting Notes  (Read 14 times)

0 Members and 1 Guest are viewing this topic.

Offline Megiddo

  • Ulysses Team Member
  • Hero Member
  • *****
  • Posts: 6214
  • Karma: 394
  • Project Lead
12/3/06 Meeting Notes
« on: December 03, 2006, 05:39:13 pm »
Alright, we covered a lot of information and ideas in our meeting. Here were some of the main ideas:

ULib:
  • For now, make it somewhat simple so we can get to work on ULX right away.
  • Allow compiled modules?
  • Modules:
    • UCL, XML, ULX, etc. Can all be modules. Modules declare what dependencies they have on other modules. Modules that have dependencies can include the version of the module they need. If ULib has a newer one, discards it. If it's the newest, it will move it into the module folder.
    • (Long term goal?) Morph this module system into something similar to our UGet idea. Modules will be stored in an online repository so they can be automatically updated.

UCL:
Surprisingly we didn't talk much about UCL. Does our current idea still stand? (Concept menu explains it all)
  • Expect that the users file will not be edited by hand.
  • On new install, pop up help information to listen server host + the user setup menu. For a ded, have it triggered by a command at the server console. (Lua commands work on ded servers now! Yay!)


ULX:
  • This is the project we should devote the most time to in the coming weeks.
  • Perhaps a better help system is in order? Don't have any ideas though.
« Last Edit: December 03, 2006, 05:59:45 pm by Megiddo »
Experiencing God's grace one day at a time.

Offline spbogie

  • Ulysses Team Member
  • Sr. Member
  • *****
  • Posts: 456
  • Karma: 41
Re: 12/3/06 Meeting Notes
« Reply #1 on: December 03, 2006, 05:45:47 pm »
Possible implementation of script bringing own module versions:

Directory structure
ULib/modules/ <-- installed modules
ULib/tobeinstalled/<name of script>/ <--Module to be installed

ULib searches the sub-folders of tobeinstalled and grabs new modules.
sub-folder with name of script prevents problems of Multiple scripts installed at once overwriting included modules.
I have not failed. I've just found 10,000 ways that won't work. - Thomas A. Edison
I reject your reality and substitute my own. - Adam Savage

Offline Megiddo

  • Ulysses Team Member
  • Hero Member
  • *****
  • Posts: 6214
  • Karma: 394
  • Project Lead
Re: 12/3/06 Meeting Notes
« Reply #2 on: December 03, 2006, 06:06:54 pm »
Full log part 1:
Quote
(@TylerM) hello
(@Megiddo) Howdy and welcome to the team
(@Megiddo) First order of business, do you want us to call you TylerM or Rattlesoft?
(@TylerM) Tylerm
(@TylerM) RattleSoft is my company name, I tend to use it alot
(@JamminR) Tyler, aka R ... ok, answeres my q
(@Megiddo) Alright, anyone got any questions for the new guy?
(@JamminR) How much is he paying us? You did find someone to pay us for our volunteer work, right?
(@JamminR) (joking Tyler, if you couldn't tell)
(@JamminR) :P
(@TylerM) lol
(@spbogie) XD
(@Megiddo) Okay then, we'll skip right on to ULib.
(@TylerM) Yippy!
(@Megiddo) It seems most developers who used ULib in GM9 only used it for the access list (UCL)
(@JamminR) skippy
(@Megiddo) Should we strip ULib down to UCL only?
(@JamminR) I liked your modular idea from discussion I saw
(@Megiddo) Might be more attractive to developers that way since they see as ULib as a deadweight with all those unused functions
(@JamminR) UCL only, with some way to add more functions (not just scripts like ULX)
(@TylerM) Doesn't ULX utilize ULib heavily?
(@Megiddo) It did, but a lot of what ULib did is now handled natively in GM10
(@TylerM) I really don't see much of a point to ULib.
(@TylerM) Except for some base features
(@JamminR) which is why we're here, most of us questioned too :)
(@spbogie) Maybe we make ULib as just a central piller and expand it with additional libraries (like UCL)
(@Megiddo) Having too many separate things to install makes for a nightmare technical support
(@JamminR) *nods*
(@TylerM) Windows installer
(@TylerM) Why not use a simple executable installer for mods
(@Megiddo) Yes, I was thinking that too TylerM, it catch the newbs who don't read the readme.
(@Megiddo) it would*
(@TylerM) I'm a wiz with VB.NET
(@TylerM) and installers
(@Megiddo) NSIS would probably be best, only takes a few line of code
(@TylerM) Yes
(@TylerM) Or Inno
(@TylerM) Uses python? I think
(@JamminR) NSIS = NullSoft?
(@TylerM) Yes
(@Megiddo) Alright, so if we stripped ULib down to just UCL... how would that work?
(@TylerM) On a suggestion note, I think an easy way to handle VGUI. Something to simplify the process
(@Megiddo) Have ULib "modules"?
(@TylerM) Yep
(@JamminR) base.lua + ucl.lua + defines ... then have rest somehow modularized
(@spbogie) That's kindof what I was saying.
(@Megiddo) The module idea JamminR was referring to was dynamic loading and unloading inside a game... but it seems too much work for too little use to me.
(@TylerM) Overall, I think we should spend our time in ULX. It's our bread and butter.
(@Megiddo) Agreed TylerM
(@JamminR) ah ok. still, what spbogie says
(@Megiddo) Also, an idea that just struck me, if we compiled our modules, they'd run a lot faster and only be one file (I think?).
(@Megiddo) Of course, we'd still provide the source in another package
(@Megiddo) But might tidy things up
(@JamminR) how much overhead is spent on server startup/client execute, compiling it in memory thought?
(@JamminR) lua does that anyway, doesn't it?
(@JamminR) gm10 implimentation of lua that is
(@Megiddo) Yes, as far as I remember
(@Megiddo) Well... maybe not
(@Megiddo) I remember playing around with it in GM9 and it still had all the comments in what was loaded
(@TylerM) Will we still continue to provide updates for Garry's Mod 9, I think not
(@Megiddo) Yes, TylerM, especially if we find most users still use GM9
(@JamminR) Meg and I have discussed that before
(@Megiddo) It'll be hard maintaining them in parallel since they'll be so different though
(@TylerM) Although Garry's Mod 9 will never be updated again and Garry even said it was only around as a demo for people who weren't sure if they wanted GM10
(@JamminR) still amazes me the amount of people asking, who don't have gm10, 'won't this work in gm10?' or "can't I just copy the lua/mods straight over'
(@JamminR) even though its been said in various locations hundreds of time, NO
(@TylerM) An idea struck me, I don't know if it was mentioned before, but what about XML support? Being able to save and load XML data would be excellent
(@Megiddo) If we went with the module idea, we'd need to find a way so individual scripts could include the modules with them, and ULib would handle loading of newest one, and being backwards compatible
(@Megiddo) Any ideas for applications of XML TylerM?
(@TylerM) Well
(@TylerM) Let's say we do all configurations and user data in XML. I could write a very simple configuration EXE so "noobs" could setup everything without loading Garry's Mod
(@TylerM) If XML was supported in ULib, users could make easier website stats
(@TylerM) Even though mySQL is already supported, XML is a very good solution.
(@Megiddo) Perfect idea for a module. ;)
(@JamminR) mmm, server stats
(@Megiddo) With the modules, how would we handle having scripts that use it include their own copy? Is their a simpler solution that wouldn't require "dependency "?
(@JamminR) bans/max/min/minge's autokicked/folks who didn't have map, and on and on
(@spbogie) Modules could register themselvs with ULib giving a name and version
(@Megiddo) We also have to keep in mind backwards compatibility. As hard as we tried in ULib 1.*, it just wasn't possible using traditional methods.
(@spbogie) ex. ULib.register("ULX", 2.9)
(@Megiddo) spbogie, how about if they declared their own ULib "class" in their init, then made all calls with ULib:doSomething()?
(@Megiddo) Ah, I was talking about scripts that use modules, never mind
(@spbogie) ?
(@Megiddo) Well I like your idea for modules
(@Megiddo) Er... well, I guess we could consider ULX a module too
(@Megiddo) Never thought of it that way
(@spbogie) It was just a example name
(@Megiddo) Was thinking of libraries as modules, XML, MySQL, etc
(@spbogie) That's what I was thinking, just ulx was first thing that poped in
(@Megiddo) Still, having anything that uses ULib be a module is an intriguing idea
(@TylerM) In a purely PR sense, how big is our ULib user base?
(@TylerM) Developer wise
(@JamminR) that is a good question
(@Megiddo) Anyone have any ideas on how we can make it so we can include any dependencies with ULX and not have them download them all separately? IE, if we use XML. But, at the same time, we have to make sure that only the newest module is used if there's multiple copies
(@Megiddo) I'd say maybe 5 who have actually used it. ;)
(@JamminR) can we have ULX check for updates
(@Megiddo) That would have to be done in C++
(@Megiddo) But yes we could
(@spbogie) I think the biggest complaint about ULib right now is that it is too bloated
(@Megiddo) I already have such a system coded from my UGet snippets
(@JamminR) I figured it would
(@JamminR) and figured you did
(@JamminR) :P
(@JamminR) How much bandwidth would be added with every server start that uses ULX checking for latest though?
(@Megiddo) I agree with you spbogie. Think the module idea would fix that complaint?
(@Megiddo) JamminR: Depends on how it's checking, if it's just reading a text file, next to no bandwidth.
(@JamminR) k
(@spbogie) I'de immagine less bandwidth as an rss feed
(@spbogie) However some people like to modify ULX so the autoupdate would need to be disableable
(@Megiddo) No one has further ideas on the module system? Anyone know of programs that does something similar we could use as an example?
(@spbogie) If we make modules register themselves with ULib then we could perhapse make it work
(@spbogie) However it brings the question of what is the reason for it being a module to ULib rather than stand alone?
(@JamminR) UCL reliance
(@Megiddo) If it needs UCL or another module
(@spbogie) Then how do we control order modules load?
(@spbogie) perhapse a ULib.require(<list of modules>) function?
(@spbogie) I see no reason for XML to require a UCL
(@Megiddo) If one module requires another, run it. Shouldn't be a case where two modules are dependent on eachother. (Desperately hope so anyways)
(@Megiddo) But ULX might require XML, or another script
(@TylerM) XML shouldn't be an optional module. It should be built in
(@Megiddo) And instead of having lots of copies of the module, only needs one
(@TylerM) Non-removable
(@spbogie) And that tyler is where the debate comes in
(@Megiddo) This system might scare away other developer though
(@spbogie) What should be a module then?
(@Megiddo) Personally, if we were to use this system, I'd make "ULib" _only_ the module handling system
(@Megiddo) And UCL, XML would be modules
(@spbogie) Which is what I suggested a while back
(@Megiddo) But perhaps spbogie is right that this is too complicated. Would it scare away developers or attract them?
(@spbogie) Perhapse a C++ backing that copies the newest version of a module to a ULib/modules folder, and delets old ones
(@Megiddo) Why would it need to be in C++?
(@spbogie) Because lua can't do files in lua directory
(@TylerM) As a suggestion, we may be able to make a socket library (simple library, nothing too fancy) and have a built in function that can check for updates to modules, etc
(@Megiddo) Oh that's right
(@Megiddo) TylerM: Is there a point in that if we could find a way to just allow scripts using the module to include whatever version they need? (Even if it's older than latest and we can simply use the newest)
(@JamminR) hmm
(@JamminR) and hope modules don't change much
(@TylerM) I really don't see a need to do backward compatibality. If we make changes, they should be required. That way the people always get the latest
(@TylerM) Plus, most of the time, anything we update won't be hard for the developer to update.
(@Megiddo) Oh true, bug fixing and such
(@spbogie) I was thinking perhapse a way of a script specifying what it needs from ulib, and if it isn
(@Megiddo) Such a system was one of UGM's many downfalls, but it was poorly implemented, so perhaps it will work if we do it right.
(@spbogie) oops bumped enter
(@spbogie) and if it isn't installed it is pulled from a specified folder that is included with the script
(@Megiddo) But TylerM has a good point that we'd want them to have the very latest for bug fixing, loopholes, etc
(@Megiddo) But might be way out of scope for this project
(@TylerM) Exactly, that way they can't come and complain
(@spbogie) Which is why it wouldn't pull the included one if there was a newer one already installed
(@TylerM) that they got an error. It saves us from saying over and over "That bug was fixed in our latest release"
(@spbogie) Could we posibly do a modules repository, and have it grab whatever is needed?
(@TylerM) ((Note, Moegiddo, in #ulysses, this is exactly why we need an installer :P
(@Megiddo) Yes spbogie
(@TylerM) Megiddo*
(@Megiddo) It's similar to our UGet project actually
(@spbogie) However what about third party modules?
(@Megiddo) An excellent question no one has an answer too ;)
(@JamminR) there was some discussion of having Ulysses host a dev repository, where devs had to register/send files, etc
(@JamminR) but, thats all it was as far as I know, discussion
(@Megiddo) Yes, on that topic, if we were going to allow third party modules we might as well bring that project back
(@Megiddo) But it makes things much more complicated
• @TylerM thinks about security and virus issues...
(@Megiddo) Don't have clients automatically download everything from repository, only what scripts need or what they manually get. Other than that, just hope we catch anything.
(@JamminR) dev has to register with valid email, all changes tracked, all ips
(@JamminR) full time job though, monitoring emails "so-n-so is a virus!!'
(@TylerM) IntelliSense for LUA
(@JamminR) hehe
(@TylerM) A way to check for "common" lua virus tactics
(@TylerM) Or spam tactics
(@spbogie) How long will this take to put together though?
(@Megiddo) Perhaps we're getting ahead of ourselves here though. As much as I love this idea, if we were to do it, it should be open to all content, not just modules.
(@JamminR) we are
(@Megiddo) I think we should just use our "include any version with it" idea for now
(@Megiddo) See if it catches on
(@spbogie) Is there a way to get the directory of the currently running script?
(@JamminR) ULIB -- module loader, UCL, def a default module, XML too? (configs of new UCL, etc)
(@TylerM) Yes I agree, alot of this is out of bounds at the moment. I think our highest priority is ULX, not ULib. I doubt people will really want to use ULib, unless it simplifys tasks
(@Megiddo) Yes if you have a variable or function from the script spbogie
(@Megiddo) debug.info( function )
(@Megiddo) Maybe it's just for functions
(@Megiddo) It returns a table with information, one of which is what file it's in
(@Megiddo) Off-topice: You can also use the debug library to get local variables outside it's scope. :)
(@Megiddo) topic*
(@Megiddo) Where were you going with that idea spbogie?
(@spbogie) Well I was thinking of some way for a script to specify what it needed from ULib, and then have ULib check it's dierctory for the required script.
(@TylerM) Where did we end up going with XML?
(@Megiddo) Or could just stick all the modules it needs in a standard folder (Ie: ulx/modules). On first run, ULib reads folder and copies modules into main directory as necessary
(@spbogie) And again ULib would then check the version of the included scrip against any installed versions, and if it was the most reacent it would move it to the ULib/modules folder
(@Megiddo) Hehe, great minds think alike spbogie ;)
(@Megiddo) TylerM: Fits well as a module, at least that's what me and spbogie think
(@TylerM) On an installer note for modules, when you install ULX or ULib, it will check if it has any required modules before hand and can download them via NSIS
(@spbogie) The common folder for to be installed modules brings the problem though if two scripts are installed at once, and one overwrites the modules of the other with an older version
(@JamminR) spbogie, restart would fix that, if Ulib checks every start
(@JamminR) might error first run of course
(@spbogie) Ok, let me give a better example.
(@spbogie) You install a PropProtector, and a AdminMod at the same time. both include the same module, but one has a newer version. You however install that one first, and the new version gets overwritten by the old one.
(@spbogie) Not talking a online reopsitory
(@JamminR) but we're talking Ulib goes looking for latest at start up, a simple C++ call, right?
(@Megiddo) Have the version on the filename of the module, or have a text file to go along with each module with the information
(@TylerM) Megiddo - I was about to say the same thing
(@Megiddo) Depends on implementation JamminR. Where will we keep the version information? If it's inside the script it would have to be loaded to see what version it is
(@spbogie) The version could be formated specaily at the top of the script as a comment
(@JamminR) Filename I guess then, keeping extra txt files would be more of a pain
(@Megiddo) spbogie: If it's compiled... ;)
(@JamminR) modulename_date_time.lua
(@JamminR) or UTC code, etc
(@JamminR) but that gets complicated, expecting Devs to not static reference the file, instead of using a function that would auto
(@JamminR) autoload latest
(@spbogie) Would we be compiling the modules?
Experiencing God's grace one day at a time.

Offline Megiddo

  • Ulysses Team Member
  • Hero Member
  • *****
  • Posts: 6214
  • Karma: 394
  • Project Lead
Re: 12/3/06 Meeting Notes
« Reply #3 on: December 03, 2006, 06:07:07 pm »
Full log part 2:
Quote
(@Megiddo) Think it's good to allow the option
(@spbogie) Ok, stupid question, how does lua compiling work?
(@TylerM) Here is a quick XML write up of what we could do with users.txt in XML format though: www.rattlesoft.net/users.xml
(@Megiddo) Makes it impossible to edit by hand, but our current idea for access was anyways
(@TylerM) With XML, I can write up a simple tool to do the work, like the access generator
(@TylerM) The nice part is that developers would love the possibilites with XML and custom user data.
(@Megiddo) spbogie: http://luadec.luaforge.net/ has some good information on how it's compiled
(@TylerM) It takes Garry's Mod 10 users.txt grouping options to a new level
(@Megiddo) TylerM: You can read up on what me and JamminR thought up for the new access control here: /index.php/topic,565.0.html
(@spbogie) Hmm, well as far as storing the version in the names go, we could have to come up with some type of naming convention, and impress it on developers.
(@Megiddo) Wait!
(@Megiddo) We could do it without outside information, even if compiled
(@Megiddo) Have them check what ULib returns from the registration
(@Megiddo) If false, return and end execution
(@Megiddo) if not ULib.Register( "XMLLib", 2.0 ) then return end
(@Megiddo) ULib would return false if it has a newer one or same version
(@spbogie) Is there a way for ULib to stop the execution on it's own?
(@Megiddo) You'd think there would be since it's just right above on the function stack... let me check the debug library
(@TylerM) Simple, just make developers save modules like so: folder name = XMLLib_2-0
(@JamminR) they shouldn't have to 'save' it, they'd grab the module from our site/repository, wherever first, wouldn't they?
(@TylerM) Yes
(@TylerM) If we do a repository, we could just make the modules be properly formated
(@spbogie) JamminR: we're not talking about the online repository right now
(@JamminR) bogie, i know
(@JamminR) but they'd have to get the modules somewhere/how
(@JamminR) so, they download ULib
(@spbogie) We're talking about a way for script to include versions of the modules they require.
(@JamminR) or are you talking modules _they_ write
(@JamminR) right
(@JamminR) they'd have to have some base modules to work with, 'we' name those modules...then the only problem is having the devs register/check for version properly
(@JamminR) we wouldn't have to worry about naming
(@JamminR) er, they
(@spbogie) The question with naming was to do with 3rd party modules
(@JamminR) sorry, thought it was with 3rd party relying on ours
(@Megiddo) Still think using that simple function call would be the easiest
(@Megiddo) Then they can name whatever they want
(@spbogie) I just had an idea.
(@JamminR) *sees bright light*
(@spbogie) What if they create the module in a local table.
(@spbogie) then pass that table to ULib.register
(@spbogie) and ULib then places that table in ULib.<name of module>
(@spbogie) It could then include a init function for anything that needed to be run right away
(@Megiddo) Easy to do with the module() command, it's how garry does all those modules in GM10
(@spbogie) and the module does no handeling of whether it is an old version or not
(@Megiddo) What if it uses hooks
(@Megiddo) Or commands
(@spbogie) those would go in the init
(@spbogie) I'll write a quick example and put it on a pastebin
(@spbogie) What's a good pastebin with lua highlighting?
(@Megiddo) Seems they all have it
(@JamminR) dev ide? Context?
(@Megiddo) Pastebin, site you can paste it to and have it highlight correctly
(@JamminR) ah
(@spbogie) Slow pastebin
(@spbogie) http://www.donotpaste.com/488
(@spbogie) Perhapse the variable scope may be a problem though
(@Megiddo) Would using "if not ULib.register( ... ) then return end" at the top of the file be a lot easier?
(@Megiddo) Wouldn't*
(@spbogie) Does return end processing of the file?
(@Megiddo) Yes
(@spbogie) Well I guess. I was trying to take it more off the developer as far as making sure nothing eles was run, but I guess my idea didn't do that much better
(@Megiddo) Your idea lets us grab all their hooks though...
(@Megiddo) Unless they hook stuff somewhere else too
(@Megiddo) Hmm
(@Megiddo) I don't see any real reason for dynamic loading/unloading though
(@Megiddo) Not when changing levels is so easy
(@spbogie) The only reason would be if you wanted to load a new version of the module without restarting
(@spbogie) That brings up a point.
(@spbogie) What happens if another script has a newer version of the module, but the module is already loaded.
(@Megiddo) Only would happen if they install two at the same time
(@Megiddo) We could take the same approach I took with ULib 1.0 to do force download
(@Megiddo) You just restart the map real quick
(@Megiddo) People connected don't even notice
(@spbogie) It would happen whenever a script with a new version is loaded after one that was previously installed
(@Megiddo) Ah, true
(@Megiddo) Still, a pretty rare occurence. I see no problem in just restarting map.
(@Megiddo) Do you TylerM?
(@TylerM) Nope
(@spbogie) Unless we have all new modules placed in a specific folder, and have them checked on startup
(@spbogie) then the only problem is loading after startup
     —›12 quit: (12JamminR)12 (12~sum1spcl@c-68-47-170-190.hsd1.tn.comcast.net)12 (12Quit: http://jamminr.no-ip.com/ - We're not alone)12
(@Megiddo) Just don't allow dynamic loads? :P
(@Megiddo) Anyways, let's stick ULib on the backburner for now. We need to discuss the UCL
(@Megiddo) Do you understand what we were thinking of doing TylerM?
(@Megiddo) Even though that thread doesn't really explain how we were going to implement it
(@spbogie) I'm going to make a quick log of everything so far.
(@Megiddo) spbogie: /index.php/topic,578.0.html , let me know if I missed anything ;)
(@Megiddo) Or edit it
(@Megiddo) Yah just edit it yourself
(@spbogie) Ok the stupid java applet won't let me select the text, Can one of you save the conversation sofar
(@Megiddo) spbogie: I will when we're done and include it in that thread
(@Megiddo) Sound good?
(@Megiddo) So TylerM, still with us?
(@spbogie) k
• @TylerM wakes up
(@TylerM) uhh yep
(@Megiddo) We'll call it a day after we touch on UCL
(@TylerM) Okay
(@Megiddo) Do you understand our plans?
• @Megiddo prods TylerM
(@TylerM) lol Yes
(@TylerM) I think so
(@Megiddo) Comment/Questions?
(@TylerM) None yet
(@Megiddo) Ideas for implementation?
(@TylerM) Except what is UCL used for anyways
(@Megiddo) It's the access system
(@Megiddo) Ulysses Control List
• @TylerM scrolls up log for details...
(@Megiddo) It's that thread I told you to look at with the funky colored menu
(@TylerM) Oh Yes
(@TylerM) Okay
(@TylerM) Lets continue
(@Megiddo) Ideas for implementation?
(@TylerM) Implementation? As in our issues with modules and third parties?
(@Megiddo) I was thinking similar to how we have it now but instead of the flags use a key character followed by information.. "+ulx kick" would mean they're allowed to use ulx kick, "-ulx ban" denies ulx ban, "@superamin" means they're in the superadmin group.
(@Megiddo) Nah, I mean how we'll save and process the data
(@TylerM) Okay
(@Megiddo) The way I'm suggesting will produce some pretty long lines in the config if they're allowed and denied a lot of stuff
(@Megiddo) But, we're not really expecting them to edit by hand are we?
(@TylerM) Nope
(@Megiddo) On a listen server the host will be given full access automatically
(@Megiddo) On a dedicated... we could have a "setup" command that issues full access to whoever uses it. Sorta dangerous, just make it clear they should be the only one in server, maybe even pass the server.
(@TylerM) I think instead of invidual access levels, we do group levels
(@TylerM) Much simpler
(@Megiddo) Yep, that's in the idea
(@Megiddo) We have three "core" groups: operator, admin, superadmin
(@TylerM) Yes
(@TylerM) Ever looked into mani's method of permissions?
(@Megiddo) The core groups are to assign default access for newly installed scripts, and superadmin gets full access and is the only one who can access that menu I showed you
(@Megiddo) No, I know it used to be similar to AMXX, but I heard it changed
(@TylerM) Basically 2 main admin files: admin groups and admin users
(@spbogie) I think the setup command may be too dangerous
(@TylerM) Admin Groups text file contains all the permissions, similar to what ULX uses for each user
(@spbogie) perhapse make it something you need to run from DS console
(@TylerM) And then the admin list contains the steam id and then the group
(@Megiddo) So besides the core groups, there would be an "immunity" group. Superadmins can bypass immunity for any user. Extra groups can be added by scripts if they want them. (IE: Full prop access group for prop protector)
(@Megiddo) TylerM: Similar to how we're doing it, but we're allowing per-user access changes too
(@Megiddo) spbogie: That's a great idea! I'm too used to lua commands not working on ded servers. ;)
(@TylerM) DS Console: I do dislike the fact in ULX currently, you can't run ULX commands on players.
(@Megiddo) Well it was a GM9 limitation
(@Megiddo) Should work in GM10
(@TylerM) LOL.. I still haven't added ULX to my dedicated server yet
(@Megiddo) Yep, works. Just tested it.
(@spbogie) GM10 DS console accepts lua CONCOMMANDS ?!?!?! YAY!!
(@Megiddo) Yah, bout time huh?
(@spbogie) I had to write a function to call them the type lua cc "ulx slap"
(@TylerM) Please tell me we're going back to ulx_slap instead of "ulx slap"
(@spbogie) I like spaces
(@TylerM) :(
(@Megiddo) I like spaces too
(@Megiddo) Easier to type
(@spbogie) Perhapse a way to specify the seperator?
(@Megiddo) Plus you can have "ulx" trigger some help message
(@TylerM) Or do a vote on forums?
(@Megiddo) Hmm good idea
(@spbogie) which?
(@Megiddo) A vote
(@Megiddo) Specifying the separator would be pretty difficult
(@TylerM) Yes
(@TylerM) The best idea is to just let the people decide
(@spbogie) Or just a bool for space or underscore
(@spbogie) heck we could do both
(@Megiddo) Kinda what I did with ULX 2.0
(@Megiddo) It would pick up "ulx_" and tell you it changed
(@Megiddo) Hey, guess we could easily do both that way
(@Megiddo) Hook into the unknown command function
(@Megiddo) Alright, anything else we need to talk about before we adjourn?
(@Megiddo) I want to add that I'm going to be working on a prop protector tonight to warm me up to GM10 coding
(@Megiddo) Simple, easy, popular. ;)
(@TylerM) Im good
(@Megiddo) You got anything else spbogie?
(@spbogie) Not much
(@spbogie) well nothing at all
(@Megiddo) Alright, if you have anything more to add, put it on the thread: /index.php/topic,578.0.html#msg2484 (Please let me know if I'm missing anything too)
(@spbogie) just a few ideas on how to actually write some stuff
(@TylerM) Good night guys
(@Megiddo) Ah, will you put them on the thread?
(@TylerM) Ill be on AIM if you need me
(@spbogie) Cya Tyler
(@Megiddo) Alright, see yah TylerM. Thanks again, and welcome to our team.
(@TylerM) Thank you
(@TylerM) Can't wait to add some next gen stuff to ULX/ULib
(@Megiddo) :)
(@spbogie) It's really not a compleat thought right now so...
     —›12 quit: (12TylerM)12 (12RattleSoft@82-241-58-66.gci.net)12 (12Quit)12
(@spbogie) If I come up with anything I'll post it
(@spbogie) Cya
(@Megiddo) bye
Experiencing God's grace one day at a time.

  • Print