Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Tels

  1. So, I got a new PC, and a shiny, new Kubuntu 64bit installation of 14.10.

     

    TDM updater throws me the error (it says a bit more, but that is the gist):

     

     


    libstdc++.so.6 missing

     

    Looking at:

     

    http://wiki.thedarkmod.com/index.php?title=FAQ#What_about_Ubuntu_8.10.3F

     

    The FAQ is completely outdated (it still talks about Doom), and the package ia32 does not exist. So I'm a bit at a loss at what actually todo.

     

    Interestingly, Linux Mint 17.1 (also 64 bit) on the same hardware runs TDM just fine. Unfortunately, I have no idea what the difference was/is.

     

    So, how do I get TDM to run under Ubuntu/Kubuntu 64 bit?

    • Like 1
  2. Last time I checked, most people don't like LPs with voice overs.

     

    I personally watch LP videos for the commentary - hearing what the player thinks, his/her emotions and so on. Without commentary, I might as well play myself.

     

    In TDM's case, of course, also to hear about the work I helped to create with. :)

     

    Of course, not every one is a good commentor, but I'd rather not watch a video w/o comments at all.

  3.  

    • Hmm, interesting is this in the wiki for the SEED entry/tut..?
    • This sounds like a bug that needs a tracker..?

     

     

    (About growing grass on earth, but not stone/tile)

     

    That's actually a feature, SEED defines a factor that says how much should grow on certain materials. The probabilities are defined on the target entities, so grass refused to grow on bricks by default, but leaves/apples/random junk would not. This can be changed:

     

    probability

    Default 1.0. Is used as default probability for entities to spawn on certain surface types, but only when you define seed_material_xyz spawnargs on the template/target entities. See there for an explanation on how this lets you spawn entities only on some surfaces but not on others.

     

    http://wiki.thedarkmod.com/index.php?title=SEED_-_Spawnargs#probability

     

    http://wiki.thedarkmod.com/index.php?title=SEED_-_Spawnargs#seed_material_xyz

     

     

    SEED is not the most mapper-friendly, unfortunately. Wish I had more time to refine it... :(

     

     

     

    BTW: Can somebody please fix the robots.txt for wiki.thedarkmod.com? Google stopped listing everything there and instead displays:

     

    "Wiki - The Dark Mod

    wiki.thedarkmod.com/Diese Seite übersetzen

    Aufgrund der robots.txt dieser Website ist keine Beschreibung für dieses Ergebnis verfügbar. Weitere Informationen"

     

    That makes it hard to search for wiki pages.

     

     

    • Like 1
  4.  

    I assumed that the names were indeed map-specific, but this is a thread entitled "How would you change St Lucia", so my suggestion is that the difficulty names are changed in this particular mission. I'm not proposing that some global TDM-enforced naming convention should be applied to all maps.

     

    Ah, that makes sense.

  5. I'm forming an idea of fixing the spawnarg documentation in DR. It shouldn't be difficult to extract all the code that reads spawnargs from the game code and the scripts, along with a line of context either side so we can see what kind of value the spawnarg holds, e.g. an entity name or a color etc. The bit that would need a lot of human time would be deciding which ones to make show up in DR. We wouldn't want ALL the idEntity spawnargs to show up for everything, for example, but we would want *some* inherited spawnargs to show up for some entities. That decision probably needs to be made by a human rather than a script.

     

    The old id code had about 50% (or maybe 30 or maybe 80%, I don't know exactly) documentation on spawnargs - and almost everything afterwards by TDM was not documented, until I started the big spring cleaning :)

     

    Others then chimed in and we added a lot documentation, but there are still hundreds of not documented spawnargs. The ones that are set on entities can be see in the online documentation http://bloodgate.com/mirrors/tdm/doc/index.html#overview

     

    However, that does not cover spawnargs which are defined/used in the code, but not set on any entity def.

     

    As for adding them in the entityDefs, I think it is important to cover them all. The editor (DR) can then decide which to show or how, but they should be absolutely documented via the entityDefs. That at least sets their type (int, entityname, color, shader etc.) and a sensible default value and some documentation.

     

    It's IMHO better the mapper has a few too much than a few hidden spawnargs.

     

    DR also already decides which sparnargs to show where, I think it depends on the base type of the entity. F.i. idLights get different spawnarg shown than idTrigger, which makes sense.

     

    But generating the list of missing spawnargs and their type from the code usage is probably easier than doing it manually like in the past.

  6. I haven't completed the entire mission yet, but here are my thoughts from the parts that I have played:

    1. A relatively trivial point, but there is a good reason the original Thief games used Normal/Hard/Expert rather than Easy/Normal/Hard as their difficulty labels. There is absolutely nothing "easy" about our Easy mode, and I suggest we stick with the same rationale used by LGS.

     

    Unfortunately, the names of the difficulty are set by the mapper. So "we" have no control over them. Which might be good, or bad. But it certainly is not easy to change.

  7. Oops, that one was probably me: Mea culpa!

     

    "cycleTrigger" got broken when someone gave func_emitters the ability to use multiple particle models. They also introduced a random time offset to make the particles look different. That overrode what cycleTrigger does, and broke the ability to trigger one-shot particles.
  8. Nearly all triggers use the 'targetNN' spawnarg and a wiki phrase that says "A targets B" means to use those spawnargs. In a few cases, though, where "A targets B" means something else, then both the wiki description and the editor comments should clearly specify what's needed. trigger_entityname fails to do that, and needs to be corrected. I think I filed a bug report to make that happen (Not home atm, so can't check.)

     

    Edit: 'entityname' doesn't function like 'targetNN', but the idea still holds: important spawnargs should be defined somewhere. The wiki page does call it out, but there should be some kind of default editor description that describes the key spawnarg this entity needs to work.

     

    Agreed. And I think the entity def should set a default value, even if this is something like "fill in entity name here". That way the mapper both sees what to do and where, and also the entity def can specify that the value of the key is an entity - there are important distinctions between colors, integers and entity names, f.i. DR knows that if you rename the entity, it also needs to change the value pointing to the entity. Without that definition, DR ignores the value, leading to a broken trigger.

  9. Yeah, we'll see. More than likely it'll be something stupid like only for 2XX series cards.

    Sorry after my issues with 5870 mobility crossfire, I'm not very fond of ATI.

     

    Yeah, the pessimist in me says they fixed some issues nobody actually had, accidentily introduced a few new bugs and never actually touched the issue we wanted fixed. That's how it typically goes, and I'm not even singling AMD out here :rolleyes:

  10.  

    You may want to read the post five up from yours.

    If only we could power the effort with sarcasm and indignation...it would be done already.

     

    So, the current excuse is that we don't know who will do it, plus a bunch of "uh oh what maybe bad could happen and how will we all handle it". That amounts to me to the same indecision as the last two years.

     

    I guess that since I already pitched in the 100$ need to greenlight it, I would also be the person to handle the submission. But my guess is you will now reply that I'm not a "trustworthy" person and we will be back at the start again.

     

    Every journey begines with the first step. With this issue however, we took over 2 years doing a pointless discussion on what-if and but-it-might-be and never dared to take the first step. And instead of trying to do the first step, the reply is again on the same line of venues.

     

    That's very frustrating - to put it mildly. :mellow:

  11. I haven't yet managed to read every post of the rest of this thread, migh thave missed a few from October 2013 onwards, but I just saw this in my inbox:

     

     


    Steam Greenlight================Some of you may already know that yesterday we submitted **Underworld Ascendant**for Steam Greenlight. If you can take a moment to click on the link below and voteYES, it would be a big help toward increasing the game's visibility with the massiveSteam community.

     

    They haven't even finished their Kickstarter campaign, but are on Steam Greenlight. In the other corner we have TDM, which build an awesome game over 7 years and still hasn't managed a simple submissin to the biggest gaming platform at this time.t... even AFTER we already gone standalone, already polished our game to perfection AND multiple people said they are willing to cover the 100 $ and time needed for the submission.

     

    So, what is our excuse this year for not doing it?

  12. Would also be cool if the entire SSE stuff could be implemented in Linux. Currently it justs fallsback to normal code there. Back then I fixed a few of the detections (so Linux at least knows about what properties the current CPU has), but it's not used much...

×
×
  • Create New...