Questions about other/sfx_orbiting_light

[MS:C community]

As the thread title says...
Is there any way to change:

• the colour of the light (and sprite)
• the size of the sprite
• the radius of the rotation path
• the angular velocity

What are the current values for the radius and angular velocity anyway?

Also, I'm looking for a complete list of sprite names and sound files used for the special attacks of the dark staff. Things such as the names of the eye sprites and glow sprites (and colours), the weird "thud" sound you hear when the staff is placed, the sound you hear when the eyes start glowing, the names of the (lesser) circle of death sprites, etc.

 

[Thothie]

Let's see...
other/sfx_oribiting_light

clientevent new all other/sfx_orbiting_light_cl $get(ent_me,origin) 60.0 96 256 (128,128,0) 0.8

other/sfx_oribiting_light_cl

{ client_activate //<origin> <duration> <wander_radius> <light_radius> <light_color> <speed>
	setvard FX_ORIGIN PARAM1
	setvard FX_DURATION PARAM2
	setvard FX_RADIUS PARAM3
	setvard GLOW_RADIUS PARAM4
	setvard GLOW_COLOR PARAM5
	setvard FX_ROT_SPEED PARAM6

So.... 96 unit orbit radius, and a color of 128 128 0 256 (although the HLRAD brightness system doesn't take here, for this is a dynamic light, just the color.)... And a velocity... Well, it's a client side effect, so it's velocity isn't going to be consistent. It's, roughly, 0.8 units per frame, but its actual rotation rate will vary between clients, depending on their FPS (though it should seem fairly slow on most).

There's two on test_scripts.bsp right at the spawn.

It isn't adjustable at the moment, but it'd be fairly easy to switch it up to be so via addparams - changing any of the parameters you see there... Might also be able to change the refresh rate (currently every full minute), mute the sound, and maybe change the sprite used - though you'd have to be careful that said sprite was precached by placing a similar env_sprite elsewhere (or checking the log files for existing sprites).

Probably would have made it adjustable, but I think the script was created before we had the additional parameters option.

Oh, the size of the sprite... Yeeeah... It's using 3dmflaora.spr at 1.0 scaling, since its already precached by the spell system, and that sprite is 64x64 units... However, since the sprite's texture fades, it looks quite a bit smaller.

 

[MS:C community]

Thanks for your answers. How does other/sfx_oribiting_light_cl work though? I don't fully understand that code.
Also, if you have time, could you please answer my dark staff resources question?

I read in a different thread that you've been asked to review all the maps of the media contest, so I gather you're quite busy. And this dark staff thing isn't really priority, so take your time

 

[Thothie]

Thanks for your answers. How does other/sfx_oribiting_light_cl work though? I don't fully understand that code.

That'd be complicated to explain... I can post the whole code up, and you can copy it into your msc/test_scripts/ folder, then spawn the special NPC that handles that with ms_dev_mode 1 set, and adjust it yourself. You’d then place the object in your map with the scriptfile "test_scripts/sfx_oribiting_light" (or such). There's detailed info on this process in msc/test_scripts/test_scripts_info.rar

It's two separate scripts, as one side handles the server end and the other the client. other/sfx_oribiting_light being the server side, placed to determine the light's location, and the client side being handled by other/sfx_oribiting_light_cl. You place the server side script, and it creates and maintains the client effect.

I'll try to comment them up, and post em here...

other/sfx_oribiting_light

 #scope server //forces this script to be handled server side, so it doesn't mirror to the client

//Special DLL event goes off whenever script spawns:
{ game_spawn

	//defining height and width so that it has an actual origin, sometimes NPC's with no models have issues finding their origins:
	width 1
	height 1
	race beloved //so no NPC's attack or damage it
	hp 1 //so it can be removed
	invincible 1 //so it can't be damaged by players or other effects
	setvard PLAYING_DEAD 1 //this prevents NPC's from even acknowledging its existence
	nopush 1 //cant be pushed
	setsolid none //isn't clipped
	gravity 0 //floats
	setprop ent_me movetype 0 //prevents the slow fall effect you sometimes get with floating npcs
	//initialize cl effect on spawn (expires in 60 seconds):
	clientevent new all other/sfx_orbiting_light_cl $get(ent_me,origin) 60.0 96 256 (128,128,0) 0.8
	//initialize server side sound:
	//(this particular wave file has a special loop flag that causes it to auto-loop)
	//(it's part of the base half-life materials [half-life/valve/sound])
	svplaysound 1 10 ambience/alien_creeper.wav
}

{
repeatdelay 60.0
	//^ repeat this event every 60 seconds
	//refresh the sound and CL effect:
	callevent refresh_sound
	clientevent new all other/sfx_orbiting_light_cl $get(ent_me,origin) 60.0 96 256 (128,128,0) 0.8
	//note that, if the player goes under water, his client will remove the sprite, but it'll re-appear at the next refresh - the light and sound will not be effected
	//if a player joins late, after this has spawned, it may not appear to him until the next refresh
	//the sound will eventually get 'drowned out' as the sound que fills, so we re-initialize that as well
}

{ refresh_sound
	//turn sound off by playing at zero volume, before re-starting it
	svplaysound 1 0 ambience/alien_creeper.wav
	callevent 0.1 refresh_sound2
}

{ refresh_sound2
	//and back on again
	svplaysound 1 10 ambience/alien_creeper.wav
}

other/sfx_oribiting_light_cl

 //glowing light orbiting at fixed origin
//note that actual rotation speed may vary quite a bit with frame rate
#scope client //this isn't actually required as its called with clientevent, but habit...

{ client_activate //<origin> <duration> <wander_radius> <light_radius> <light_color> <speed>
	//this event captures the parameters set with clientevent in the above script
	//as with all events called with parameters, these appear as local's PARAM1-9

	setvard FX_ORIGIN PARAM1
	setvard FX_DURATION PARAM2
	setvard FX_RADIUS PARAM3
	setvard GLOW_RADIUS PARAM4
	setvard GLOW_COLOR PARAM5
	setvard FX_ROT_SPEED PARAM6

	setcallback render enable //lets the script capture frames pre-render
	setvard FX_ACTIVE 1 //flag to note this effect as active
	setvard CYCLE_ANGLE 0 //initial radial angle position, relative to center
	callevent FX_DURATION end_fx //end in <duration> seconds
	cleffect light new FX_ORIGIN GLOW_RADIUS GLOW_COLOR 1.0 //initial light
	setvard LIGHT_ID game.script.last_light_id //stores the light created above
	cleffect tempent sprite 3dmflaora.spr FX_ORIGIN setup_sprite update_sprite
	//creates cl sprite via the params in setup_sprite event, updated each sprite frame under update_sprite event
}

//This DLL event only occurs if setcallback render is enabled, and is called every client frame
{ game_prerender
	if FX_ACTIVE
	//moves the light to the current location each frame:
	//move a bit:
	add CYCLE_ANGLE FX_ROT_SPEED
	//if we've made a full circle, reset:
	if ( CYCLE_ANGLE > 359.99 ) setvard CYCLE_ANGLE 0
	//start with our base origin:
	setvard CUR_POS FX_ORIGIN
	//figure a ray from origin to set radius, based on current cycle angle:
	//ie. $relpos($vec(pitch,yaw,roll),$vec(r,f,u))
	vectoradd CUR_POS $relpos($vec(0,CYCLE_ANGLE,0),$vec(0,FX_RADIUS,0))
	//move the light to said location
	cleffect light LIGHT_ID CUR_POS GLOW_RADIUS GLOW_COLOR 1.0
}

{ update_sprite
	//moves the sprite to the current location, each update:
	cleffect tempent set_current_prop origin CUR_POS
}

{ end_fx
	//turn off the effect, and give a second for any frames to finish their work...
	setvard IS_ACTIVE 0
	callevent 1.0 remove_fx
}

{ remove_fx
	//...and then remove the script from the client
	removescript
}

{ setup_sprite
	//sets up the parameters for the sprite
	cleffect tempent set_current_prop death_delay 	FX_DURATION
	cleffect tempent set_current_prop scale 	1
	cleffect tempent set_current_prop gravity 	0
	cleffect tempent set_current_prop collide 	none
	//^ prevents collision with world or npcs...
	//...however, if the sprite leaves the map, it'll be removed, as with all tempent sprites/models
	cleffect tempent set_current_prop framerate	30
	cleffect tempent set_current_prop frames	1
}

Also, if you have time, could you please answer my dark staff resources question?

I read in a different thread that you've been asked to review all the maps of the media contest, so I gather you're quite busy. And this dark staff thing isn't really priority, so take your time

Oops... Didn't see that... Actual map judging will have to wait until I get home, as this laptop barely handles MSC, so I've some time (even if I should really be working on Cyax's scripts)...

The seals are all in one very large grouped model... msc\models\weapons\magic\seals.mdl - you'll need JHLMV to select the appropriate Body attribute for use with env_model (subtract 1 from the JHLMV index, as Half-Life actually indexes from 0). Note you'll also have to tilt it a bit to see it, as when you open the model, you're looking straight at the seal's edge - as this is a 2D object, this renders it invisible. (It's also invisible from underneath). Note also the Body attribute does not preview in Hammer.

The pulse sound when you slam it down is the standard stun burst sound, I believe... msc\sound\magic\boom.wav

...and the eyes... I'll have actually it open it up... Lessee... calflame.spr - with various rendering colors applied.

 

[MS:C community]

Thanks a lot for all the detailed info. I knew how to use other/sfx_orbiting_light, I just thought other/sfx_orbiting_light_cl was something different... But it's the client-side 'version' of that entity.

I got an orbiting light working in the new and improved Loreldian orrery in my map, now I just need a different colour someday

 

[Thothie]

Thanks a lot for all the detailed info. I knew how to use other/sfx_orbiting_light, I just thought other/sfx_orbiting_light_cl was something different... But it's the client-side 'version' of that entity.

Well, it's the client side, half, rather than version. Server needs to know where the effect is to be, and initiate and maintain it. Be kinda nice if there was a system to get around that... Client cues in the BSP or some such. Would eat less server resources that way - not that it's eating a lot as it is, but it'd add up if you had a bunch of em.

I got an orbiting light working in the new and improved Loreldian orrery in my map, now I just need a different colour someday

I think I had this hanging over my crib when I was a baby.

You could tweak the client end of the script up to make the light color cycle, but umm... It's gaudy enough as is, I think.

 

[MS:C community]

Another question about something. It's not related to the above at all, but I don't want to flood this section with new threads.

I stumbled across an ancient entity guide for SpiritHL (web archive link).

The page lists, as one would expect, a whole bunch of SpiritHL-only features, but at the top, under "General Information", there's this:

Similarly, for any Master, you can invert the master relationship (that is, you can disable the entity whenever the master is on) by adding a tilde (~) at the start of the master's name.

Now I played around with this a bit... I have a trigger_once that targets a multisource and I have a func_door_rotating that has the multisource set as its master. If I just set it up normally (ie. give the multisource a regular name), it works as one would expect: The door is locked until someone walks through the trigger_once. If I try the ~-trick, however, it doesn't work...

Door master: ~[reg. name], master name: ~[reg. name], trigger_once target: ~[reg. name]
Behaves exactly as without ~

Door master: [reg. name], master name: ~[reg. name], trigger_once target: [reg. name]
The door is always open, presumably because the master auto-removed itself because nothing will ever trigger it...

Door master: [reg. name], master name: ~[reg. name], trigger_once target: ~[reg. name]
The door is always open...

Is this ~-trick SpiritHL-exclusive or am I doing something wrong? Note that I haven't tried all possible ~[reg. name] and/or [reg. name] combinations yet for the three entities involved.

 

[Thothie]

Yeah, that'd be an SOL exclusive thing...

We'd love to integrate more SOL features, and I have several different builds of the source code - but the bugger of it is, despite the fact that they made it with modding in mind, they didn't make it moduler... This, wouldn't be a problem, if you used SOL as your SDK base and built a fresh mod on it from there, but it makes it a real pain to figure out how to integrate with an existing mod, especially one that's altered so much of the base SDK (bad Dogg!) as ours has.