Next-Gen Candles

[Springheel]

Ok, I've (finally) finished the improvements to the candle entities.

 

The texture of the candlesticks themselves pulses and flickers when the candle is lit. There are 3 different skins, and each one flickers at a different rate; this allows mappers to put batches of candles together without them all flickering in unison.

 

I was getting a little bored seeing the same candleholders all the time, so I added a new chalice one, which has a few different skins.

 

There are regular candles and wide candles with three heights each. Each holder has a default candle and a short candle version (with 3 'flicker' skins each)

 

Frobbing any of these candles will pick them up. Hitting "use" will then extinguish them (angua has identified a bug where hitting "use" again will teleport the candle into the grabber, even if you've already dropped it).

All the candles should be lightable by fire sources.

 

I've moved the old candles to a separate editor folder (candles/originals) as mappers may want the glare or colour options of those candles. I modified their entities so that they should also have the "use = extinguish" behaviour.

 

Eventually I'll get around to addressing some of the wall candle entities, but this is probably all I'll do with candles until after the release.

 

There are 1150 lines of entitydefs to make these new candles, so I'd be surprised if there isn't a typo somewhere. Let me know if you find any that aren't working.

[Tels]

Nice work!

 

The models look much more believable. Do they use the same "candleflame" entities as before?

[Springheel]

The models look much more believable. Do they use the same "candleflame" entities as before?

 

I made new entities for most things, though they inherit the same base as the other candles.

[Tels]

I made new entities for most things, though they inherit the same base as the other candles.

 

If they just inherit the old base and don't set any new values or spawnargs, they (the entities) would be better just using the old baseclass - otherwise we clutter up the entity class tree with "empty shells" and people will wonder what the difference is between class A and B_inherit_from_A.

[Springheel]

If they just inherit the old base and don't set any new values or spawnargs, they (the entities) would be better just using the old baseclass

 

Yes, obviously.

[SneaksieDave]

Have only had time to take a quick peek at a small handful so far, but they're looking good. I'm quite happy to not have the confusing, "will this pinch it out, or pick it up?" apprehension from frobbing anymore; the extra step of frob and use to pinch out (which can be done quickly) is well worth it.

 

I notice these don't play the hiss extinguish sound or show the smoke particle upon extinguish. Is carrying that over planned as well?

 

Edit: this stuff:

"editor_model model_extinguished" "Set to the model name the light should display when just extinguished (usually a steam particle)."

"editor_snd snd_extinguished" "Sound the light plays when just extinguished."

"editor_var ext_hide_delay" "Seconds to wait before hiding the model after light is extinguished. This should be long enough to insure that the extinguish particle and sound play to completion. Default is 10 seconds."

(more?)

 

Edit: Hm, I notice that candle+holder combos have separate frob highlights (candle is one, holder is the other) although frobbing either has the same effect -- lifting the candle.

[Springheel]

I notice these don't play the hiss extinguish sound or show the smoke particle upon extinguish. Is carrying that over planned as well?

 

I'll have to check that--I'm pretty sure the right spawnargs are present. Do they play the sound when you use a water arrow? It's possible the "use" behaviour isn't triggering the sound.

[SneaksieDave]

Ah, you are correct. The sound and smoke particle play for water arrows, but not pinching. This tickles a memory; @Tels was this a problem in the original use functionality?

[Ishtvan]

The texture of the candlesticks themselves pulses and flickers when the candle is lit. There are 3 different skins, and each one flickers at a different rate; this allows mappers to put batches of candles together without them all flickering in unison.

Regarding the flickering in unison, isn't there a way to add "phase diversity" in the material definition for the flickering? That is, they flicker using some repeating lookup table (intensity vs time), but I thought there was a standard way in D3 textures to create a random entry point into the table so that things didn't ficker in unison?

[Springheel]

There may be but I'm not aware of one. D3 also had multiple versions of their candle textures (same table, but slightly different speeds), and I assume it was to address the same issue.

[Ishtvan]

Hmm, that's weird, D3 is usually pretty good about adding random offsets to periodic stuff like that. Maybe some of our graphics gurus know if it's possible or not.

[Tels]

Ah, you are correct. The sound and smoke particle play for water arrows, but not pinching. This tickles a memory; @Tels was this a problem in the original use functionality?

 

Yes it was and I never figured out why, they "play" (I added debug print statements before the calls) but are not visible/audible for some reason.

[Tels]

Hmm, that's weird, D3 is usually pretty good about adding random offsets to periodic stuff like that. Maybe some of our graphics gurus know if it's possible or not.

 

http://www.iddevnet.com/doom3/materials.php

 

doesn't mention random values, though one could use "sound" maybe, but then we would need different entities with different sounds (or rather "starting positions of the same sound").

 

What one also could do would be to add a small script that includes a delay?

[SneaksieDave]

Yes it was and I never figured out why, they "play" (I added debug print statements before the calls) but are not visible/audible for some reason.

Could it be because the object in question or links are destroyed? (I don't know if they are; just putting it out there.) Or the opposite, there's a race condition (is that the correct term here?) where they are attempting to play before they are fully created or initialized?

[Tels]

Getting back to the new candle models:

 

* It looks now we have each candle entity twice (e.g. the old and the next-gen candles). Yuck!

* Someone deleted the old models like models/darkmod/lights/extinguishable/candle1.lwo, but didn't add entries for replacements into fixup.txt - which means that for instance now SL map is broken, but I do not have an automatic way to fix it. Yuck again!

 

Seriously, we need to clean up this mess before release and stop creating more instead!

[Springheel]

It looks now we have each candle entity twice (e.g. the old and the next-gen candles). Yuck!

 

I didn't delete the old entities because they do things the new ones don't (can use the color spawnarg and have a particle glare) and some people may wish to use them. The old ones have been moved to the "originals" folder in the editor to avoid confusion. There shouldn't be any duplicates of anything, however.

 

Someone deleted the old models like models/darkmod/lights/extinguishable/candle1.lwo, but didn't add entries for replacements into fixup.txt - which means that for instance now SL map is broken, but I do not have an automatic way to fix it. Yuck again!

 

I deleted the some of the really old candle models that aren't in use anymore. I should have added them to fixup.txt for older maps, however--mea culpa. Of course, the St. Lucia candles have to be replaced with updated entities somehow, not just swapping the models (or else they'll all be empty holders).

 

Seriously, we need to clean up this mess before release and stop creating more instead!

 

I hope that's not directed at me.

[Tels]

I didn't delete the old entities because they do things the new ones don't (can use the color spawnarg and have a particle glare) and some people may wish to use them. The old ones have been moved to the "originals" folder in the editor to avoid confusion. There shouldn't be any duplicates of anything, however.

 

Okay. But it makes things much more confusing for mappers, they now have to sets of candles to choose from...

 

I deleted the some of the really old candle models that aren't in use anymore. I should have added them to fixup.txt for older maps, however--mea culpa. Of course, the St. Lucia candles have to be replaced with updated entities somehow, not just swapping the models (or else they'll all be empty holders).

 

Er yes, someone should really start on SL *curses his weak laptop*

 

I hope that's not directed at me.

 

No just at the general population. The new candles *are* nice, but they also created a lot of work and problems while we still have fundamental other problems unsolved - at some point we need to start to focus

[Springheel]

Okay. But it makes things much more confusing for mappers, they now have to sets of candles to choose from...

 

Most mappers will not delve into the "originals" folder to begin with, but if they do, they will see from the editor text that those candles allow color keywords (and look different). If you think that's too confusing and want to remove the original candles (and deal with all the maps currently using them), feel free.

 

No just at the general population. The new candles *are* nice, but they also created a lot of work and problems while we still have fundamental other problems unsolved - at some point we need to start to focus

 

You're right. Why on earth didn't I think of that?

[SneaksieDave]

I haven't looked into these so the answer might be really obvious but: can the new ones be made to support skin color changes too (easily)? Glare versions could be made easily enough and then we could truly remove the originals and have no confusion. If a map uses the old ones, sorry, but this is an ongoing process...

 

Edit: in fact, even just a single or small handful of demonstration next gen ones with color skins and particle glare would suffice, and allow the originals to be removed IMO. As long as users see what exists and can be done, they'll fix up what they need.

[Springheel]

If a mapper really *wants* a tall, skinny yellow candle with glare, I don't see any reason why they shouldn't be allowed to use one. But as I said above, if people want to strip out the originals, feel free.

[SneaksieDave]

I mean, can the next gen ones be made to support the color skins easily, or are they set up in such a way that it won't work? That and the glare. If even one demonstration next gen candle is set up with skins and a glare, users will see how it's done, and then the originals can be removed.

[Springheel]

I don't know how easy or difficult it would be to add the colour keyword, but I suspect it would require modifying the original image files, which I'm not interested in doing. And glare I specifically removed because it was responsible for the main effect I didn't like on the old candles--that being the fact that the glare is a single plane that rotates around and visibly bisects the candle as the player moves. I tried several alternatives but nothing worked to my satisfaction.

 

I guess what it comes down to is that I'm pretty satisfied with these candles, and don't plan on putting any more time into this (barring fixing any bugs that have yet to be discovered). I personally see no reason why the originals need to be removed (as I said, they're already tucked away in a sub-folder), so I'm not going to do that either. If others feel differently, they can go ahead and remove them.

[Ishtvan]

I personally see no reason why the originals need to be removed (as I said, they're already tucked away in a sub-folder), so I'm not going to do that either. If others feel differently, they can go ahead and remove them.

 

Dumb question: Does frobbing do different things to the originals? My man gripe with having many versions of lights is that you don't know which FM authors will use and you don't know what will happen if you frob this candle. Will it pinch it out or pick it up or add it to the inventory or what? I think we should at least standardize the frobbing behavior.

[SneaksieDave]

My man gripe

 

Yes that's one of the probs; the originals support (though kinda klunky) frob to pinch in addition to frob to lift. The new ones are frob to lift only, and then hold and use to pinch. That's a bit of a problem to leave the inconsistency in. Thus I think we should just make a single (or few) example of the uber next-gen and old skin/particle hybrid candles, leave the rest to the users, and get rid of the old (and prefabs).

[Dram]

My man gripe

 

Oh dear