Leaderboard

I think the time has come to "do something" with the console text layout, prompted by user feedback on discord I suppose since the original console was designed for 17` 4:3 screens, it does looks weird to modern eyes. What is the common setup these days - 24' 16:9? With increasing share of even wider and bigger screens. As always, I'm willing to minimize the changes in the code (unless the change is deletion, which I can never have enough of ) Unless someone else wants to step up, I'd like to make the following changes configurable console line length (text buffer width), which would automatically make symbols narrower (or, quite unlikely, wider) configurable number of lines to show in the console -> make lines more dense or sparse maybe also allow the console to take 1/3, 2/3, etc vertical space when dealing with large amounts of text info unicode?

Without any prior giveaway - Samorost 1 is now free on Steam and GOG. I didn't see any time limits for taking it: https://www.gog.com/game/samorost_1 https://store.steampowered.com/app/1580970/Samorost_1/

I think there's probably a way to make this happen with a custom s/r and some scripting. I'll think about it. Edit: here's how. Set up a custom stim near the light, with an appropriate stim radius. The stim fires every 200 ms. Add a corresponding response to the player object. Custom responses call a script. That script looks like this: if (!light_already_on) { $mylight.On(); light_already_on = true; lightTime = sys.getTime(); thread checkLight(); } lightTime = sys.getTime(); light_ready_on is a global boolean, lightTime is a global float. Basically, the response script stores the latest systime that player was near the stim. The checkLight thread is this: void checkLight() { if (sys.getTime() - lightTime > 0.5) { $mylight.Off(); light_already_on = off; } sys.wait(.1); } Once the light is on, the checkLight thread wakes every 100 ms and compares the current time with the "last time the stim was fired". If it's more than a certain value, the user has moved away and the light is turned off. Completely untested. Also, the various timing parameters might have to be changed. But it's an idea.

Time to make a texture?

https://www.theverge.com/2021/7/15/22578783/valve-steam-deck-gaming-handheld-pc It's about time to play TDM on a 720p handheld Linux PC.

I do have a downloadable Precursor-style lamp in my Scripting thread, which uses trigger brushes to repeatedly activate a lamp to "keep it alive". As Obsttorte and joebarnin suggest you could also do it by defining a S/R radius, though I've used the trigger brush method to be able to define where exactly a lamp should switch on/off. The problem is that because of a TDM bug, AIs stop activating trigger brushes when they stand still, so my lamps can only react to the player.

And that's an evasive non-answer. Do you or do you not agree that "The Koran causes terrorism" involves the same logic as "Hate speech causes violence against minorities"? If you agree that they are the same, why do you support censoring "hate speech" but oppose censoring the Koran? If you don't agree that they are the same, what is the important difference between the two arguments which makes the first one invalid but the second one valid?

Ok, great. We're generally in agreement on that point. Books like the Quran and the Bible can tell their followers to do violent things, and some of their followers DO violent things, but we don't try to make the books illegal. Instead, we condemn the violence and we try to use reason to counter the violent messages. Why is that approach not also sufficient for "hate speech"?

This is exactly why I asked. I undesrstand the hesitation of changing existing entities, especially if you may have more than one of them in your map and the changed properties may not be suitable for all. For this, you have spawnargs that can be changed in DR (which I assume is what you meant with "but I feel mission authors should have to modify builtin stuff as little as possible. Thankfully this is usually the case already"). The player entity is a special case, because (as far as I know) it cannot be changed in DR. However, there is only one instance on the map, so any changes can only affect this one entity. And as you pointed out, on important advantage of changing the def-file in this case is, that creating a new entity may require you to change other references. Regarding your suggestion of overriding defs. The way you suggested cannot work, because you create a loop in the definition, in which the definition targets itself. And if you want to change the definition and keep the name, anyway, why use this intermediate step and not simply change the original definition in your map? I cannot see, why your way is norably different from it. Also, the way TDM handles def files is exactly designed in a way to support modification by map authors, with def-files in FM folders taking precedent over core def-files. This way you can change anything you want without affecting/compromising the core files. If you notice a crash or have any unwanted effects, you can simply delete the def-file in the FM folder and revert any definitions to their original form.

@duzenko It's fixed - by updating the intel gfx with the intel drivers at the Asus site. I had thought, since it was using the nvidia chip, that updating the nvidia drivers would be enough. But I guess that "GPU 1 -copy" also addresses the intel chip. Thanks, and I apologize for wasting your time!

Syberia 1 and 2 https://www.gog.com/giveaway/claim https://slickdeals.net/f/15162037-gog-com-pcdd-free-game-syberia-1-and-2 https://en.wikipedia.org/wiki/Syberia

Go Kurshok go Kurshok go!!!

Beta 4 testing thread is up for those willing to try it

Done in svn revisions 9447 & 16320

The location may not be exposed directly to the user, who does not need to care about which PK4 a particular image is in, but the underlying filesystem definitely has to keep track of this information, otherwise it would have no idea how to load resource files. It's not enough for the engine to know that textures/darkmod/blah.tga is "somewhere in the PK4 structure". It has to know exactly which PK4 and exactly which byte offsets to use when extracting the image data from the ZIP. Maybe not a full parser, but you would need some kind of parsing at least, even if it's just keeping track of opening and closing braces so you know where the definition begins and ends (so you can remove it if needed). You'd also need some basic handling of tokens so you know that the string which follows "map" or "diffusemap" refers to an image, although regexes might be powerful enough for this part.

The logical place for this would be either DR or the game itself, since both of these are already parsing the asset tree and know what they are loading or not loading in a particular map. Doing it in a standalone script is of course possible, but then you have to start from scratch with parsing entity defs, MTR files and the like.

I think what drives most of the large FMs to be as voluminous as they are is that they contain custom assets which don't get used. Mappers might try out various ambients before choosing one, download texture packs and only use some of them, re-export the same model multiple times and so on. In such long projects, assets come and go, and I think more often than not they never go. More major factors would be briefing videos, which can easily become gigantic if one isn't careful with the quality settings, and mappers not adhering 100% to conventions, i.e. converting as many .tga images as possible to more compact .dds or choosing a sensible resolution. Also, some compression programs (7z) seem to produce more compact zip archives than others (WinRar). Ironically, The Painter's Wife has just now been undergoing optimisations and trimming to bring the file size down. The lowest hanging fruit included checking for images and sounds that were never included in a definition, looking for assets that already exist in core TDM and downscaling oversized custom textures. More intensive methods included loading the FM without the custom texture folders to see which textures the game actually wants to load, according to the console. As a result, that particular FM has already been brought down from 550 MB to under 200 MB, and still has some ways to go, mostly just by cutting ballast. Loading times dont seem to have improved yet, but that might change once all the custom models are looked at (quite a few seem to have way too many vertices due to an exporter bug that was fixed in DR 2.9). Down by the Riverside would be another example. Some alpha packages of that FM weighed 150 MB, but that was trimmed down to 56 MB for the beta and release (i.e. by checking which paintings out of a custom paintings pack are actually used). So there's a surprising amount of potential for savings in FM sizes if an author is willing to put in the extra technical work of doing such trimming. Though I can understand if they'd rather just focus on polishing and releasing the mission after having already worked so long on it. In particular since there isn't really much in the way of tools to assist in the process.

Hard to follow up some of the recent screens people have been posting, but here's a little something for my beta testers to reassure them I've not forgotten about them! Part of a new area, really going for a natural feel with some pagan vibes, might be hard to notice but I've got some of @STRUNK's new bats flying around and they cast a great shadow in the moonlight as they pass by the cave opening (it's in the screen but looks way better in person!) Ignore the fps counter; I've got a misbehaving VP in the area.