• Content count

  • Joined

  • Last visited

  • Days Won


Kered13 last won the day on February 18 2016

Kered13 had the most liked content!

About Kered13

  • Rank
    Advanced Member
  • Birthday 12/08/1989

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

688 profile views
  1. Xonotic did that. I think it had like 3 different explosive weapons, all with different properties.
  2. Adding options is pretty straightforward, just look at some other widgets for examples. The basic structure is that you define variables for your user options in self.userData inside your widget's inititalize function. In your drawOptions function you draw the options screen using the functions from the reflexcore library, which do thinks like drawing checkboxes, edit boxes, drop downs, sliders, etc. Each of these functions will take a current value and return a new value. Save the new value to self.userData and then call a function to save the new userData.
  3. Hey this widget looks a little familiar The code is familiar too (For the record, I don't mind)
  4. Looking at the host match code, it looks like it's supposed to remember your last bot settings. However there is a bug if Steam integration is enabled. The code to draw the host match menu checks to see if the selected map has navigation data, but workshop maps are not loaded until you open the map selection window. Since there is no map data loaded, it thinks that there is no navigation data and resets the bot data to empty, which also clobbers your saved bot data. To answer the larger question, yes a widget like this is possible. The console variables "ui_menu_startbot1" to "ui_menu_startbot8" contains the bot data stored as a string. A widget can easily read or write to these values to change the bot settings. You can also get the bot information during a match from the botSkill field of a player table.
  5. These are some useful global objects and functions: world: Contains a lot of useful data on the state of the game such as game mode, timer, item timers (if enabled), team data, etc. players: Contains the data for all the players connected to the server. getPlayer: Returns the player object for the player that is currently being played or observed. getLocalPlayer(): Returns the player object for the client's player. deltaTimeRaw: The time (in seconds) since the last frame. Useful mostly for animations. gamemodes: Contains information on the different game modes, such as the mode name and is a team mode. widgets: Contains the names and some information for all the loaded widgets. You can iterate over this to get widget names and use _G[widgetName] to get the object for that widget ("_G" is the global object in Lua). Note that at least the world and players objects are new objects on each frame (so if you say "foo = world" then inspect foo on a later frame, it will not have changed). It can also be good to check existing scripts in the workshop and these forums. I'm not sure what you mean by the first part. If you have a MyWidget:Foo() function defined, you can call it from anywhere in the file that defines it or any other file that transitively requires the file that defines it. MyWidget:initialize() and MyWidget:draw() are the typical entry points to your code, but not the only possible ones. The second part is just standard Lua. A function definition that starts like MyWidget:foo() is syntactic sugar for, and calling MyWidget:foo() is syntactic sugar for calling You could if you wanted (but please don't actually do this) define your function as, use "this" instead of "self" inside the function, and call it like MyWidget:foo() and it would work. You can also call and now "self" inside the function foo will be SomeOtherWidget (this is useful for implementing a sort of pseudo-inheritance, where SomeOtherWidget is a subclass of MyWidget). Lastly, the formatting on these forums is still a steaming pile of shit, and whoever is maintaining the forums needs to go back to standard BBCode. I literally had to edit this post five times to make the last two paragraphs not get lumped into the last quote. I would rather use plaintext with no formatting at all than this piece of shit formatting system (but of course, even that is not possible).
  6. KeredVolume This is pretty simple, but I find myself changing s_volume often, usually to balance it with music in the background, or to turn it off when Reflex is minimized, so I put this together. You can bind keys to volume up, down, and mute, and it provides an on-screen display like a TV. I also tried to make the sound curve smooth, so it doesn't just change in constant increment of s_volume (it actually uses an exponential curve). The link above is to the addon on the Steam Workshop, you'll also need my OptionsGadgets and Utils addons (linked in the workshop description). The source code is also available on my BitBucket.
  7. I have uploaded this widget as an addon. You need to download the Utils and OptionsGadgets addons separately (linked in the description). I've uploaded most of my other widgets as addons as well.
  8. Can addons have dependencies on other addons? I'm thinking in particular about shared Lua libraries. I have a bunch of widgets and a couple libraries that they all share. Making all my widgets into a single addon would be inconvenient for someone who only wants one or two. Copying the library for each widget is cumbersome to maintain (making sure all widgets have the same library version). Ideally I could make my libraries an addon and each of my widgets an addon that depends on the libraries, then users would just need to download the libraries and the widgets that they want. Also, how does updating addons work? Do you manually upload it for each update? Do users receive the updated addons automatically or do they have to redownload them?
  9. Because when I make changes to it (and I will) I would have to make a new pak file and post it or leave people with an out of date download. It's easier to provide a link that will always be up to date. It's not hard to download the repository and copy the important files to your reflex folder.
  10. This is a system for chat binds, inspired the VGS system in Tribes and the voice menus in TF2. Sadly an actual voice system isn't possible, but chat binds are still pretty nice. Basically instead of just having keys bound to chat commands, you can create menus containing more chat binds and submenus. When you press the bind for a menu in-game, you'll see a menu open up on screen showing you the chats and submenus it contains, as well as their binds. This system allows you to have a large number of chat binds for many different purposes (for example, calling out item spawns in team games, or griefing chat) without requiring your entire keyboard. Download the files here. You will need KeredVgs as well as the Utils and OptionsGadgets folders. Make sure you preserve the folder structure when you copy them. This is a bit of a beta release, as I'm about to go on vacation for a week and I want to get this out before I leave. It should be completely functional, but if you encounter any issues please report them in this thread and I'll try to fix them when I get back. I'd also like to eventually add a default menu to serve as an example, but I think you guys can figure it out. One shortcoming is that whenever a menu is closed it's keys are left unbound, so don't use any important keys like movement in your menus. I'd like to fix this but I haven't found a good solution yet. Let me know what you think, and any bugs or feature requests.
  11. I'm working on a script that needs to temporarily rebind keys. I want to restore the previous bind afterwards. To do this I need to find out what command is currently bound to a key so I can save it. (If you're curious, the script is a VGS-style chat menu.) Typing "bind <key>" in the console manually displays the command, but consolePerformCommand() doesn't return anything, even when the command print output. consoleGetVariable() doesn't work on binds. bindReverseLookup() tells you what key is bound to a given command, which is the opposite of what I want. Iterating over all built in commands is possible, but clunky and won't cover other custom commands the player might have. I fear this may not be possible, but does anyone else know?
  12. No, damage stats aren't available until the match has started.
  13. Yeah, there's a good chance I might do something like a VGS system soon. I do like the idea, it's just in competition with my laziness. Also, because I'm always overambitious I would probably try to find a way to make the nested menus customizable, which is probably a lot of work.
  14. Needs more shazbot. Speaking of which, a keyboard-based interface would probably be easier to use and wouldn't have to replace the scoreboard.
  15. Alright, I've fixed that bug. Redownload the widget from the link in the OP (you only need to update the widget itself) and it should work. Thanks both of you for the bug report.