kingsal

@Acolytesix All of the statues should spawn optional useful items. If it doesn't spawn something then this is a new bug. For the statues: I don't know which areas you are trying to get to, but you can access every place the apebeasts can. Try using vine or rope arrows or just explore. You should be able to get there.

@nbohr1more Hey thanks! I wasn't planning on updating this mission, but Ill definitely include this in the next ones and whenever I swing back around on this!

Ive seen this happen where the AI will be alerted during a conversation but wont take action until after the conversation loop is finished. This is usually from a build up of audio alerts. If they clearly see you they’ll usually stop. Just a heads up conversations and scripts can get pretty messy. Ive experimented with this is my current fm and its seems like any functions called directly to the ai ($guard.moveTo() for example) will happen after the conversation is done and as Dragofer mentioned you can’t always depend on a conversation being done… After my first mission I kind of learned to just design areas around conversations so there’s less chance of them being interrupted by the player. Making sure they start while the player has a good hiding spot, removing noisy surfaces and things the player might bump in to, and also trying to start the conversation before the player sees the AI so they don’t accidentally shoot them with an arrow or flash bomb them.

Yeah I'm sure its possible. For automaps we'd want some kind of tool in DR where the author can "draw" or select areas, label them, and then export those out as gui images. Those could then get rendered as transparents on top of the current in-game map OR just be exported as entire map images. The author would also have to label all their locations correctly and we'd need scripts to drive all that. This exists in some form already, but it would take a lot of thinking and effort to truly automate in-game map creation.

I dont think darkmod needs a mini map. Its not really trying to solve any problem and goes against so much of what makes the thief formula work. Although, I could see making better support for highlighted areas on the current in game map (this is possible now with some scripting but requires individual hand drawn maps for each change in area) It would be entirely up to the author to create the content for it and we would not be able to retroactively integrate it into current missions.

Thanks for the update man. Yeah I second going with something more neutral just a good ole 50-75 percent bright white light. I appreciate being able to see them in context though.

Uh no, but we still have forum rules regardless. These seem pretty reasonable and universal.

I think your missing the point. We don’t tolerate name calling and personal attacks regardless of how patient you’ve been. Clean it up, be respectful.

And this is how you choose to respond ? "You seem to have a peculiar cognitive disorder". "...it stands for Level Of Detail, and not Lights Off, Dumbass." Knock it off. This kind of language is destructive and harmful and has no place here no matter how much you disagree with someone.

That is very cool and very impressive! Right now it would be a lot of us to take it on for 2.10, but getting it in a mission would be awesome and prove out a bunch of stuff before going into the mod. I'll download this though and do some testing and play around with it when I get a chance.

Interesting, stuck arrows are not moveables. They inherit a weapon_arrow_base which is its own special thing. I was referring to general moveables (crates and the like) will keep their collisions meshes even when their physical models are hidden. Although thats not to say there aren't bugs that could occur here. I could see an arrow appearing and disappearing, but dropping to the floor is pretty odd considering they are bound to the entity they are stuck to.

That shouldn't be happening. Out of curiosity does the model or its LOD have a collision mesh? This won't happen to moveables AFIK since their collisions meshes are kept.

The color is not hard coded into the particles, it comes from the texture map which then gets "tinted" by the entityColor argument in the .prt. So we need to create grayscale maps for all the associated particles, which I've already done. This method doesn't require explicit color defs like you have (red, green, blue, pink). Yeah so this is done with a "set _color on flame" "1.0 1.0 1.0" Basically telling attached object named "flame" to have _color set to 1 1 1. Dragofer and I are looking into a method using the script object for light holders to colorize the FX and even model skins. This way *any* light object with an associated flame can be colored as well as the models glowy bits. Glowing candle wax or fire embers for instance

Having colored lights is a great idea! As Dragofer mentioned we are looking into ways to make this as customizable as possible. I've made some progress and have colorable candles, torches, ect that will pass their color to their particle effects. I'm going to look into some other stuff and then I'll post up what I have.

I use a ton of bounced lights as well, even in large spaces. Its true they can really add up if you arent careful, but at least in my case turning them to noshadow is what keeps the frame rate from tanking Also from my understanding its moreso about the amount of surfaces those lights touch. So if you have 2 direct lights and 2 bounced lights on a pile of objects, there will be a noticeable drop in perf. I can't say that turning those bounce lights off will be less noticeable, in fact it might be the opposite in my case. I guess it all depends on how the author uses them.

Right on, thanks for the clarity. Yeah it looks like just reducing object count /light interactions the good ole fashion way will have the most impact. Ill see if I can put something together.

Yeah this is tricky, frivolous shadow rays *used* to be a big issue, but with all the renderer and GPU updates maybe not? I wonder if transparents, alpha tests, and FXs are bigger culprits now. Having a light touching a glass window with fog and trees behind it might be a worse case scenario. Would switching to a "less expensive" lighting model at a distance be beneficial or even feasible? Are there less accurate, but cheaper lighting methods outside of just shadow/ no shadow? What about texture resolutions? Would rendering less pixels at distance do anything for us? Sorry just kind of troubleshooting here. @MirceaKitsune @duzenko I think the proper approach here would be to open up a heavy map like TPW or the opening shot in your FM Mircea, and look into the impact lights, emitters, transparents, ect are having on it. I'm sure turning off lights will have an impact, but doing it in an elegant manner might not feasible. I'll look into this a bit more this weekend and see if I can really prove that dropping lights out can A: give back enough performance in enough situations to warrant the change and B: actually be done in such a way that isn't glaring to the player.

Got it. Regardless we should be able to get light models to hide if not the lights themselves.

Yeah its possible that lights are harder to do, but maybe more feasible in a dynamic-only light engine like doom 3.

Also we should probably discuss light clipping and lighting techniques in a different thread as that's own can of worms. @duzenkoSo for the hide_distance stuff it looks like these things would be helpful to add to the list: Func_rotating and other movers? SEED (more so investigate why they aren't working properly) Lights, specifically entities that spawn lights and FX. If we can get a gentle fade out / in on all those things that would be incredible. Basically we'd have an industry standard system. I can see lots of cases where gradually dropping out lights and objects at distance will significantly help performance on larger maps or outdoor areas. Also being able to fade out FX when you get close to them is valuable for stuff like fog. This helps prevent "washing out" the screen when you get close to an emitter.

Yeah you might be able to use a spot light, but that wont work for most of our custom light entities which use volume lights. There are definitely ways around this problem. My point it is they are fiddly and time consuming and in some cases require specific engine knowledge. It might be easier for a mapper to just hide that light at a distance or yeah draw some kind of clipping volume.

@peter_spy Yeah so I had to turn off a couple things to get it to work, new front end renderer and obviously use stencil lights. You might also have disable uncapped FPS. @duzenkoNo unfortunately you cant clip light volumes in that way. You can move the volume to fit the space so it doesnt go outside the wall and then adjust the center. However, thats pretty time consuming and it wont work for lights that spawn and attach things to their entity origin, torch flames for intance. A lot of authors use the custom light objects that automatically def_attach lights and FX, so those rely on the center and origin being the same. it would be pretty useful if we had a kind of brush that just acted as a light clip volume that stopped the shadow rays. It would give us more explicit control for sure.

Edit: Keep in mind in the top image, the light debugger is showing where the light is bleeding through so thats why you see the back wall illuminated.

Okay so Ive updated the test map to reflect this. Maybe this isn't an issue with shadow mapping, but I dont know. Dmap and then load it up lodfade.map So this is the common scenario. A light inside a closed portal is still bleeding through the walls and shadowing the boxes on the outside of the building. Obviously if I add a door we won't have this problem, but this isn't always feasible. In complex spaces this happens a lot. Now if I could just hide that light at a certain distance I can eliminate that problem. There might be other ways to fix this problem, but once again in complex spaces (which are most city missions) this happens more than you would think. Its not a systemic solution, but it could give mappers more control.

Awesome for mappers, as it will give us another avenue for controlling light count and performance. Ill agree that its an edge case, but if we are supporting lights with models hiding or fading out a distance, street lamps for instance, wouldn't we need code to turn lights off anyhow?