Tels

AHA: http://wiki.ubuntuusers.de/Spiele/The_Dark_Mod That installs 27 packages (21 mbytes), and then it runs.

One option would be to simply disallow quicksaves at this time. I'm not sure it is easily fixable otherwise.

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): 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?

It's "Rootkit"-Sony, and "Heh, let's remove Linux from the supported OS from the PS"-Sony, remember? Why wouldn't they screw with you, just because?

Two links I stumbled over from the Kingdom Come - Deliverance update #10 video: http://botn.info/en/ http://libusin.org/en I'm considering visiting these events.

Somebody should create an account and post a comment, mentioning TDM and Underworld Ascendant

When my new PC arrives, I could give this a spin - but it will take another week or so at least. So please don't wait for me

Btw, thank you for making these videos and uploading them - that is quite some work. One request tho, would you upload a more high-res version? 480p isn't what I'd want to watch fullscreen.

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.

The map spawnarg can be used to get more varied distributions, here are a few examples: http://wiki.thedarkmod.com/index.php?title=SEED_-_Image_maps

(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 übersetzenAufgrund 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.

Ah, that makes sense.

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.

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.

Oops, that one was probably me: Mea culpa!

.

I have no idea without delving into that code again - which I'd rather avoid at this time

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.

"That video gave me epileptic seizures after 10 seconds. Would not watch again. ---"

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

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.

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: 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?

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...

Apart from the logging code in TDM (which is different from the console ouput), you can also use "condump console.txt" to get the contents atferwards into a file. (But it doesn't stream them out as they appear)

http://svs.gsfc.nasa.gov/cgi-bin/details.cgi?aid=11742