Jump to content
The Dark Mod Forums

Obsttorte

Active Developer
  • Posts

    6522
  • Joined

  • Last visited

  • Days Won

    111

Posts posted by Obsttorte

  1. I don't have an issue with reusing assets (like scripts et al.) either, reusing whole map parts would be odd, though. But if someone says, whoa, that's a nice doorframe or alters for example the puzzle in the Old Habits Rebuild, I see no issue. It never hurts to ask, though.

    In regards to absent authors it is probably better to not reuse their stuff without consent. It just creates drama in the worst case and in the best case mission authors save a bit of work which they in return have to invest to understand whatever the previous mission author has bashed together.

    EDIT: @Dragoferpretty much nailed it.

    • Like 2
  2. That's the point. It would be nice to have, but it includes an enormous amount of work. So whoever is going to do that needs the respective motivation. And I, for one, don't give a noodle about scoring et al., so I am not motivated. (that's my "excuse" :D )

    We definetely need more coders. So kids, learn do program.

  3. The gui isn't the main issue. The issue is more that each part of the gui was implemented seperately, although there is lot of things that are done commonly. This makes it difficult to make information accessible in one gui that is already available in another one.

    Example:

    In the past, when I worked on the scalability of the in game gui (icon and text size et al.), there was also the idea that upon selecting a mission in the mission screen, if no background image was given the mission screenshots could be used there, which are available in the downloader. I eventually gave up on trying to get the mission selection screen to access the information available for the downloader, as it would have meant an enourmous amount of copy and pasting code.

    My assumption is that the code needs to be rewritten in a form, that one piece of code handles the complete menu system. This would make additions much easier. Until that happens, every change includes a comparable high amount of work and is rather limited in what is possible.

  4. 12 hours ago, chakkman said:

    Big cities usually don't cause claustrophoby.

    I am not sure that this is true. I guess it depends on the city you are in. Also, the feeling of claustrophoby actually fits the theme pretty well, imho. I mean, it is a dystopia.

    • Like 1
  5. 3 hours ago, Knockout Thief said:

    Yeah I'm just talking about a launcher that you can write notes in and score things for your own personal use and search for certain levels like a lot of the thief fm launchers. image.thumb.png.9dc3326cdcdf19d73f39dc13388422ce.png

    Well isn't the main executable basically not our "launcher" then? It serves the same purpose, download and select the mission you are going to play. I honestly don't think we need an additional program for that. What is true and what has been discussed before as said is that additional features, like the possibility to rate missions, could be added. The thing is that this is a surprisingly complex task, and the few programmers we have concentrate their time on the tasks they consider most important. This isn't very high on that list.

    However, as you are a coder and it appears you consider it to be of priority ... ;)

  6. 4 hours ago, kano said:

    I think if the Xbox hadn't existed, DX2 and Thief 3 would have been superbly excellent games.

    I think the games wouldn't have differed much in regards to gameplay and level design and we would be holding the same conversation just complaining about different aspects that we didn't liked.

    Personally I've played both games several times, which means they didn't do too much wrong imho. The first Deus Ex already had split up maps with comparable small areas, so it wasn't such a break compared with Thief. Besides that the only real downside for me was the lack of a synchro for Deadly Shadows, while oddly enough DX2 received one.

    I wouldn't say that DX3 and DX4 are better, they are just different.

  7. 2 hours ago, Daft Mugi said:

    I tried this by making newspaper_bridgeport01.dds, newspaper_bridgeport02.dds, and newspaper_bridgeport03.dds darker, and it worked well. The result was better than I originally thought it would be, so thank you for suggesting this.

    On the long run it is probable easier to darken the guis instead of altering the image files (and it is easier to revert if necessary).

    I'm curious how your try on an automatization works out. Thumbs are pressed. :)

  8. 2 hours ago, Knockout Thief said:

    C# and Dark Basic

    Well, the game is written in C/C++, so you can probably read the code. I just saw you are refering to the launcher, but the discussion I've mentioned was about the game. I am not sure how many players actually use the launcher.

    Either way, you are welcome to play with the code and provide whatever you may come up with. :)

  9. 1 hour ago, wesp5 said:

    That sounds like a promising approach, scale the brightness of the readables in connection with the light gem.

    Not really. You could stand in the darkness but look at something bright in the back or vice versa. It doesn't depend on how well the player is lit, but how bright the scenery is compared to the gui. This however doesn't only depend on the light sources, but also the materials used on the surfaces.

    Did anyone ever test the automated gamma adjustment mentioned earlier on?

  10. This is a mission bug. The quill is attached to Percys hand for writing, and removed once he stopped. But there is nothing in the code that checks on whether Percy is already holding a quill. This can cause a quill to be spawned although there already is one, and as the naming is fixed, you suddenly end up with two entities sharing the same name, which is not allowed.

    The attached modified script should solve the issue. It belongs in the maps folder inside the pk4.

    (I hope it is okay to provide the fix, it doesn't change anything artistical).

    tbm.script

    • Like 2
    • Thanks 1
  11. 5 hours ago, Daft Mugi said:

    Do "guis" refer to the ".gui" files in the pk4 files?

    I'm looking through pk4 files now and just saw ".gui" files for the first time.

    That's what I've meant. As far as I see it the problem is the contrast between bright guis opened in an otherwise dark environment, as @Oktokolopointed out already. So the idea would be to make those, like the above newspaper, darker.

    11 hours ago, Daft Mugi said:

    Wouldn't code that automatically adjusts the brightness be more effective at solving this for any mission?

    Yes, and automated version is always preferable. And as @stgatilovsaid it appears that there was something like that been worked on in the past, which I didn't knew. The question is though how reliable it is. Typically such adjustments work gradually over time, but that wouldn't help much here as a bright gui would still be annoying, even if for a shorter amount of time. So the code would have to reduce the brightness immediately.

    It has to be tested whether this doesn't create any unwanted side-effects and if we exchanging one annoyance with another. As said, I wasn't aware of the implementation and have therefore never seen it in action, so I can't judge on that.

  12. Well, in regards to the core assets it is probably worth a consideration to tune down some of the brighter gui backgrounds. (The gui in the video is the same as in your first post, so it is probably a core asset.) This would additionally result in a more consistent look, which isn't the worst thing imho.

    But regarding guis specific to certain fms I still think you should address this in the respective mission threads. Personally I never had an issue with this matter (although I can see that it can be one), which leads me to believe that this is heavely depending on factors like the monitor used for example which may could cause mappers not beeing aware of that effect.

    Maybe you can list the guis in question so we can see whether they are stock assets or mission specific?! That would be a good starting point.

  13. If you set models to non-solid, they won't affect collision detection. This is a good idea for models used as decorative extension, like little beams on walls or other small stuff (like static junk). It won't speed up aas creation, but the cm file is created faster and it becomes less likely that ai gets stuck on small objects. Obviously you should't do this with large objects.

    • Like 2
  14. As long as you are not working on optimizing gameplay or ai, you can use noflood as argument for dmap (dmap noflood mapname), this will skip the aas creation (pathfinding).

    As @nbohr1moresaid, the pathfinding algorithm or more precisely the time it requires isn't linear with the amount of areas the ai can step into. If the map isn't properly monsterclipped and a lot of decorative stuff made from brushes is left worldspawn, you can easely end up with a huge workload. The same applies for the collision data creation.

    • Like 1
×
×
  • Create New...