Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Torr_Samaho

Members
  • Content count

    19
  • Joined

  • Last visited

1 Follower

About Torr_Samaho

  • Rank
    Warming Up

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Torr_Samaho

    ...solved - is no bug

    A lot of stuff may accumulate in the Zandronum directory (config files, save games, downloaded wads, screen shots, logs files, crash dumps, etc.). The installer gives the user a convenient option to wipe everything. The option is disabled by default for a reason, but if the user explicitly wants everything to be wiped, why don't offer the option? The big difference is that this was an incredible bug in the Sierra's uninstaller, while Zandronum's uninstaller just does what it was explicitly instructed by the user to do.
  2. Torr_Samaho

    ...solved - is no bug

    The uninstaller has a "Remove all files in the Zandronum folder" check box (which should be off by default and at least on my system it is). If you manually check that box and then hit uninstall, it will do as instructed. Did you check that box? If not and it still deleted all files in the directory, I agree that this is a terrible bug that needs to be fixed ASAP.
  3. Torr_Samaho

    Zandronum 1.0 Released

    They are two competing distributed revision control system but with very similar feature sets. I prefer Mercurial because it has better Windows support than Git (at least it was like this when I switched to Mercurial).
  4. Torr_Samaho

    Zandronum 1.0 Released

    For ZDoom/GZDoom the much better branch handling would be very useful. You could define GZDoom as brach/fork of ZDoom and let Hg do all the merge work (keeping the full history instead of collapsing many ZDoom commits into a single GZDoom commit). This would also be interesting for Zandronum because I could then define Zandronum as GZDoom branch and also get the benefits of the much better merge handling. Also you can more easily import code submissions using Hg's pull mechanism.
  5. Torr_Samaho

    Open Your Mind, Open Your Skull

    About one and a half years ago, the bug handling has been moved to a bug tracker that is completely separated from the forum. Whatever experience you had with reporting bugs on the forum doesn't necessarily apply to the new tracker. There is only one thing I can say for sure, chances that I fix something that I don't know about are zero (ignoring the unlikely case that something is fixed accidentally...). Thanks! I'll backport the fix. Then please make a report at our tracker and we can discuss all the details there.
  6. Torr_Samaho

    Open Your Mind, Open Your Skull

    From the top of my head I only remember some cosmetic Hexen bugs being reported and after a quick look at the bug tracker I couldn't find any report on this issue. Can you either point me to the report on this or create one?
  7. Torr_Samaho

    ZDaemon turns 109 today

    Since my name is brought up and I coincidentally noticed this, let me clarify my stance: We are thinking about a completely optional login system. In particular, the master sever will always give everybody (unless the IP is banned from the master) the player list without logging in / signing up or anything like this. Each server admin then is free to decide whether he requires players to login before allowing them to join his machine. IMHO requiring a player to sign up just to get the server list is outrageous and something that I will never support.
  8. Torr_Samaho

    Skulltag 0.97c2 Server Backdoor

    If anybody insist, I will make sure that all affected binaries are removed from our homepage. It looks like the MAME code crept in when porting a bunch of changes from ZDoom in Skulltag revision 2025 of the latestzdoom branch. This means that all ST versions since 98a are affected. I'm aware of this and therefore obtained permission from Carnevil to relicense his code (which in particular should cover all Skulltag exclusive files in 97c2) as I see fit some time ago. So it just remains to obtain permission from the handful of people who worked on ST since 97c2, but I don't foresee any difficulties with this.
  9. Torr_Samaho

    Skulltag 0.97c2 Server Backdoor

    Right after the license of the OPL code was brought to my attention I immediately announced that I will simply remove the OPL emulation: http://dev.skulltag.net/tracker/view.php?id=291#c1089
  10. Torr_Samaho

    Skulltag 0.97c2 Server Backdoor

    I'm confused. I thought the following is completely unambiguous: Good grief, is your impression of me really that bad that you think I'd willingly try to hide such a backdoor with an evasive trick answer? Not to mention that the statement I made in the second paragraph IMHO is unambiguous. "no backdoor of any kind" of course also means that there are no secret currently unused lists to get control over a server or anything. Rivecoder removed the code in revision 1657 on 15. Sep. 2008 from the main trunk, I ported the change shortly after to the latestzdoom branch, i.e. removed it from that branch. IIRC I noticed the backdoor only when Rivecoder removed it because I looked into sv_admin.cpp to see what he removed there. I don't know when Rivecoder first noticed the backdoor, but I assume that he stumbled upon it shortly before removing it. Since I myself was never really interested in the "control" stuff like banning or RCON, I didn't notice it earlier. You can hardly assume that I have read the complete source before making any releases, can you? So I don't see how I have been caught with anything. Are you even aware that I was the one pulling the strings in the background to make the release of the 97c2 source happen at all? By now I have touched pretty much all parts of the code. I would be very surprised if there is any other backdoor hidden somewhere. Rivecoder left the team a while ago, so I was pushed to also work on the control stuff since then. Unless we decide to go completely open source, it is possible that I will strip the released sources of some hack countermeasures. Not that these are very effective or sophisticated, but when the source of them is released they are completely useless.
  11. Torr_Samaho

    Skulltag 0.97c2 Server Backdoor

    There is no "master adminlist", the only thing the master distributes is a banlist and a whitelist that puts exemptions to the master banlist. You can view those lists with "viewmasterbanlist" and "viewmasterexemptionbanlist". And the master bans can be turned off by setting sv_enforcemasterbanlist to false. The code you showed above was removed approximately two and a half years ago from Skulltag. I myself wasn't really aware that there was a built in backdoor for a long time, but I didn't check the code for such a thing when I joined ST. Due to the best of my knowledge there is no backdoor of any kind in Skulltag ever since the code you posted was removed. Furthermore, I would never add such a thing or tolerate it in any way. I have to admit that I didn't read every line of code though.
  12. Torr_Samaho

    Yet another Skulltag source thread

    Ever since I ported the GZDoom renderer to Skulltag, Graf always had full access to the very latest version of the Skulltag source. In some regards, this is more than LGPL would have granted him. We share everything we do with him. And if you look through the GZDoom logs, you'll see that he got quite a few improvements to the GZDoom renderer from me: Model interpolation, HUD model support, a whole bunch of model rendering flags, sprite billboaring and smooth/round particles, just to name my contributions to the GZDoom renderer that I remember from the top of my head. AFAIR Graf mentioned somewhere that he never got any noticeable contributions to the GZDoom renderer, but this was before I started working on Skulltag. So if my memories serves me well in this regard, no one (other than Graf of course, he is the creator and the overwhelming majority of the code is his) contributed more things to GZDoom than me. At least this is true for the last year, I have been following the GZDoom development since then. On several occasions my code even appeared in GZDoom, before it was in a public version of Skulltag. IMHO this agreement was/is advantageous for both of us.
  13. Torr_Samaho

    Yet another Skulltag source thread

    The sad thing for me about the outcome of this discussion (i.e. new GZDoom license) is that essentially I get punished for one of Aabra's actions that I don't even agree with. Security issues should always be publicly documented, this is good for open and closed source software. For the latter it pushes pressure on the selected few with source access to quickly fix the exploits, and this is a good thing. Ever since I joined the ST team, I took all security problems that were brought to my attention seriously. You can ask Luigi Auriemma, he should confirm that I quickly react to reported exploits and that I don't ask anybody not to publish exploits. The text file of him that was referenced here was written long before I even came to ST. I even told Aabra on the Skulltag forum that publishing exploits is a common and widely accept practice (Graf should be able to see the corresponding post in the dev section, that I made well before his decision to change the GZDoom license). The only reason why I didn't do anything against the fake players tool yet is it that I don't consider this to be an exploit that needs fixing. If someone is interested in why, I happily elaborate on this. And from the fact that hundreds of other online games don't fix this either, you can guess that I'm not alone with this opinion. The only thing you can do with it is to fill a server. It's blatantly obvious from the logs and anybody abusing this can be banned easily.
  14. Torr_Samaho

    Yet another Skulltag source thread

    As already mentioned, denial of information methods can only be used to reduce the effectiveness of aimbots, but as soon as an opponent is visible on the screen, an aimbot has all information it needs. DOI may be effective against wallhacks, but can't really keep aimbots at bay. Any other suggestions? If not, I'll guess I have to conclude that a closed source anti cheat module is the only feasible solution.
  15. Torr_Samaho

    Yet another Skulltag source thread

    I think you misunderstood me. Currently I'm not really interested in theories about how people are going to use cheats or how cheats affect the overall gaming experience. It's not that your views don't sound plausible, it's just that I'm only looking for unbiased technical measures to prevent cheating (or at least make it more difficult). Especially how to prevent aimbots from being used when the source code is completely open. Finding them by watching demos will never be 100 percent accurate and always be biased to a certain degree. Furthermore, this doesn't prevent anybody from actually using an aimbot in the first place, it will just lead to a ban after the aimbot already has been used. I can imagine difficult to circumvent counter measures to aimbots when using a closed source anti cheat module, but I have no idea how this could be done with the source completely open. If anybody has ideas on this, I'd be happy to hear them.
×