kingsal

Thanks guys I am glad you like them! The plan is to do a campaign of about 6 or 7 missions. I have 1 more “big spawler” in the works, but generally Im trying to keep them a little smaller but more polished. My only real goal is to just not make the same mission twice, so probably wont do any more giant cave systems 3 and 4 are pretty close to being done and Ilm going to release them together, hopefully end of this year beginning of next year depending on my work schedule.

Yep Volta 3 and 4 are coming! I can't say when exactly because I'm pretty busy IRL, but they're getting pretty close!

Yeah if the lighting is too bright or too dark, some of the cues can get lost. Also the AI's patrols and the encounters slow the gameplay down and force the player to familiarize themselves with the area (in theory). Although I still think I went a little too big and too complicated given the objective and intentions of this mission. Some players dig these giant open underground missions and others don't. It was hard for me to find that balance, tbh. Looking back at it, I probably should have done more testing and got feedback earlier in the design process.. Lessons learned I guess

Well yeah, but to answer your question again. The cvar does not solve the problem, but creates another. EDIT: but to be clear, the cvar is the lesser of two evils imo.

Good to hear, i didnt know about this spawnarg but if it hides those items then thats a start. Although as Cabal said i think it looks weird and broken when it occludes half the object.

@duzenko There are plenty of examples. Its not likely to "break" a mission, but its going to reveal things the author intended to hide. Its like having xray vision in some cases. I was actually talking about an unreleased mission, but I checked volta 1 and found a couple examples: For my own missions im not *that* concerned with this, but its an unintended consequence and in my mind can break immersion and in worse case mess up the author's intent.

@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.