Jump to content
The Dark Mod Forums

Apples and Peaches: Obsttorte's Mapping and Scripting Thread


Obsttorte

Recommended Posts

I looked up the definition of cosine. It didn't help.

 

Let's say I want the player to be able to trigger the object as long as it is within a 90 degree xy arc of the direction he is looking. What value would I set "tolerance" to?

 

Ok, time to see if I really understand what's going on here!

 

From what I understand, an eps (tolerance) of 1 translates to 0 degrees, or in other words looking dead center at the object. An eps of -1 translates to 180 degrees, or looking directly away from the object (and would probably result in the stim being triggered all the time, since the player's view angle can't exceed looking completely away). An eps of 0 translates to 90 degrees, or looking directly perpendicular to the object. The smaller eps is, the smaller the angle to trigger is (or how directly a player has to look at the AI/object before the script is triggered). At least in the version of the script I checked out, unless otherwise specified the eps would default to 0.1, which is a decently generous tolerance of 9 degrees cos(x) = 0.1, or arccos(0.1) = 84.26 degrees. assuming I've done my math right. MAKE SURE YOUR CALCULATOR IS SET TO DEGREES AND NOT RADIANS WHEN MAKING THESE CALCULATIONS!

 

So for what you're depicting, a total angle of 90 degrees on all sides from the object would need a 45 degree player view angle from any side, so the eps would be 0.5.

 

[EDIT] No, I haven't done my math right. Eps is calculated by cos(# degrees you want). So 45 degrees would be around an eps of 0.70 or 0.71. Derp.

 

Am I right, or am I horribly mistaken?

 

By the by, should probably drop this here for future reference (and thanks for this @Obsttorte, it was super useful; I haven't had time to look into modifying the script yet but I plan to once base architecture is done):

 

Edited by Aosys
Link to comment
Share on other sites

From what I understand, an eps (tolerance) of 0 translates to 0 degrees,

An eps of 0 translates to 90 degrees,

 

Is there a typo there or am I even more lost than I thought?

Link to comment
Share on other sites

Yes that's a typo, my bad!

 

It should be:

 

Eps of 1 = 0 degrees (looking at object)
Eps of 0 = 90 degrees (looking perpendicular to object)
Eps of -1 = 180 degrees (looking exactly away from object)

 

At least, that's how I think it works, someone correct me if I'm wrong!

Edited by Aosys
Link to comment
Share on other sites

So I tried adapting this with the Turning Statue script, and I'm not getting the right behavior. I want a statue to turn only when the player isn't looking at it (aka when the player's view angle < eps).

 

I tried giving the statue ($Statue) this as the scriptobject:

 

 

 

//Trigger Look Script by Obsttorte

object trigger_look {
	float stim;
	float distance;
	float processing;
	float eps;
	float singleUse;
	string entityName;
	void init();
	void processStim(entity inflictor, float f);
};

float length(vector v) {
	return sys.sqrt(v_x*v_x+v_y*v_y+v_z*v_z);
}

void trigger_look::init() {
	stim = getFloatKey("stim");
	if (!stim) {
		stim = 23;
	}
	
	distance = getFloatKey("distance");
	if (!distance) {
		distance = 1024;
	}
	
	eps = getFloatKey("tolerance");
	if (!eps) {
		eps = -0.3;
	}
	
	eps = 1.0 - eps;
	
	singleUse = getFloatKey("once");
	
	entityName = getKey("entityname");
	if (entityName == "") {
		entityName = "player1";
	}
	
	ResponseAdd(stim);
	ResponseSetAction(stim,"processStim");
	ResponseEnable(stim,1);
	processing = 0;
}

void trigger_look::processStim(entity inflictor, float f) {
	if (processing || entityName != inflictor.getName()) {
		return;
	}
	
	processing = 1;
	vector playerView, shieldToPlayer, playerViewDir;
	
	if (entityName == "player1") {
		playerView = inflictor.getViewAngles();
	}
	else {
		playerView = inflictor.getAngles();
	}
	
	shieldToPlayer = getOrigin() - inflictor.getOrigin();
	shieldToPlayer_z -= 64;
	
	if (entityName != "player1") {
		playerView_z = shieldToPlayer_z;
	}
	
	if (length(shieldToPlayer) > distance) {
		processing = 0;
		return;
	}
	
	playerViewDir_x = sys.cos(playerView_y) * sys.cos(playerView_x);
	playerViewDir_y = sys.sin(playerView_y) * sys.cos(playerView_x);
	playerViewDir_z = -sys.sin(playerView_x);
	
	float sightAngle;
	sightAngle = playerViewDir*shieldToPlayer/length(shieldToPlayer);
	
	do {
		vector playerPos = $player1.getEyePos();
		vector thingPos  = $Statue.getOrigin();
		vector diff      = thingPos - playerPos;
		vector angle     = sys.VecToAngles(diff);
		vector rotation  = '0 270 0'; // adjust to suit
		angle_z    = 0;
		angle_x    = 0;
		angle      = anglemod360(angle + rotation);
		
		$Statue.setAngles(angle);
		sys.waitFrame();
	} while (sightAngle < eps);
	
	processing = 0;
}

 

 

 

It's not working in the slightest, and I get the feeling there's something wrong with my loop...

Edited by Aosys
Link to comment
Share on other sites

Aosys, your understanding is not completely true. Yes, a cosine of zero degrees equals one, cosine of 90 degrees equals zero and cosine of 180 degrees equals minus one. But that's not the value used in the script. It's one minus the cosine. This means:

  • 1-cos 0° = 0
  • 1-cos 90° = 1
  • 1-cos 180° = 2

The resulting values are the tolerance. I've choosen the setup like this so that a higher angle means a higher tolerance value. If I would use the cosine directly it would be vice versa, which is counter-intuitive.

 

Regarding your script: Can you explain what exactly your are aiming for?

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

This means:

  • 1-cos 0° = 0
  • 1-cos 90° = 1
  • 1-cos 180° = 2

 

 

 

So the default of 0.1 would equate to what angle? 10 degrees?

Link to comment
Share on other sites

25,84°

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

25,84°

 

 

:P I used to think I knew enough to keep up in a conversation about basic math. This thread has shown me how wrong i was.

Link to comment
Share on other sites

@Obsttorte I know the script uses 1-cos(θ), but I thought that was done for you, so a user's DR inputs would be between -1 and 1?

eps = getFloatKey("tolerance");
if (!eps) {
	eps = 0.1;
}
	
eps = 1.0 - eps;

Regarding the script, I have a turning statue script by VanishedOne and grayman that looks like this:

 

 

 

void main() {
	sys.waitFrame();
	
	while(1) {
		vector playerPos = $player1.getEyePos();
		vector thingPos  = $Statue.getOrigin();
		vector diff      = thingPos - playerPos;
		vector angle     = sys.VecToAngles(diff);
		vector rotation  = '0 270 0'; // adjust to suit
		angle_z          = 0;
		angle_x          = 0;
		angle            = anglemod360(angle + rotation);
		
		$Statue.setAngles(angle);
		sys.waitFrame();
	}
}

 

 

 

Normally, you just take that script, drag it into the same folder as the mission it's used in, and it works. In this case, it runs all the time and causes an object named Statue to always rotate and face the player on the x and y axis. I would like this behavior to trigger only when the player isn't looking at it, so when the player's view angle is outside maybe 90 or 95°. I thought that by putting a do-while conditional loop where the trigger_look script normally activates a target, I could continually get it to check the truth of the conditional, but something's clearly off with my implementation and I'm not sure what. (I'd also like it to work on whatever object it's applied to, not just something named "Statue", so the final scriptobject could be applied to multiple elements in any given map).

 

@Springheel Ok, I think I've finally got it figured out. Script tolerance uses 1-cos(θ) = eps, θ being the angle (in degrees) and eps being the tolerance. To solve for the final tolerance the script uses is easy, just plug your angle in and calculate it. So, an angle of 30° from the object would be calculated by 1-cos(30) ~ 0.13 when rounded. Going backwards is a little harder, you have to use the inverse cos (cos-1) to find the angle, so for an eps of 0.1 solving would look like this:

 

1 - cos(θ) = 0.1

-cos(θ) = 0.1 - 1

-cos(θ) = -0.9

cos(θ) = 0.9

θ = cos-1(0.9) = 25.84°

Edited by Aosys
Link to comment
Share on other sites

 

:P I used to think I knew enough to keep up in a conversation about basic math. This thread has shown me how wrong i was.

I already thought it might be useful to do a video about math, as it appears every now and than when working with scripts, materials etc.. :)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Well, it is Aosys' idea. I've just implemented it.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

  • 1 month later...

Ran into a little problem. I am fiddling around with the possibility to change the size of the hud elements, like the lightgem, inventory icons etc...

 

I've added an option to alter a cvar (gui_Width, currently unused) in the settings menu, no problems thus far, but how do I get the information from the cvar into the hud gui, so how can I access it.

 

I've taken a look at the lightgem hud and noticed, that the visibility of the lightgem is stored in the cvar tdm_hud_hide_lightgem, but the information accessed in the gui is gui::HUD_Lightgem_Visible, so a gui variable, not a cvar. I've tried to find out at which point the information from the cvar gets moved to the gui variable, but couldn't find it.

 

Does anyone know either where this is done or how to do it? So in summary. I want to access the value stored in a cvar inside a gui OR change a gui variable once the cvar changes. Note that the cvar adjustment and the usage of the value take place in two different gui files.

 

Thanks in advance. :)

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

gui_Width is used, by idGameLocal::UpdateGUIScaling().

 

The cvar tdm_hud_hide_lightgem is referenced by this statement in SysCvar.cpp:

 

idCVar cv_tdm_hud_hide_lightgem( "tdm_hud_hide_lightgem", "0", CVAR_GAME | CVAR_ARCHIVE | CVAR_BOOL, "If set to 1, the lightgem will be hidden." );

It's sent to the HUD by this statement in idPlayer::UpdateHUD():

 

// Propagate the CVAR to the HUD
hud->SetStateBool("HUD_LightgemVisible", !cv_tdm_hud_hide_lightgem.GetBool());
where "hud" is the Player HUD.
  • Like 2
Link to comment
Share on other sites

Thanks.

 

Well, tels wrote on the bugtracker that he implemented it, but that it does not get used by now. Playing with the cvar I couldn't see any effect it has, so I thought that it is indeed not used.

 

However, using the cvar is only temporary for testing purposes.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Resizing the hud works thus far. Right now I'm using a script function to pass the cvar to the gui parameter every frame. This is just a temporary workaround, though. In the end this would require its own cvar and some code added similar to how the lightgem visibility is handled.

 

By now I could resize the lightgem, the health and breath bar and the weapon hud in the lower left corner. Will upload a video once I'm finished with it.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Looks perfectly suitable to me. Great work!

 

I guess if you are aiming for absolute perfection the last things you'd need are:

 

1) A way to specify a sub-section of the screen where the GUI is allowed to render. This would all the GUI to exist

in the central region of a very wide screen, or multi-monitor setup.

 

2) Some sorta "depth control" to anticipate VR support?

 

Neither of these are really crucial at this point but number 1 would sure make a few wide-screen folks happy.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

First thoughts are that the smaller elements of the hud are way too small on the smaller scales, so either-

  • resized the smaller elements independently.
  • or resized the smaller elements independently as a ratio of the light gem - if light gem is 0.5 original size then the breath/health meters would be 0.75 thier original size (or something like that)
Link to comment
Share on other sites

Looks perfectly suitable to me. Great work!

 

I guess if you are aiming for absolute perfection the last things you'd need are:

 

1) A way to specify a sub-section of the screen where the GUI is allowed to render. This would all the GUI to exist

in the central region of a very wide screen, or multi-monitor setup.

 

2) Some sorta "depth control" to anticipate VR support?

 

Neither of these are really crucial at this point but number 1 would sure make a few wide-screen folks happy.

I've already thought that it might be worthwhile to rewrite the gui files, especially after fiddling with the loot gui, so (1) would be doable. Regarding (2): I have no idea how VR works and no motivation to investigate it, as I'm not using it and consider it rather pointless. Someone else has to take a look at this.

 

 

First thoughts are that the smaller elements of the hud are way too small on the smaller scales, so either-

  • resized the smaller elements independently.
  • or resized the smaller elements independently as a ratio of the light gem - if light gem is 0.5 original size then the breath/health meters would be 0.75 thier original size (or something like that)

 

Never thought about that. Will wait how other persons think about that.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

 


 

Never thought about that. Will wait how other persons think about that.

 

 

Yes, I think in the previous discussion about this feature, Tels postulated making a cvar that controls the lightgem size ratio so that this could be independently tuned.

That would probably be the most elegant thing to do rather than add additional sliders for each GUI element.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Interesting.

 

Two questions:

 

1 - Does the number of HUD overlays remain the same?

 

2 - At one point in WS3:Cleighmoor, various HUD overlays are either turned off or masked by a new overlay, and the mask design is based on the HUD scaling in effect at the time. I assume these scaling changes would require that I revisit WS3 and determine how to use the scaling cvar to keep a scaling change from destroying the effect I was trying to achieve. So the question is: do we know if other mission authors have done something similar to what WS3 does, and will those authors be willing to (or have the time to) revisit their own mission designs?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...