Hybrid Flashlight Mod

[MadGypsy]

@torch timer/cooldown

One idea you could consider is having the torchlight slowly fade to off. When the torch is fully extinguished it gets stowed and you implement your "cooldown" as a recharge. You could get fancy with very little effort.

You could have summin like 100% to 10% charge is full power. Less than 10 and it becomes something like [brightness = fullBright*(currentBatteryLevel/beginDimBatteryLevel)].

I could be wrong but, Player(Pre/Post)Think is probably a good spot for the battery code. It doesn't seem like you are using any physics, so it probably doesn't matter which one.

After you do all that, all you have to do is make an entire map with long completely black corridors. The object of the game will be to see how long you can stay alive in pitch black waiting for batteries to charge. You could create your own genre of game. FPW - first person waiting.

# - "Why is the level pitch black?"
+ - "Just wait."
# - "Wait for what?"
+ - "For your flashlight batteries to charge."
# - "How long does that take?
+ - "Well, this is the first time you have played so, you really should let the battery charge uninterrupted for 12 hours. You know, to break it in properly."

[abel1389]

the "no shadow" line worked like a charm. thanks for that, man. flashlight is fully functional in SoA. now all i have to do (knock on wood) is repeat those steps in mission pack 2 and i'll have a working bit for the whole game. after that, the next step would be the aggro effect and the battery life; i haven't the faintest idea how either of those would be coded, but i'll get there eventually.

EDIT: MadGypsy, that's a pretty good idea with the dark level. and i like the idea of the battery starting to crap out at low charge, although i'd probably start with something like 15-20%. or do it in two stages starting at 50% and then speeding up decay at 10%. even some flickering...

[PrimalLove]

The easiest but least creative way to get the monsters to react is to use a simple traceline in the flashlight update function.

makevectors(self.angles);
traceline(self.origin, self.origin + v_forward*500, FALSE, self);
if(trace_ent.flags & FL_MONSTER && trace_ent.health > 0)
   self.show_hostile = time + 1; // This will wake up the monster.

It will work but has little variety. The battery is easy enough also. You can make the .light_lev equal to your self.lightbattery. Just make it so self.lightbattery becomes less over time in your update function. Something like this... NOTE: You'll need to create a new .float lightbattery in defs.qc or similar.

[COLOR="Lime"]// The 120 is the lowest you want the light level to go for the battery. Can make that as low as you want.[/COLOR]
if (self.owner.flash_flag) 
{
    self.lightbattery = max(self.lightbattery - (frametime * 35), [COLOR="lime"]120[/COLOR]);
}

And in your spawn function you can change the light_lev to this:

[COLOR="Lime"]newmis.lightbattery = 650;[/COLOR] // Set the starting max battery amount/light amount
newmis.light_lev = [COLOR="YellowGreen"]newmis.lightbattery[/COLOR];

Also in your update function you'll need to recharge it once you turn it off:

if (!self.owner.flash_flag) 
{
self.pflags = 0;
[COLOR="lime"]// 650 here is the max light level. [/COLOR]
self.lightbattery = min(self.lightbattery + (frametime * 65), [COLOR="lime"]650[/COLOR]);
}
[COLOR="Lime"]// Put this near the bottom of the update function to update the light level for the flashlight. [/COLOR]
self.light_lev = self.lightbattery;

This to has limited variety but can get you started. Good Luck.

PS: If you want it to blink when close to running out you can do something like this:

if(self.lightbattery < 200)
{
	if(random() < .10)
		self.pflags = 0;
	else
		self.pflags = PFLAGS_FULLDYNAMIC;
}

[MadGypsy]

@primal - you are a beast, bro. Every time someone makes a code related post, you end up practically writing the code for them. I also know you bang code out with little or no effort. I can tell by the time/way you post it. I have hella respect for you.

@battery

What if there was a lifetime on battery recharges for the entire game? For instance, everytime you charge the battery it lasts a little bit shorter amount of time. It would be nothing to make a decimal that is multiplied by the battery life and decremented a very small fraction at the beginning of each charge. That decimal needs to carry through every episode and mission without being reset, though. You could just decrement the batteryLife var directly but, then you can't make it a constant. That's not really a problem but something like initial battery life should be a constant imo.

@start dimming at 50

You realize a real flaslight doesn't dim til there is less than 1% charge. Ex the point where it is expelling a charge that is less than the battery's standard output. If you dimmed at 50, summin like 49% would be a dead battery. My math is fucked up but, I'm basically right.

My phone shuts off at 2% charge remaining. If it started warning me at 50 percent it would be in the garbage. Don't make the garbage...

[abel1389]

alright, flashlight is up and running in DoE, save for one issue: it's green. and the color command in flashlight.qc isn't affecting it at all. lol, had to be something, i guess; at least i got a laugh out of it when it came up that way. not sure what's up with that, but i'll poke at it some more when i'm running on more sleep. also, no luck with the aggro or battery lines yet, but i've only played with them a little tonight, so we'll get there.

a couple of questions/guesses, just to make sure i'm understanding this code correctly. first: is "v_forward*500" the distance that traceline extends to for interaction with enemies? second: on the battery codes, i'm gonna guess "frametime" is the rate at which the value changes?

anyways, i'll be back at it sometime tomorrow to get this going; hopefully i'll have it wrapped up by the end of the week. much thanks for all the help you guys are giving me, and for the code chunks.

[PrimalLove]

@abel1389

1. Yes the v_forward*500 is the distance to simulate the light distance.
2. Yes, it uses frametime to increment the amount of battery/lightlevel over time. It adds it back when you turn it off as a charge. You can play with the numbers a bit. use 95 to charge faster or a lower number to make it take longer. Its basic but will work.

I am not clear on your green light problem. I doubt DoE uses any code that would mess with it.

As for using the code for charging.. Here is an example of its use...

.float lightbattery;
.float maxbattery;
.float minbattery;
void() checkflaslight=
{
        [COLOR="lime"]// Flash the light on and off randomly if light level really low.[/COLOR]
	if(self.lightbattery < 200)
	{
		if(random() < .10)
			self.pflags = 0;
		else
			self.pflags = PFLAGS_FULLDYNAMIC;
	}		
	
	if ((self.owner.flash_flag) && (self.pflags != PFLAGS_FULLDYNAMIC) && !self.cnt)
	{
		self.pflags = PFLAGS_FULLDYNAMIC;
		self.cnt = 1;
	}
	if (self.owner.flash_flag) 
	{
		makevectors(self.owner.v_angle);
                [COLOR="Lime"]// Traceline to tell enemy you are pointing the light at them[/COLOR]
		traceline(self.owner.origin + self.owner.view_ofs, self.owner.origin + self.view_ofs + v_forward*600, FALSE, self);
		if(trace_ent.flags & FL_MONSTER && trace_ent.health > 0)
			self.owner.show_hostile = time + 1;
                 [COLOR="Lime"] // Lower battery life over time. Adjust as desired.[/COLOR]
		self.lightbattery = max(self.lightbattery - (frametime * 45), self.minbattery);
	}
	if (!self.owner.flash_flag) 
	{
		self.cnt = 0;
		self.pflags = 0;
                 [COLOR="lime"]// Recharge[/COLOR]
		self.lightbattery = min(self.lightbattery + (frametime * 85), self.maxbattery);
	}
		self.light_lev = self.lightbattery; [COLOR="lime"]// Update Light Level[/COLOR]
		self.nextthink = time + 0.1;
};


void(vector org,entity e) FlashLight =
{
   newmis = spawn();
   newmis.owner = self;
   setmodel(newmis, "");
   newmis.origin = org;
   newmis.angles_y = newmis.angles_y - 180; 
   newmis.owner = e;
   [COLOR="Lime"]newmis.lightbattery = 850;[/COLOR]
   [COLOR="Lime"]newmis.maxbattery = 850;
   newmis.minbattery = 50;[/COLOR]
   newmis.light_lev = 850;
   newmis.color = '2.5 2.5 2.5';
   newmis.skin = 1;  
   newmis.viewmodelforclient = self;
   newmis.think = checkflaslight;
   newmis.nextthink = time;
};

[MadGypsy]

@abel - good work. What I'm about to say might be completely stupid but, it's the only idea I have on why it's green. Are there any green lights naturally in that level? Maybe some kind of crazy way you are cloning it. I know I'm probably wrong.

@primal - also good work. You also taught me something. I didn't realize QC had min/max number operators. I actually wrote a max function once because I didn't think QC supported it. In AS3 max is a static method of the top level Math class (Math.max()), so I named my QC method mathMax. Too bad I don't use simple names, otherwise I probably would have realized the feature already existed when I unknowingly tried to override it.

[PrimalLove]

@MadGypsy

Technically it's not a builtin unless you use the DP extension. But I knew he was already using dpextensions so I used it here. I apologise I should have been clearer about that. But yeah you can just add them.

float (float a, float b) min =
{
	if (a<b)
		return a;
	else
		return b;
};

float (float a, float b) max =
{
	if (a>b)
		return a;
	else
		return b;
};

[MadGypsy]

@dpextensions - thats right, I actually did know that. DPExtensions has a whole math suite that (I forget who) wrote. I believe those classes are built into FTE as well. (built in cause FTEExtensions is compiled into the engine)

you can drop the else's, if the condition is false it will automatically do the next return. Or we could have fun with ternarys

return (a<b) ? a : b;

[Spike]

and if you want to have fun with ternarys and preprocessor:
#define min(a,b) (((a)<(b))?(a)b))
#define max(a,b) (((a)>(b))?(a)b))

[MadGypsy]

@spike - pretend I'm stupid (maybe you wont have to try too hard )... what exactly does that do? To be clear, I'm assuming the #define goes in qc, but what is the difference between the preprocess way vs standard qc (aside from the syntax)?

Oh, and why so much parenthesized nesting on the vars?

[Spike]

this:
#define foo(a) blob(a*10)
foo(2+3);
is replaced by the preprocessor to become:
blob(2+3*10);
the excesive brackets are there because you probably wanted:
blob((2+3)*10);
which saves doing
foo((2+3));
which just looks clumsy.

in the min+max examples, both a and b can be evaluated twice, while a normal function call will only evaluate them once. its thus not recommended to use side effects as the arguments to such macros. and by side effects, I mean assignments, function calls, or pre/post increments/decrements.
on the plus side, using the preprocessor saves you a function call at run time, which can also help avoid operations on two variables that are basically constants.

there was actually a bug in fteqcc that got abused... but that's because it was an awesome one. by using \ within a macro you can include extra #define commands (or #ifdefs or whatever) within the macro itself. naturally you can use this to set all sorts of hidden variables as arguments to later defines or generate entire blocks of code from formulas.
It can actually be quite useful, and I've found myself wanting the same sort of thing in C too...
But its completely and utterly unreadable. especially if you're using #ifdefs and not matching them properly.

[MadGypsy]

@spike - I understood all of it. Thank you. If that is you pretending I'm stupid, you nailed my level of stupid, excellent job.

As an aside most of the time you tell me things and I have to read it a couple/few times. I think mostly cause you are a C programner and I am not. This time however, I only read it once.

[abel1389]

there's one green light in the intro map, but only on the HD version with RomiRT lights enabled. with a bit more tweaking i've discovered that i CAN affect the color by changing the first of the three values in the newmis.color command. setting it to around 200 changes it to orange! but the other two numbers don't do anything to it that i can tell thus far; are all three values to change color or is it a "color, saturation, opacity" sort of thing? the problem as far as i can tell isn't that i need to correct the color but that i need to find out why it's being tainted in the first place, because the cubemap is already colored correctly, and the added green is oversaturating it so that you actually have a harder time seeing anything within the light radius: it blocks out image detail completely when you get close enough and just shows a solid green mass.

other features are gonna be put on hold on my end till i get the "green" sorted out, but you guys keep doing what you're doing; looks like all this sparked some light brainstorming that's above my head.

EDIT: another thought occurred to me. when i was working on the Hipnotic Torch, one of the errors kept asking me to go in and change a line about color definition from .vector to .float. i can't seem to find what file that was in anymore, but could that have something to do with it? don't know why it would let me even compile the mod if that was gonna be a problem since it didn't on the other mod, but it's the only color related thing that came up that i can think of.

[Spike]

EDIT: another thought occurred to me. when i was working on the Hipnotic Torch, one of the errors kept asking me to go in and change a line about color definition from .vector to .float. i can't seem to find what file that was in anymore, but could that have something to do with it? don't know why it would let me even compile the mod if that was gonna be a problem since it didn't on the other mod, but it's the only color related thing that came up that i can think of.

yeah, don't do that.
the color field must be a vector for it to function correctly with rtlights.
change it back to a vector and then change any references to the .float color to instead use color_x (find em via compile errors if you want).
then make sure the various forcefields still work or whatever it is that uses that field.
this is why you shouldn't use generic names for extensions, because there'll be some mod out there that already uses it for something...