Jump to content
The Dark Mod Forums

taaaki

Root
  • Posts

    1020
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by taaaki

  1. Nice find indeed. I have no issue with you committing the mktime() related changes. Once you do, I'll just need to know so that I can recompile the packager binary on the server (have to do it there since the server runs FreeBSD) and recommit the bin to SVN. I can then investigate rebuilding the differential updates and syncing to the mirrors.

     

    We might still need some process for fixing a user's existing install (for cases where there are bad PK4s from previous updates). So shouldn't we leave the timestamp altering stuff in the updater for a release or two (after fixing it for Linux)? Or do you see another way, like fixing the file reading code in TDM itself so that it doesn't get tripped up by the bad dates?

  2. NightStalker:

     

    As you probably gleaned from the bug tracker issue, the changes to the updater were implemented as a workaround. This was because the only way to have the packager build "correct" pk4s was to force a situation where the afflicted files would have to be regenerated completely due to an "update" to an existing file and we couldn't ensure this for all the afflicted files. As I recall, this was implemented as an 11th hour kind of thing, so I admit that I probably didn't test it as well as I should have (and I don't think I got around to testing it on Linux at all) - hence the lack of issues on Windows.

     

    In theory, it shouldn't matter that the tdm_update_* files have bad dates as the cleanup step in the updater should sort this out. But it is quite likely that I may have missed something in relation to the differential updates, which would not surprise me given how difficult it is to follow the updater code (as you can attest). I'll have to try and fix my Linux environment and run some some tests on there to see if I can isolate why the cleanups didn't work (in particular, I'll need to see why the differential updates still have this issue since the packager was "fixed" prior to the release of 2.04). And I agree that this is treating the symptoms, but unless we can actually track down and properly resolve the issue in the underlying zip library (or switch to a more modern version or alternative library), I'm not sure how to finally resolve this.

     

    I assume that you also checked this bug for background: http://bugs.thedarkmod.com/view.php?id=4110

    In that issue, you can see that neither gnartsch, nor myself could figure out why the dates were getting our of whack in the zip/pk4 files in the first place, but my suspicion was that the minizip library used by Doom3 is at fault.

     

    I think it might be possible to regenerate older releases, but I'll have to make sure that the packager is actually buillding valid differential update zip files. Anyway, I'll take another look at this during the week and see what I can come up with taking your suggestions into account.

  3. I don't recall us changing anything to explicitly remove WinXP support. I'll see if I have a WinXP vm already so that I can test this.

     

    My personal opinion (not endorsed by TDM) is that you are doing yourself a disservice by continuing to run WinXP. With MS discontinuing support (or providing token support at best), I wouldn't trust an XP system as anything that could possibly hold or access sensitive data.

  4. Yeah, our WordPress site was getting DoSed by around 4 IPs. I added them to the firewall blacklist, so that has relieved the pressure for now. I'm going to update the web server config to block access to the API that they were spamming, so hopefully that prevents the issue in the future.

  5. This should work now. But I'm not sure if the way I fixed it is correct. I'll have to do some further research so expect it to break again sometime in the nearish future while I experiment.

     

    Edit: also, you may have to force a browser refresh for the forums to get the latest versions of the javascript files.

  6. It needs to extract the .so file so that it can dlopen() it [i have no idea whether or not it is possible to load a shared library from a memory stream]. However, it is a bit strange that it could find the .so file to perform the timestamp comparison, but can't find it when it needs to perform the dlopen().

  7. The features you are looking for will depend on the IDE you choose. The choice of VS for TDM on Windows shouldn't influence your choice of IDE for Linux (as mentioned above, the build system for Linux is different, namely Scons). However, you will need to configure the build process in whichever IDE you choose so that it uses Scons to make your life a bit easier - I was lazy and just ran the scons build script in a separate terminal. Also, the build system hasn't really got much to do with the features you listed above (function locations, etc.). I was using QtCreator when I was making changes to the Linux side of TDM and that seemed to work quite well (I can't recall if it had the function/variable referencing though). You might just need to have a look through the options in CodeBlocks to enable such features or see if there are plugins that can do it for you.

  8. Just a heads-up to anyone using anonymous access to the TDM source code repo hosted at https://svn.thedarkmod.com/svn/darkmod_src

     

    Due to some annoying side-effects of hosting both authenticated and anonymous access to the repository via the same URL, I have decided to re-home the anonymous access URL and make the original URL always require authentication.

     

    So for anyone using anonymous access, you will need to "relocate" your working copy to https://svn.thedarkmod.com/publicsvn/darkmod_src

    The underlying repository is exactly the same as before, but it now uses a different URL.

     

    Assuming that your working copy points to darkmod_src/trunk, you can relocate it as follows (from your working copy directory):

    svn relocate https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk 
    

    For TortoiseSVN users, look for the relocate command and use the URL above.

     

    Apologies for any inconvenience caused. And if you experience any issues, please don't hesitate to post in this thread or drop me a PM.

     

  9. Attachments should work again. Also, I think I've resolved the 3 issues with the mobile version of the site (Full Version button didn't work, usernames on New Content view showing as "Array", and quotes not displaying correctly), but could someone please confirm for me.

  10. Yeah, it's GPL. But it isn't all that straightforward to port the multi-threaded renderer over (and the other improvements). And there will likely be some issues with trying to rebase TDM onto BFG since the tools, etc. aren't there. So until a more "dev/mod friendly" branch is available with the tools and all, we might need to "watch this space". But there are people working on it (e.g. RBDOOM-3-BFG )

     

    Edit: and people making some moves to port stuff from vanilla to BFG like nbohr1more stated above.

  11. And the performance of the opensource driver isn't quite there yet. Just getting back to your issue hammadnadeemx, you probably don't need to go to the latest beta driver, so see if you can dial it back a version or two. Just so long as it's a newer version than the one you're currently using.

×
×
  • Create New...