Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

Everything posted by sparhawk

  1. Looking good is one thing, but Spring raised the issue that the hard part is creating normalmaps. If the textures are just that and only looking good, it is not enough to put them in the mod, because they will look bad without the maps.
  2. Did you also raise the issue of TDM being put on DVDs (which already happened with Thief's Den)? On the other hand, that might be seen just as a different way of distribution, even though a magazin profits indirectly from it, it's not their business model to sell the textures as such. IMO it would be the same category if a hoster charges per download, independent of the content.
  3. The model definitely looks nice. The first few images look a bit extremly new and clean (or maybe modern as Spring said), but the lower ones, sure look much better.
  4. Obviously it's technical impossible to "lock" them in any way so that they can not be used for other purposes. The only thing we can do is, to add the permission to our redistribution notes, and a list of the filenames of those textures that we are using so that poeple are aware that those are commercial textures.
  5. Cool! That's certainly good news. I sent them a mail asking for confirmation and also on details that might apply. I hope you don't mind me doing this, but since this is always a sensitive issue and can cause a lot of problems I'd rather double check. Before we can add those textures to the repository we should create a list of the filenames (as used in the mod), so we can track them and make people aware that those are commercial textures.
  6. I already bought it. Must see if I can scan the article somehow. Hmmm... I considering renewing my subscription. I cancelled it some time ago, because I don't play so much anymore, but somehow I miss the news.
  7. Textures are always an issue. There is nothing like "too many texture error" in our mod. So if sombody like pataran goes to the effort to create new textures or improving existing ones, this is certainly appreciated and always helps the mod along, as we are notoriously low on contributing people. And I sure don't buy that "When the mod is released there will be a host of people suddenly adding quality stuff". I certainly think that good stuff will be added over time, as there are always people doing that, but if there would be such a large number willing to contribute new stuff, why would they wait for the final release, when we can already use them now, and often enough said so? You got permission from the copyright holder? That's certainly good news indeed.
  8. Since usage is strictly restricted to TDM, I wonder if the licence does apply. After all, it is for this project only, not for a library or such. The best approach would be to ask the owner on his opinion and maybe get a written permission if he agrees.
  9. I just had time to read it and it's not so bad. It's more a general article, because apparantely they included our mod on their DVD this time. They even mentioned that fan made mission.
  10. In the current issue of Gamestar 12/08 there is another short article about us. While I consider that good, the article is a bit missleading. Specifically it says that we are at version 1.0. Otherwise it's ok.
  11. I'm definitely for a seperate packacking process as opposed to a release branch. Merging is painfull and prone to errors, and using a package script gives much more control over that even if you want to test different configurations.
  12. That depends on the type of application. Assume that you have a quad with 2.6GHz then in worst case, the application runs at 2.6GHz. In best case you might get 4x2.6GHz (not really because of overhead, but closer). On my 2GHz Pentium 4 I tried to run Need For Speed Prostreet and it was a slideshow (even already the menu). On my new machine it runs totally smooth on highest settings. Of course I also bought a new gfx card along with it and additional RAM, so this alone might not be the deciding factor. With the advent of new games they will increase to employ more parallel strategies and some already do. Don't know which breakthrough was meant, but there are some ideas already in research, like quantum computers, which are MUCH faster then any classical machine. Of course it also needs new paradigms for software development as well.
  13. Huh?!? Why should a D3 original file go???? If we don't need it ok, but copyright reason? The horse is of course a different thing.
  14. That's usually quite easy on Linux as well. It depends. I neglected to update my Linux machine for some time. Now I wanted to upgrade some parts of it and all the servers are dead already. so I have to do a full install probably. The good thing though is, that this is quite easy on Linux. I was really suprised to see that with Ubuntu I could install it over a gentoo distribution and not loosing a sinlge user option that I had configured. Even though they are completely different distributions. I was quite surprised about this. The key to that is properly seperating the parititions, which I always do anyway. In Windows it's not really possible to do that. Installing a new OS from scratch also requires you to install all the applications that have nothing to do with the OS as well.
  15. The only reason why this is more "complicated" than on Windows is, because on Windows most programmers already do the dirty work for you. That's one area where linux is lacking. That software developers are not used to writing easy to use installer. Sure it's partially because the systems can be much more different than on the average windows installation, but if you get down to the real OS Windows is not really easier to configure as well. Quite on the contrary, with the registry being in a binary format you have almost no chance of rescuing your system if something is screwed up. On linux you can always mount the drive on a different machine and repair it. I don't say that one or the other is neccessary better though. There are good and bad sides to each of the approaches. I like to have more detailed control like in Linux, but on the other hand it can get really tedious if you HAVE to exert that control all the time.
  16. sparhawk


    Some of them are simply foreign characters. The other one was just gibberish text, that gives an impression of someone not good at english. The spamlink was in the signature, so that it looks less like spam and increase the chance of getting through.
  17. Yeah, that's true. I was wondering, because for Saturn it wouldn't make sense to remove it because of copyright crap (which was my assumption at first). After all it's a commercial and it possibly can't get better exposure for no money.
  18. The tag can be already added, because it's just a text spawnarg after all. So even if currently there is no code to support it, it can be added later. So you can start adding a tag to textures now without fear of disrupting anything. The only thing that should be agreed on is to use a consistent (and small) set of tags. Another advantage is also, that even if we don't add code to support it, you can still use the tags later on with scripts to help automatize analysing the problematic stuff.
  19. I don't see why, putting it in a local PK4 which is map specific and will be delivered with the map anyway, should be so complicated. Assuming this works as I think it should, of course, this should be the best way to do this stuff, because such problems can occur always also at a later time. Not just because some things would be replaced by newer stuff breaking older stuff, but also because it might make sense to override existing stuff with a customzied version of it. And the proposal about adding tags, would be a long-term solution for this problem, not just for your particular map, but it would solve other problems as well, like where to put things if they have more then one particular use.
  20. lights/no_models lights/static lights/movable Not, if we ALWAYS put all lights under lights. The problem is that we have an N-Dimensional matrix and try to squeeze it into a linear description. The only way to properly solve it is, if we attach tags to each def, like "Light, Movable, Model, etc." and the editor shows you a list based on that tags, instead just a tree with fixed paths. This way the user can look for Moveables if he wants to see movables, and find everything, but if he looks for Light he would find all lights including those objects. The same approach would be also good for textures, because there the same problem applies as well. I think such a strategy could be implemented without any reorgs, as it would be transparent for the user. Organziation of the paths, would also be less critical then.
  21. Another option would be to flag such textures as obsolete, and support that flag in the editor. So the texture would remain in the repository, but the editor can warn people about them based on that flag, so they shouldn't use them anymore. This way we can at least mark all those textures, and have more time to think about it, without the immediate need of replacing them and angry mappers with it.
  22. Yes, that's understandable. It's very frustrating to have to do the same boring stuff over and over again (just ask Spring about the re-rigging of the models for animation). Also there is a high risk that such textures cause problems in the map, because you may easily miss areas where it was used and considered finished.
  23. I wonder if this would work if the textures are removed and you keep a local copy of them, putting them in your own private pk4 file and deliver it. Not sure if this would work, but if Doom 3 loads two files with the same name, I think there is a chance to take precendence over other files. Did you try this approach?
  • Create New...