Jump to content

Agent

Former Developers
  • Posts

    1271
  • Joined

  • Last visited

Posts posted by Agent

  1. That's not a horrible solution, but it would require adding this information to the server list (or adding some entirely new mechanism), and would require transferring a ton of data (several GB) if someone were running a custom maps server with many custom maps. Similar to writing an entirely separate in-game transfer system, this would likely require a substantial amount of code, but would certainly be possible.

    I do plan to go back to looking at this, once I've finished up some web interface stuff for the ladder; lately, I've been working on some general improvements (i.e: cleaner tokenization) on Jupiter (Stats bot), which may ultimately end up powering the web interface to the ladder as well.

    Edit: oh look you updated your post, and I'm apparently very slow at typing responses.

    Pretty much every stupid setting has been toyed with, and nobody has found something that really fixes the issue though. You're more than free to mess with these, and if you find a solution (especially with Engine.ChannelDownload's slow speed), feel free to post about it. GameName should have little to no impact, though.

  2. Writing it into the launcher is very, very far from the "best solution". For example, when maps change mid-game, you would still get removed from the game, and users would be left sitting there thinking "wtf just happened?". A player would then have to close their game and try rejoining that server, or just join another server.

    That said, some sort of map repository accessible via the launcher wouldn't be bad to let people try out new maps, and allow mappers to submit content to the repository. This is an entirely different feature than auto-download, though -- this is essentially just a file browser.

    The "best" solution would be find a fix for the issue (which seems elusive), or to write a separate system entirely, but I'm not entirely sure how practical/possible such a thing would be. In the mean time, my only real suggestions are to limit map file size, or occasionally push well-made fan maps via patches.

  3. This issue has been thoroughly looked into by multiple people, and no solution has been found. Auto-download is a UDK feature, and is written in entirely native code, so there's no way we can modify or even really look at the faulty code. This essentially leaves 3 options:

    1) Keep messing with client/server config settings, until someone discovers something that works (no solution yet found).

    2) Write an entirely separate system from scratch to automatically transfer files (that's a decent bit of work).

    3) Keep using the system as-is (buggy).

  4. Updated! Add RenX.Ladder to the plugins list to enable a server-specific ladder. The ladder is currently only interacted with by chat commands; a web interface should be coming before too long.

  5. also, a little request. Can you add a registry value that stores the installation path? This will help out on custom map pack installer

    Is the "RenXPath" variable in "HKEY_CURRENT_USER\Software\Totem Arts\" not a thing anymore? It's in my registry, but it could be from an old install ("InstalledVersion" in my registry still says "Open Beta 4", after all), so can someone please confirm/deny this?

  6. I'm not really a fan of spawn delays; being able to quickly react to beacon placements or rushes, without a feeling of complete and utter hopelessness is actually rather nice, and keeps me further engaged in the game.

    ...I also thoroughly enjoy going in as a kamikaze engineer.

  7. Seems redundant to have multiple systems that do the exact same thing stickied, especially when their feature sets are extremely similar. That said, if i ever get around to updating the "Administration Systems" thread, this will definitely get a mention. A number of threads in this forum need updating, actually.

    It'd also be neat to see some unique features, maybe like TeamSpeak logging or something.

  8. It's currently sorted by total_score, just like the previous leaderboard (and every other Renegade ladder I've ever seen), and is already loaded onto the stats bot for testing. There may or may not be database resets, as testing and additions progress.

    To view your rank in-game, type ".ladder" in team or public chat. The web interfaces haven't been started on yet at all, so that will come later. Assuming nothing else gains priority on my to-do list, I should be starting on a web interface before too long.

    Possible future features:

    * (Time consuming) Detailed web interface

    * (Easy/quick, if above is implemented first) Data retrieval interface for server owners

    * (Easy/quick) All-time/Yearly/Monthly/Weekly/Daily leaderboards.

    * (Unknown/Low priority) Detailed in-game interface (pause menu? Load web interface as webpage?)

    * (Easy/moderate time/Low priority) Player-configurable bitfield to determine a player's ".ladder" output.

    * (Time consuming) Networking capabilities to share ladder data (and other data) between multiple Jupiter bots (likely a hub/leaf structure), to enable non-global multi-server implementations, as well as better network load distribution.

  9. You should also be able to make your own gamemode, though I haven't tested if this automatically transfers from server to client (it should, though). Just extend Rx_Game, and your server command line could be something like:

    start Binaries\Win32\UDK.exe server CNC-Field?game=Thundernerd.TS_Game

    This assumes a package named "Thundernerd" contains a class named "TS_Game" extending Rx_Game.

    Alternatively, make a mutator using the aforementioned tutorials.

  10. Thanks very much for the feedback. To clarify, this is just trying to figure out the default output for the "ladder" command -- nothing to really do with join messages, nor recommendations, nor team balancing. I'm also trying to figure out if there's any other data what-so-ever that should be tracked (it's better if have a little extra, than not enough).

    The current format again, generates this example: #1: "Jessica!" - Score: 69463 - Kills: 4 - Deaths: 3 - KDR: 1.33 - SPM: 18.41

    I'm wanting to avoid adding a ton of commands, so I'll probably change the ladder command's input from "ladder [rank|name]" to "ladder [rank|name] [var]" eventually; thanks for the suggestion! It would technically be possible to add some sort of bitfield to entries, to determine logging output, so you could toggle what stats you want displayed about you in-game. If/when I eventually deploy this globally, it'll likely use '.' instead of '!' as the command prefix, to prevent conflicts with other server-specific systems.

    As far as more data: I may add total_gdi_game_time, total_nod_game_time, top_gdi_game_time, and top_nod_game_time, as well as other gdi/nod variables.

    As far as command output format: I'm thinking Vehicle Kills and Building Kills would be nice additions.

    As far as commands implemented:

    [COMPLETED] ladder [rank|name]

    [PLANNED] top5

    [PLANNED] ladder [rank|name] [var]

    As far as access by server owners: I plan to eventually add an web interface with this, run on the stats bot itself. So there'll probably be some sort of easy-to-parse URL for server owners like "ladder.renegade-x.com/data?steamid=00000000&vars=total_score%2Ctotal_kills%2Ctotal_game_time", or perhaps some other mechanism.

    Thanks for the suggestions and feedback!

  11. One of my current projects is a bot-side ladder system, which can be deployed on a per-server basis, as well as potentially (probably) globally. This system is more-or-less done with its initial testing phase, and should be committed to my GitHub before too long.

    This ladder collects and maintains a lot of player stats as well -- everything from total score, to GDI wins, to game-time, to the most kills/deaths a player has had. It requires users to be using Steam in order to be added to the ladder, and updates on GameOver.

    More specifically, here's the data stored in each entry (so far):

    uint64_t steam_id, total_score;
    
    uint32_t total_kills, total_deaths, total_headshot_kills, total_vehicle_kills, total_building_kills, total_defence_kills, total_captures, total_game_time, total_games, total_gdi_games, total_nod_games, total_wins, total_gdi_wins, total_nod_wins, total_beacon_placements, total_beacon_disarms, total_proxy_placements, total_proxy_disarms, // totals (15)
    
    top_score, top_kills, most_deaths, top_headshot_kills, top_vehicle_kills, top_building_kills, top_defence_kills, top_captures, top_game_time, top_beacon_placements, top_beacon_disarms, top_proxy_placements, top_proxy_disarms, // tops (12)
    
    most_recent_ip; // other (1)
    
    time_t last_game;
    Jupiter::StringS most_recent_name;

    I can always add more data to each entry, as well. When I eventually add a web interface for this (it'll be a while), most of these variables (everything but IP) will be viewable on a player's profile.

    In the meantime, however, I'm trying to figure out what I should include in the "ladder" command's output. So far, it's pretty bland:

    [22] <~Agent> !ladder 1
    [22] <@Comis> #1: "Jessica!" - Score: 69463 - Kills: 4 - Deaths: 3 - KDR: 1.33 - SPM: 18.41

    (SPM means "Score Per Minute")

    So with this in mind, I want to know what the community values when it comes to stat visibility. I'm asking everyone: What should be shown?

    Thanks,

    Agent

×
×
  • Create New...
123