Jump to content

Agent

Former Developers
  • Posts

    1271
  • Joined

  • Last visited

Posts posted by Agent

  1. Votes do need an animation to increase visibility and player participation. I'm thinking the text would start in the middle and slowly rise to the top where it rests. It'd be best if this were done in Flash so that it's the same size for everybody as well. If surrender votes still appear to be bothersome after such a change, perhaps we should adjust the votes needed to pass the vote.

    We do not need to associate any gimmicks with surrender votes. At most, a 5-10 second time span where vehicles are abandoned and the enemy puts their hands in the air. That's it. We don't need to change how surrender votes function at their core.

  2. 2 hours ago, Axesor said:

    like sending stats after each round to the webside, so all the archievements and stats would be archived on the webside

    The server list / leaderboard already has full RCON access, which logs many events such as purchases, kills, deaths, and much more. I just haven't gotten around to converting some things to use a proper SQL database yet, which makes it slightly annoying to display webpages or generate stats for. I've had a lot of ideas and just simply not started working on them -- I don't want to dedicate that much time to unpaid work every day; I'd rather spend that time job searching (which is extremely draining and demotivating to me).

    As far as implementation of an in-game login system goes... Checking credentials against the server database would also require a custom PHP script, or perhaps an external application, to verify credentials. Then if we wanted to tie this in-game, a unique authentication token has to be generated and sent to the client. The client then sends this authentication token to the server, and the server verifies it against another custom PHP script. A new RCON event would throw a log for authentication pass/fail; the server would then kick the player or allow the player to play depending on implementation. That's the most straight-forward way of implementing a login system by itself, and would only require usage of 2 languages (PHP and UnrealScript). My original plan was to incorporate user logins (among other things such as PMs, server queues, etc) into the server list application, though I never got around to it (this solution would require 3 languages: C++, UnrealScript, PHP). I would have then been able to fundamentally change how the server list provides server data to the clients using this new user management system, hopefully improving the general security of Renegade X game servers by obfuscating server details from potential attackers (it certainly wouldn't be full-proof, but it would have made it a bit harder).

    As far as whether this is a good final project for a university course... I'd lean no because you'd be building off of systems that aren't your work, and I have no idea how your professor would feel about that. It's also not particularly "flashy" in that it's a pretty mundane programming project that requires a considerable amount of work without really providing any "wow!" factor -- which is true about most network programming tasks. If you're wanting to impress your professor, I would think that making a small game in Unity might suffice. Who knows, maybe you'll make something really nice.

    • Like 3
  3. K/D is a terrible measure for anybody, largely because deaths just do not matter in the slightest. Kill count is more relevant.

    I'm somewhat against implementing an MVP marker, at the very least below player names -- the UI looks cleaner as-is. Maybe a star with a number on the inside to the left of their name would look nice though.

    Edit: Something like this 2016-11-07_11-39-55.png

    Though people would probably start confusing it for veterancy at that point.

    • Like 1
  4. 16 minutes ago, Axesor said:

    This may go by side with game accout when/if it will be introduced

    I'm slowly starting to doubt this ever getting implemented unless we recruit another programmer or two. I just do not have the time or passion right now to implement this on top of the in-game downloads. I'll probably make a post if I get around to working on this.

  5. 20 hours ago, KrypTheBear said:

    How so? I mean, recently I see more and more remotes in choke points, especially if you are a LCG and it's like "Oh shit, there's a rem-" *dead* and you can't really do anything against that other than praying to Mother Mary having some mercy. 

    There's a lot that you could do. You could just not run into remote C4, kill the person who placed them, bring a repair tool, or simply ignore them since they're probably fake. If you're an LCG (or another flak character), you can tank a few remotes with ease and still take down a building.

    If we wanted to discourage using remotes in choke points, it'd probably be better to reduce the personal limit from 4 to 2.

    Also worth noting, it'd be pretty easy to limit the disarms to remote/timed c4 attached to the landscape (or otherwise not attached to a building/pawn), though that'd be pretty wonky and inconsistent behavior.

  6. I'm currently busy sending out work applications. In addition, I don't have access to some of the source code I had written for this due to a possible SSD failure (I haven't gotten around to figuring out if the SSD is actually dead, or if the motherboard is the issue).

    I'll work on it when I work on it.

    • Like 2
  7. None of the others really fit me at all -- I tend to just do whatever I feel like the team needs most. I prefer tanking, killing enemy repairs with shotgunner, and occasionally attempting to sneak in. I rarely repair vehicles or snipe, though it does happen from time to time. If I'm Nod on Field or Islands, I'll often push GDI tanks into the water with a Stealth Tank.

    When I'm in the right mood, I'll also find myself yelling at the team to buy tanks or meet at the Airstrip for a Mendoza rush.

    Field is still my favorite map, though I have no real reason for this. I just like Field.

  8. You can't just give it an arbitrary class and expect it to know what to do with it. That's why you must have a class that extends Rx_Mutator that replaces classes out for you.

    I'm sure nBab could post some examples from his mutator for Fort, but you're going to want to make use of Mutator's CheckReplacement() function.

  9. How is that bloat? It would drastically simplify gameplay, remove the single most convoluted mechanic from the game, and remove much more from the code base than it would add. Dedicated defenders would no longer be nearly as critical.

    And that's half team participation if you want every door mined instantly. The base would actually probably get mined sooner than it currently does even with mines costing 250/300. And even then, not every door needs to be instantly mined and secured. It's perfectly fine for it to take a couple minutes.

  10. Mines in the HoN floor are kind of cheesy and should be fixed, but they're really not worth moderating.

    Yes, I would say a glitched nuke is indeed "intentionally ruining other people's fun", and as freak pointed out they're against CT's rule set -- which I agree with. Server moderators should disarm glitched/undisarmable/invisible beacons and warn the player. That's a very proportionate response. However, a permanent ban for example would be a disproportionate response for any glitch. Glitches get fixed, they're temporary, and they're not an egregious form of cheating. Glitches can also occur unintentionally or unknowingly that it's considered a glitch. It'd be a bit unfair to kick someone or disarm all of their mines just because their mines fused into the HoN's mesh for example, if that wasn't their intention. It's also very difficult to prove many accusations of glitching unless somebody happens to be recording.

    It's extremely difficult to moderate glitching. That's part of why I prefer a lenient policy over a strict one any day.

  11. It's a pretty minor exploit, and the beacon itself was still perfectly disarmable. He put it in a legal location, and how you get there is up to you. The beacon succeeded more-so because he successfully defended it, than it did because he used this minor exploit. I wouldn't get too salty over a minor exploit like that, though I did forward the post to @Havoc89 to see if he can fix it real quick. There is some merit in that he grabbed attention, even if it's not in the most elegant fashion.

     

    38 minutes ago, voltex said:

    Also, going off that same logic I guess it would be just fine for me to grab a Nod spy on Under and Ion the top of the PP because as you said its not my fault its the glitch's.

    That's a much more severe exploit, as you're placing the beacon in a location that is in no way accessible.

×
×
  • Create New...