Obsttorte

You could try func_damageable (not to be mixed up with func_damage!)

It needs health to be set to a value above zero, at least.

This sounds complicated

This variable could simple go into the missions main script as well as the function to be called to change the state of set variable. The weapon scripts can be found in the script subfolder.

This would require to tweak the weapon scripts that are used by the arrows. Note that the bow itself isn't a weapon using different arrow types as different ammuntion as one might guess, but each arrow type corresponds to its own weapon, simple sharing the weapon viewmodel with the other arrow types. The weapon behaviour was kept as it was with doom 3, where the player basically has all weapons from start on, but can only equip them if he has ammunition for it (if it requires some). For the behaviour you are aiming for you would have to create a global variable storing whether the player already found a bowincorporating a conditional in the 'draw weapon' function that, depending on the state of that variable when an arrow should be equipped, denying it if he hasn't found the bow yetcreate a little script that changes the state of the variable once a bow has been found

The window thing was an example To me this doesn't sound like he is aiming for something as complex as you suggest. I don't say your approach is wrong, but it is more time-consuming and should be worth it. Whether that is the case in this scenario I can't tell as I haven't seen the mission, but if the statue is only an eyecatcher in a location the player may not even has to visit, investing hours in a modeling program to get the look right might be a bit like taking a sledgehammer to crack a nut. My suggestion takes less then five minutes to implement, and if neon is unhappy with the result, he can still bring in the big guns.

You don't get an uniform color just by using the colored keyword. It works as a multiplicator, so it heavely depends on what you are using it on. For colored windows reflecting the state of the light in the room behind them it is actually more then suitable. In addition, you don't neccessarely have to use it on grayscale images only. Also, why are you talking about models in general? Neon was quiet specifically asking for glass (ok, on a statue, but still) and water. Especially in the later case it sounded like all he wanted was to change the color hue from blue to green. IIRC I've used the colored method on the statues in the chapel in my Old Habits rebuild, and noone ever complained on it looking artificial.

He was talking about changing the glass/water color only, not several colors on one model! And with your approach a new material/skin is needed, too. I don't really get your point here. :| I don't see how it will worsen quality if you color an existing glass material using the colored keyword, especially as there are already a couple of glass materials using it. The quality will be the same as with the standard, uncolored material. Your point is valid if you want to have better or different looking glass/water as shipped with the mod, but again, that wasn't what he was asking for. And even following your approach I don't see a reason not to use the colored keyword. The only exception would be if you don't want the material to be colored uniformly.

This is fine if you only need one new color, but if you want several ones or want to change it later on this can become a quiet tiresome approach.

Yes Yes The only precaution is that the material in question uses the colored keyword. Such materials are normally named _colored, _colorme or similar. In that case you can vary the color using the _color spawnarg.

I am using f.lux for quiet a while now, which may be of help until something changes in that regards (if it changes, of course). Although I have to admit that besides the practical reasons the dark look definetely has something to it.

I am not saying I am always happy with this. It's just the kind of inconsistencies one gets when several working on something every now and then with no clear hierarchical order behind that specifies the rules and concept. As you say, a fan project. The question is whether this or any other workaround justifies your needs or you (and preferable a few more people) would prefer a change beeing made. In the latter case all that is left is to convince the team to change it and someone to implement it

As mentioned above you can bind different mover types to each other and then bind the boat to this setup, and let it move along a spline. That's a bit messy for my testing, though, not to mention the movement will probably get a bit repetetive after while. If you use a func_mover (which you need for the spline movement anyways) it makes more sense to create the bobbing and swinging of the boat via script, which also has the benefit of randomizing it a bit more. It heavely depends on your specific use-case how complex the setup has to be. In regards to the player you can either bind a toggleable, invisible wall to the boat or immobilize the player while the boat is moving, so he doesn't fall into the water I would prefer the latter (easier). BTW: For the future it might be worth considering performance before and during your mapping progress, and not only towards the end. This way you don't have to fallback to such auxiliary solutions.

Short answer: yes.

Check the tdm_hud.gui file for popups. I am not sure whether there is any plan behind this. Often things got added to fulfill a specific need, but one doesn't always consider whether it makes sense as a concept as whole. Or it gets overseen. However, if you don't mind the door making the same noise when opening and closing, you can use snd_move.

Then you should check one of the missions of Goldwell iirc. He added secrets to one of his missions and everytime the player found one, a message like yours appeared telling the player how many secrets he has already found. Dunno the exact mission, though.

sys.println("your_text") allows you to print something to the console. It will be visible on screeen without you having to open the console everytime if you enter con_noprint 0 to the console. This what I do if I need debugging intel from my scripts. Your script looks good. Note that getFrobbed my also return the entity currently held by the player (e.g. is in his grabber) as it is also frobhilighted in this state. Depends on the usecase, though, whether this is important.

If the intention is that the player uses the inventory item by frobbing the world item (for this make sure inv_used_on_frob is set to true), then you could retrieve the entity it got used on by checking what is currently frob-hilighted. Or you go the other way round, use the frob_action_script on the entities placed in your map and let them check which inventory item is currently selected. See also here: http://wiki.thedarkmod.com/index.php?title=Inventory

I guess most players would expect the light state to be stored, as can be seen in the poll already. However, I voted "some other..." as I think it heavely depends on the situation/area. Mainly it should depend whether it is acceptable that lights get turned out via switches, like in houses or mansions where only those rooms are lit where people currently are. If the player is in an area where the lights should be all on (raising the question why there should be any light switches then), reseting them to beeing on makes sense. Another aspect to consider might be whaat makes more sense gameplay-wise, what also depends on the actual mission, I guess.

You don't need four additional versions of the statue model, you can just place the corresponding object at the proper position. In regards to the objects we already have hammers and swords, so those could easely be reskinned. I am not sure about the shepherds' crook and caduceus, though. Regarding the statue itself we have quiet some of them, so it may be worthwhile to take a look at them if you haven't already. Statue_torch_left or statue_torch_right might be fitting models, although the hand that could 'hold' the book looks the wrong way. However, it might be easier to change the orientation of that hand then to create a whole new model, and depending on lighting etc. it may not even be noticeable. In addition it is possible to keep an ai model in a static pose and reskin it either. On a gameplay note:

Can't you just put something heavy on your "move forward" key?

Amen

You can upload the images in your post directly, no need for external image services. You just have to make sure the file size is sufficiently low (gimp is your friend here). As we are talking about it. Was there any chance the upload file size limitation could be raised? I barely remember this being discussed in the past but forgot about the outcome.

Due to the way you are expressing it ... noone.

This looks impressive, indeed. Due to the sheer size and the tris count even on low stages it might be worthwhile splitting the model into several pieces. From how I've read it it sounds like it is only one big model. I am not sure this will be very good for performance if used in a mission where the size of the harbour as well as the level of detail fits the ship.