Obsttorte

The C++ coloring is already pretty good considering how close those languages are to the script language. I am not aware of any keyword or syntax related stuff in the scripting language that is not part of C++, so I am not sure whether there is much to gain with a custom coloring scheme.

@datiswous: Argh, typo. I was in a hurry. Corrected.

The bits are the digits and the byte the whole number (a bit simplified). It basically means that you use a number of which each digit represents a specific state. Similar to how they work in everyday life, where each digit corresponds to the amount of different numbers (ones, tens, houndreds, ...), just that now they stand for different keys. But as stated this level of abstraction is not needed here. Yes, but it is mostly 6 grade maths I dunno if it is bokers, as it depends on what you are trying to achieve. I think I just don't understood exactly that. My interpretation of what you have written was that one key (22) opens door A, the other (47) door B, but having both (69) also allows to open door C. The last part doesn't make sense to me, so you probably meant it differently. Just for learning sake as you implied: The bit approach would be like one key is 10, the other is 100. Having both corresponds to 110. But it also works the other way round, as there is no other combination of keys that lead to that number. Or more in detail: Say you have 4 keys. key 1 corresponds to 1 key 2 corr. to 10 key 3 corr. to 100 key 4 corr. to 1000 So depending on which digits are nonzero, you can exactly say which keys the player possesses. Is the number 1011? Then he has key 1, 2 and 4. The power of two stuff comes into play as computers use binary numbers, not bundles of tens. The math is the same, though. The number bundled is completely free to choose, has not always been ten in the past (just think of the clock or the names of the numbers) and is only ten nowadays because we have ten fingers.

@Dragofer: I don't really see the issue here, actually. As mentioned above, if you really need to know whether the player has an item, you can either setup the item so that it leaves a note (what I suggested with the world entity) or use the objectives system. But the first approach is already pretty straightforward. What are you looking for that cannot be achieved with the suggested method. That is probably necessary for the ai to be able to detect whether something has been stolen. In addition, entities that appear the same to the player doesn't have to be coding-wise. The flashbomb lying around for you to pickup, the one(s) in your inventory and the one that you throw to blind your foes appear all the same to the players, as they would be in the real world, but from a programmers perspective they aren't.

That is the right attitude

@datiswousTwo thoughts (or cents, so to say): As @Nort stated, the usual approach is to use bits if it is just about whether a key is present or not. So each key would be represented by a power of two. I don't really see why the player should be able to open door 69, just because he can unlock 22 and 47 (as in your example, which I probably misunderstood). The reason for the bit approach are to not waste unnecessary resources. The downside is, that it is a bit abstract. And as this will not hurt performance a lot, the bit approach is not necessary here, though. Stackable items are items like flashbombs. Note, that even though there appear to be several entities in the inventory, it is actually only one. Using it, will decrement the counter, and if it reaches zero, the item gets removed. You can obviously not differentiate between objects if it only one. Now, how will one go about this?! The most straightforward approach is, that if the player frobs a key, it gets removed (not added to inventory!) and a spawnarg is set on the world entity, denoting that the player has the key. Note, that if you readout a spawnarg on an entity that has not been set, it will return 0. So we just add something like "name_of_key" "1" to the world entity. If the player frobs a door, the modified version of the script will readout that spawnarg which is either 0, if it hasn't been set as the player hasn't picked up the key yet, and the door stays locked, or 1, which will lead to the door beeing unlocked. So basically two script functions: // the frobaction script used by our keys void frob_key(entity key) { string name_of_key = key.getKey("inv_name"); $world.setKey(name_of_key, "1"); key.remove(); } // door script void advanced_frob(entity door) { if (door.Locked()) { float unlocking_key = door.getFloatKey("used_by"); if (unlocking_key) { door.ToggleLock(); } } else { door.ToggleOpen(); } } This is without the lockpicking mechanism. I would have to check, whether the immobilization is still correct (as stated above, the number confuses me). Note that this is untested code that came to my mind. It probably includes wrong written stuff and has the potential to destroy the universe. Use with caution

IIRC the default setup is to attach an entity (like an apple) to the ai, which then overrides the respective animations. EDIT: It seems there are no such props defined for food, although there is a wine bottle prop and I though I would have seen eating ai in the past. Probably mappers set the up on themselves everytime, which is cumbersome. So yeah, having some of these might be useful.

This is a mapper decision. By default, doors do not close automatically. However, it is possible to set the to do so and normally used in haunted mission (because it is spooky ) For the rest, like @AluminumHaste said. If it is easy, why don't you do it yourself. If you can't do it yourself, it maybe isn't that easy

FYI: Issue #5678 has been resolved with revision #9926. The end mission statistics now display the total amount of items that could have been pickpocket by the end of the mission. Note that this is no static value. If an ai is taken out by the player, taken the items from the body is not counted as pickpocketing and therefore is not counted to the total value. So depending on the playstyle, this number may vary for different players/playthroughs. Left is the current, right is the future stat screen.

As per request of @Dragofer I've updated the shader work from this post. The image manipulation takes place in the fragment shader gl_overlay.fs and can be tweaked as needed. I haven't found a way to pass arguments via the gui to the material to allow on the fly alterations, so the effect is static. gl_overlay.pk4

You are welcome.

Oi. I couldn't find a bugtracker entry for this, so I created one (#5967) and was so free to provide a solution (revision 9925). I have added a script function on the player that allows to turn the notifications on and off. The function has no return value. //turn the notification (sound + text) off, using a nonzero value turns them on again $player1.setObjectiveNotification(0); This works for "objective completed", "objective failed" and "new objective". Hope that's what you are looking for.

This has been discussed back then (note that the tdm version used in the video is 2.01, the video is 8 years old). The conclusion was that the majority of the users share the opinion expressed by @Nort. Mappers are obviously free to use such setups in there fms. Also, it's mostly been common to not add features for the feature's sake. And this isn't something that is better per se. In some type of missions having to search for the correct key might even improve gameplay (horror missions for instance).

It is, the printable version of this wiki section is 19 pages long!!! I mean, it's doors. If that needs such a wall of text to be explained, you probably need a whole book to describe optimization.

@datiswous It's a dirty hack, to be honest, as it was just a proof of concept. Basically there are two things going on. 1. An infinite loop, that takes care of clearing the inventory if the player is not looking at a door. 2. An alternative version of the frob action script on the door that takes care of finding the correct key in the players inventory and switching to the lockpick, if the correct key is not in the players possesion. As stated in the video this setup works with one lockpick. But due to the minigame in TDM having several picks is nonsense either way and only present as it was like that in the original games. These are the scripts (this stuff is actually still lying around on my harddrive ) : 1. Inventory clearance (switching away from the lockpicks (this is to disguise them in the inventory, as the player doesn't have to use them actively) void test() { while(1) { if ($player1.getImmobilization("")!=2048 && $player1.getCurInvItemEntity().getName()=="lockpick") { $player1.getNextInvItem(); } sys.waitFrame(); } } Immobilizations are set by the game if the player is doing something specific, normally to somewhat restrict his moving capabilities (e.g. making him slower). From player.h // Player control immobilization categories. enum { EIM_ALL = -1, EIM_UPDATE = BIT( 0), // For internal use only. True if immobilization needs to be recalculated. EIM_VIEW_ANGLE = BIT( 1), // Looking around EIM_MOVEMENT = BIT( 2), // Forwards/backwards, strafing and swimming. EIM_CROUCH = BIT( 3), // Crouching. EIM_CROUCH_HOLD = BIT( 4), // Prevent changes to crouching state. (NYI) EIM_JUMP = BIT( 5), // Jumping. EIM_MANTLE = BIT( 6), // Mantling (excluding jumping) EIM_CLIMB = BIT( 7), // Climbing ladders, ropes and mantling. EIM_FROB = BIT( 8), // Frobbing. EIM_FROB_HILIGHT = BIT( 9), // Frobbing AND frob hilighting (not sure if needed or if EIM_FROB can disable hilight also) EIM_FROB_COMPLEX = BIT(10), // Frobbing of "complex" items (not a door, lever, button, etc) EIM_ATTACK = BIT(11), // Using weapons EIM_ATTACK_RANGED = BIT(12), // Using ranged weapons (bows) EIM_WEAPON_SELECT = BIT(13), // Selecting weapons. EIM_ITEM_USE = BIT(14), // Using items EIM_ITEM_SELECT = BIT(15), // Selecting items. EIM_ITEM_DROP = BIT(16), // Dropping inventory items. EIM_LEAN = BIT(17), // Leaning }; Dunno if the numbering has changed or the logic is a bit different, but immobilization 2048 refers to one of the frobs (but it is two to the power of eleven, so I am a bit confused here, one would have to test if it is still valid). The frob_action_script on the door (you have to set that via the respective spawnarg): void advancedDoorFrob(entity door) { if (door.IsLocked()) { $player1.setCurInvCategory("#str_02392"); $player1.setCurInvItem(door.getKey("used_by")); sys.waitFrame(); entity key=$player1.getCurInvItemEntity(); if(key==$null_entity) { $player1.setCurInvCategory("#str_02389"); $player1.setCurInvItem("lockpick"); } else { door.ToggleLock(); } } else { door.ToggleOpen(); } } The code basically switches the inventory item to the key used by the door currently frobbed. If such a key isn't present in the players inventory, no item will be selected (aka null_entity) and we switch to the lockpick. Otherwise the door will be unlocked. This only happens if the door is still locked, though, otherwise it just gets opened/closed. In all honesty, I would prefer a different implementation nowadays, but this gives you an impression of how this can be set up.

The entity you are searching for is atdm:froblock.

@NortThis might help http://old.mrhide.fr/doom3/guis.html

Mappers can manipulate the levels at which state changes happens as well as the ai's acuity in regards to visual, acustic and tactile stims. And this is the case since I joined the forum over ten years ago. Obviously, different mission require different setups due to the differences in geometry, average distance and lighting etc... to work optimal, but unfortunately most - if not all - mappers don't bother with this 'technical' stuff. An easier way would probably be to alter the gui files. Images can be toned down there and the toning factor could be a variable, so it could be turned into a setting adjustable via the options menu. It would also allow to alter the factor based on the lightgem value so that the readables are brighter if the player is in a well lit area and darker if he is standing in the shadows (which sounds kinda cool now that I think about it).

This is actually not true. The reason I wanted to implement this was to allow mappers to modify the gameplay in a way that causes players to actually risk something and for different kinds of overall gameplay. As I had tried to explain back in the uproaring discussion as you named it was that there was no intention to use this as a method to increase difficulty, as there were already other means to achieve this. So although using this will increase the difficulty, mappers can always outweight this by reducing the difficulty via other aspects (ai sensibility, lighting, equipment et al). Unfortunately this wasn't understood back in the discussion with the team members nor later on when discussing it with mission authors, as your comment illustrates. Dunno if this is some sort of language barrier or whether the opposition to ideas differing from the original gameplay caused this confusion.

I've played around with a throw-hook in the past. It basically consisted out of a hook with a rope attached to it. The issue was the physics. IdTech4's physics calculations are pretty rudimentary and not very stable. If an object with an ragdoll (like the rope) attached to it becomes too fast, the attachment gets interrupted (the console literally stated: "Too fast, letting go" :D) Iirc the limit was about 128 doom units per second. An arrow is way faster. The problem is of course that if the hook is too slow, you cannot throw it very far, unless you manually keep the speed high via scripting to bypass that, which would look unrealistic, though. Maybe there have been tweaks made to the physics engine that lessen these issues, as it's been years when I was working on this. In difference to that approach an tightrope arrow doesn't need to be that dynamic. However, a proper animation would be needed unless you want the arrow to magically appear once the arrow has hit its target. Another issue is, that in difference to the current rope arrow, that chooses the length of the rope out of four possibilites depending on the space available, a tightrope arrow would have to relatively exactly fit the length between two points, which could become hard to achieve.

One side of the exit location brush is textured with caulk, maybe that is the issue. Btw.: iirc if you set ongoing on the exit objective you don't have to use the enabling objectives logic, as the objective will only tick off if all not ongoing visible objectives have been completed. Could be worth a try, too, if the caulked surface isn'T the source of your issue.

I guess we can agree on that. and I don't think it is very helpful to boil my comment down to morality play. I haven't had any morality in mind when posting my comment. It is a simple fact that disallowing certain modifications per se restrict the mappers. There might be good reasons to do so, but those should then be brought up to the mapper once necessary, and the mapper should have the choice to decide. That's what beta tests are intented for. That might be true. But players can only modify the game to the degree that they are allowed to via the settings menu, unless you expect the average player to fiddle with the files shipped with TDM or a fm. And in the latter case the player would not be able to modify it more then the mapper can. So I don't really see the point here. We are not talking about player versus mapper modifications.

May he rest in piece. Condolences to his friends and family. He has definetely been a column for this community and the mod and a helpful and kind person throughout. I can't tell how much I have learnt from him, especially in my beginnings, and I bet I am not the only one. May he and his work be an idol for us.

I have to say that I share @peter_spy's opinion on this matter. Even though frob hilighting is part of the ui, that is very well part of the artisitic design of a mission. Screen resolution or fps are not, therefore the comparision doesn't make much sense imho. It is odd that on the one side it is often stated how important the respect towards the artistic choices and mental property of the mappers is while on the other side they get restricted in how to shape their work. It makes sense to have a standard, and if it is customizable by the player that's fine, too. But a mapper should have the choice to alter that if he or she considers a different approach more suitable. Especially considering there is no harm done as it will only affect the autors mission. In addition: who is "the majority"?! I can only see roughly half a dozen team members having discussed this matter. I am pretty sure the team consist out of more then just those few.

Nuff said.