Tels
-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Posts posted by Tels
-
-
I don't think that could work... There's a chicken-and-egg problem. Frob boxes have to be independent of their parent entity, because they help the game identify which entity the player is looking at. So you don't know which frob boxes need to be "used" in a frame until you know which frob boxes are in the player's line of sight that frame, which you don't know until you know the world coords of every frob box.
Rats!
-
Because of planks, and other awkwardly-shaped moveables. You might pick them up at a certain distance without their intersecting your head, but as soon as you start to rotate them, that distance might not be enough.
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.
-
It's adjustable using the "size" spawnarg. Personally I think keys should be a bit less easy to steal than they are -- the CM is half the size of the AI that's carrying the key! -- but I won't start a campaign about it
You are right, I meant "it might be _easily_ adjustable" with a hint of "maybe we should look into it"
I hadn't spotted that... Although, at least some of the code must be using both collision models: the original bug that started this discussion was: you can pickpocket keys from AI from two places in the map.
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
The frob boxes for things attached to AI are always in the wrong place, so removing them shouldn't cause any problems. No, I haven't added code to recreate the frob boxes when an AI drops an item. I can if we think it's needed.... I couldn't think of any realistic circumstances where we'd want that to happen, although as I say that I can imagine a TDM dev in 10 years saying "I found the bug! frob boxes get destroyed on binding but not recreated when unbinding!".
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).
-
No, it turns out that it won't get easier if the frob box moves with the key. I've since discovered that prop keys (meant for def-attaching) don't depend on the frob box at all. The frob box is irrelevant. Prop keys have a 32-unit cube as their collision model, instead of a precise collision model derived from the visible model. That 32-unit cube would swallow the 10-unit frob box completely even if the frob box could move.
I've already committed a fix for the mislocated frob boxes: remove the frob box from any entity that gets bound to an AI or other animated entity. That's still probably the right thing to do given that (1) those misplaced frob boxes are bugs, (2) in general we want to reduce not increase the number of moving collisioin models for performance reasons, and (3) we have another way to make pickpocketing easier -- using enlarged and simplified collision models for attached items like happens with keys right now. But it's up for debate.
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!
-
The snap to position is the same as it is now. It probably looks worse because I'm grabbing things that are so close in the vid. But we could have the item glide smoothly into position rather than snap if we want. And we could try shortening the min distance, but there could be some larger moveable items that then clash with the player at min distance. Those would need identifying and they'd need bespoke min distance spawnargs.
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.
-
Does everyone use the mousewheel for moving held objects back and forth?
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".
-
Yeah, if you're going to ignore the licence and use this software illegally, why bother with CS2 when you could download a cracked copy of the latest version and get all of the new features while breaking the exact same laws?
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...
-
You might heard of this awesome looking horror game, which featured a great actor and an awesome cast of developers. Sadly they put it down lately because of some intern d***-measuring contests... Nothing for me, I want this game to be done!
If you want, you can watch the trailer video or sign this very cool petition ("Would you please sign my petition?" -"Okay.") Thanks for your support
The world needs more horror games!
No, not really. Although the trailer is done very well, I really can live without horror
-
Exports to common 3d file formats like .obj
And it runs on linux, looks worth checking out.
-
So, plan on contacting Killer Tracks?
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/
-
That does sound very much like one of our ambients though. However, the Killer site says copyright 2012? Our ambient has been around since at least 2009, probably earlier.
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:
self.someFunction();
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:
your_entity_classtype variablename = self;
variablename.methodName();
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
-
type in terminal
sudo apt-get install libtxc-dxtn-s2tc0:i386
to download 32 bit version of s3tc. It won't show up in synaptic for some reason.
This is as far as I got to get past the blank menu screen. Your next problem is the ridiculously low fps and stutter.
I never knew how to get past this without installing proprietary drivers.
If you're stuck b/c of the low fps or blank screen, just hit the tilde key (~) and type quit to exit.
This trick should be put on the wiki - our FAQ is horrible outdated.
-
1
-
-
Whoever is in charge of the http://wiki.thedarkmod.com/website needs to update the resolution page cos my 4096 x 2304 16:9 4K resolution isn't on the page as being a custom setting. The options only go up to 3840 x 2160 for a 16:9 custom setting on that site.
The table doesn't list all possible combinations, because the list is basically endless - everything your hardware supports would probably work in TDM.
-
That's a huge heap of work you've got done there!
Has there been any discussion yet how to implement the subtitles, or do we have an established method already? There are easy ways to get text at the bottom of the screen, so it shouldn't be too difficult technically, but it might need a code tweak unless there's something already built in to the i18n system.
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.
-
1
-
Should pickpocketing keys be easier?
in The Dark Mod
Posted
Am I right that the CM on the prop keys is only used for frobbing, because the key, when bound, is non-solid?