Tels

Am I right that the CM on the prop keys is only used for frobbing, because the key, when bound, is non-solid?

Rats!

Ah, good point. But maybe we should really set a "good" minimum distance for each object then instead of forcing everything at 35. (More work I know

Addendum: This is something that occured the last time I looked into that, but I forgot it in the meantime: The frob-box is seemingly located in absolute terms in the world, and not moved if the item is bound to something, but moved if the entity moves on its own. So, wouldn't it be easier to define the frob-box as "relative to the current world-origin of the entity", and then everytime it is used, to compute its current extends? That's certainly less work then to keep the frob-box updated all the time, just to query the actual box when the frob occurs. Frobbing events occur much less often than "entity origin moved" events. Might speed up everyting up a tiny bit, not having to update the hundreds of frob-boxes every frame. Edit: And another micro-optimization: If the CM is a box AND the box is larger than the frobbox, remove the frobbox after on entity spawn.

You are right, I meant "it might be _easily_ adjustable" with a hint of "maybe we should look into it" Right, as soon as I hit post, it occured to me that some code must always use the frobbox, but other code not, or even it checks both of them in some order. (Oh the joys of speculating without reading the code Hm, yeah, any case where: * the AI drops an item the player can pick up * the item has a CM that is smaller than the frob-box I can only imagine that a mapper might make custom prop items, and force the AI dropping it (by scripted scene?) and then the player can't pick it up anymore. Just removing the definition of the frob-box on the prop-keys would not fix this issue, however, as then you would still get at frobbox at 0,0,0 if the mapper defines one for his custom item. Oh, and that reminds me.. I did have a custom chain+ring made for the Swift demo level, consisting of two entities bound to each other. The newest version is only one entity, but that would be one of these special cases - you have one special entity bound to another (not nec. AI, think "button + elevator"). The "real" fix would be to always move the frob-box with the bound item. It would be more costly, but void any such side-effects. I'm all for the optimization, but we really should see if it doesn't have unintended consequences. (I trust you to think them through

Just throwing out ideas: But if the player can't move into a solid object, you can never get closer than the "per-object minimum distance", anyway. So why enforce in the code a larger "minimum" distance? It makes sort of sense if the object moves immidiately to that distance, the idea was probably so the player can "hold" important objects (readable whatever? small item?) closer. Not having these values set, but the code looking for the spawnarg is our "default design policy". If possible, make things configurable, even if we don't need it right away. That explains why the code is there, but the spawnarg unused. Now that the behaviour is changed, maybe we should change the "minimum distance" spawnarg to: * if set, use it * if not set, don't use it (instead of assuming 35 units). This might make more sense for the player observing how objects behave. And it still allows overriding and setting a minimum distance (f.i. for large or unwieldly objects like planks).

Thanx for the investigation and fix! The 32-unit cube might actually be adjustable - smaller => harder pickpocket, larger => slightly easier. But I'm not sure it really needs adjusting, we don't seem to have many complaints. And yes, I concur that having less collision boxes is better - although the code only uses one of them (either the frob-box, or the CM), anyway? I'm still trying to think if removing the frob-box from bound items will create problems in some cases. What happens for swords or other items attached to an AI? And is the frobbox restored when the item gets "unbound"? This doesn't happen for things the player picks up, but it might be for things theAI can drop, like the lantern? Edit: Or did you mean you simply removed the frob-box definition from the prop items?

I'm torn. Fixing the frob-box to move with the key is the correct thing to do, but pickpocketing shouldn't get easier. OTOH, *does* it really get noticable easier if the frob-box moves with the key?

Great, now you can rebuy the same game, again.

One thing that makes me wonder is the "min. distance" and once you scroll/rotate, it will move to the minimum distance. That would mean players could easily circumvent the minimum distance by just moving closer, but lose it once they rotate the object. Wouldn't it be better to not have the min. distance at all? That somehow feels awkward, to have the ability to get objects real close in some case, and not in some other cases. Otherwise, outstanding work! Btw, moveables should be placed flush with the surface - this avoids physics "bumbs", and artefacts due to floating objects like light shining between the cracks and the player being able to look through the crack. So adding 0.1 unit to avoid the "sink in" is a nice idea!

Sorry, didn't have internet for a few days, so I'm late. But I'd definitely change the "snap" to a "smooth move", even if it moves faster than normal. Snapping just looks out of place.

Is there another way? if so, I never knew.

I'm not sure the candle-stick/grab issue is something we should fix. It actually means there is some sort of "build-in" skill - if you know how, you can grab stuff silently, if not, you might get clatter. That makes things more interesting and a bit unpredictable, and also depending on the player skill, and not always "it automatically works". (It's abit like the "if you jump from high enough, it hurts, but if you crouch and then jump, it makes less noise.". Technically, the engine could ensure that it minimzes the noise by auto-crouching first. Might be a bad example, but you get hopefully my idea). Of course, if it is too annoying, we might improve a bit. The examples of the stones and the planks - well, the physics is quite whacky, and the weights are not well-adjusted. Me thinks these are sep. issues from the "grab stuff".

Maybe malware, backdoors, and the problem of finding the cracked version.

The "m4" package must be installed: sudo apt-get install m4 Then it gets further along to: Command line: BUILD='release' scons: done reading SConscript files. scons: Building targets ... scons: building associated VariantDir targets: build/release/core/glimp build/release/core build/release/game scons: building `game/precompiled_game.h.gch' because it doesn't exist g++ -o game/precompiled_game.h.gch -x c++-header -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/precompiled_game.h In file included from /usr/include/c++/4.9/typeinfo:34:0, from game/../idlib/precompiled.h:97, from game/precompiled_game.h:28: /usr/include/c++/4.9/exception:37:28: fatal error: bits/c++config.h: No such file or directory #include <bits/c++config.h> ^ compilation terminated. scons: building `build/release/game/game/randomizer/userintf.os' because it doesn't exist scons: *** [game/precompiled_game.h.gch] Error 1 g++ -o build/release/game/game/randomizer/userintf.os -c -fPIC -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/randomizer/userintf.cpp scons: building terminated because of errors.

Oh, so you try to help people and then die? Amazing...

No, not really. Although the trailer is done very well, I really can live without horror

http://www.wings3d.com/ Exports to common 3d file formats like .obj And it runs on linux, looks worth checking out.

The label seems to be Koka, whatever that is: http://m.killertracks.com/Browse/Labels/CD%20Listing/CD%20Details.aspx?cdId=7244 http://www.filmpartner.de/film/koka.htm http://www.koka.comredirects to http://www.unippm.fr/

Well, yeah, it is either some generic stuff, or something like this: Copyright is already bad enough, but ever since the "it is almost like it, so it belongs to ME - FOREVER" rules get watered down more and more, the tragedy of the commons affects the commons, well, more and more. It is very much like https://en.wikipedia.org/wiki/Midas- everything "they" touch turns to gold, for them at least, but is lost for the rest of mankind.

You can use: to reference the entities' script object. (The script object and the entity it runs on are the same "thing"). Edit: "self." is optional. "someFunction()" does the same. EoE. However, you need to make sure that the script engine knows what type of entity "self" is. It will allow only calls to methods that exist on that specific type of entity. You can "cast" the entity beforehand with: where methodName() is only available on "your_entity_classtype" but not f.i. "entity". See the Swift script code for some examples – I (ab)used the script code quite heavily in it

Some random link about water, rain and rendering: https://seblagarde.wordpress.com/2012/12/10/observe-rainy-world/ The blog is a bit hard to read, but good! Also: www.marmoset.co/toolbag/learn/pbr-theory

This trick should be put on the wiki - our FAQ is horrible outdated.

The table doesn't list all possible combinations, because the list is basically endless - everything your hardware supports would probably work in TDM.

There where a few discussions, but nothing has been decided yet. Some difficulty is that some spoken texts might have subtitles and some not ("hum", "whistles"), depending on wether it is "full subtitles (for deaf people)" or "subtitles for easier reading". The biggest challange is that the subtitle must be "per audio file", not "per sound shader" as some shaders have wildly different audio files in them.