Newbie DarkRadiant Questions

[grayman]

You could put this off until you enter beta, and ask for a beta tester who still has 2.03 installed ...

 

or you could give me the map and I'll try to see what's happening.

 

if changing the search type didn't make it better, it's possible that some other 2.04 change is causing the problem.

[Spooks]

So I've done a camera trolley for player laying down on bed - with help from this topic :

http://forums.thedarkmod.com/topic/13059-func-animate/

 

 

I've not tried what you're trying right now but I'll try to be helpful. To me, the turn_180_left animation looks like just that, an animation. It will not actually turn the character pivot, so to speak. I think what you'd need is when the turn left animation ends, teleport the func_animate to the same location where it is, but just turned 180 degrees. The way you have it setup is problematic though and I doubt you'd be able to do this without it looking a bit jarring (it's a PoV for the player after all). Keep in mind that's only one solution you can use to address this, it's just the first that came to my mind, but yeah, that's your problem.

[Dunedain19]

@grayman

 

Either way works for me. The mission is a long way off from completion, so the issue is not urgent at all.

 

If you could take a quick look, I would be very grateful. I do need to just isolate that area from the rest of the larger level structure so you can examine the problem directly.

 

I'll get around to that on the weekend.

[ERH+]

Does someone working on winter / polar suits or hats, or is something similar scheduled for updates?

[Dragofer]

Can lights toggle the skin of a targeted model, so that an exterior window would fit to the interior lamp? What I've tried was to let the lamp's flame entity target the window model, then set skin_lit and skin_unlit on the window model, but that caused no reaction.

(I know that the flame is set up correctly because it's able to hide and unhide that window if I set "hide" "1" on the window)

 

 

Also, has anyone managed to get AIs to use horizontal doors, for instance the cargo loading hatch on a ship?

Something I tried was setting two door handling position entities for where the AI should stand (I used the wiki to copy-paste spawnarg names), no luck. Even if I let the door start fully open, the AI will only move downstairs if I move the door about 64 units to the side.

[grayman]

Can lights toggle the skin of a targeted model, so that an exterior window would fit to the interior lamp? What I've tried was to let the lamp's flame entity target the window model, then set skin_lit and skin_unlit on the window model, but that caused no reaction.

(I know that the flame is set up correctly because it's able to hide and unhide that window if I set "hide" "1" on the window)

 

Have you read this page in the wiki?

 

Also, has anyone managed to get AIs to use horizontal doors, for instance the cargo loading hatch on a ship?

Something I tried was setting two door handling position entities for where the AI should stand (I used the wiki to copy-paste spawnarg names), no luck. Even if I let the door start fully open, the AI will only move downstairs if I move the door about 64 units to the side.

 

AI only (automatically) use doors that rotate about the z axis. If you want something else, you'll need to simulate it. (AI arrives at path_corner, raises its hand to the door, activates the door, waits for the door to open, moves to a path_corner on the other side, turns back to the door, raises its hand to the door, activates the door, and turns and leaves). Even then, if two or more AI use the door simultaneously, hilarity will ensue.

 

You'll probably have to use a rotating mover, rather than a door, because the presence of the door is going to cause the code to try to set up automatic door handling, which will interfere with the simulation.

[VanishedOne]

Can lights toggle the skin of a targeted model, so that an exterior window would fit to the interior lamp? What I've tried was to let the lamp's flame entity target the window model, then set skin_lit and skin_unlit on the window model, but that caused no reaction.

(I know that the flame is set up correctly because it's able to hide and unhide that window if I set "hide" "1" on the window)

I just got it to work with an oil lamp, not with a basic light entity. Reading http://forums.thedarkmod.com/topic/14130-windows-with-switchable-skins-done-in-a-fashion/?do=findComment&comment=296126 made me think it should work with any extinguishable light, but if it's failing with a flame then maybe not... Does your flame have the usual scriptobject for extinguishable lights?

[Obsttorte]

Can lights toggle the skin of a targeted model, so that an exterior window would fit to the interior lamp? What I've tried was to let the lamp's flame entity target the window model, then set skin_lit and skin_unlit on the window model, but that caused no reaction.

(I know that the flame is set up correctly because it's able to hide and unhide that window if I set "hide" "1" on the window)

Not the flame entity of the lamp, but the lamp itself has to target the window. And the lamp has to use the scriptobject tdm_light_holder (which it might does, check the inherited spawnargs).

[Dragofer]

I just got it to work with an oil lamp, not with a basic light entity. Reading http://forums.thedarkmod.com/topic/14130-windows-with-switchable-skins-done-in-a-fashion/?do=findComment&comment=296126 made me think it should work with any extinguishable light, but if it's failing with a flame then maybe not... Does your flame have the usual scriptobject for extinguishable lights?

 

Great, it was as simple as targeting the window from the lamp model, that's all I needed. It didn't work earlier because I was targeting from the light itself ("set target0 on flame" "window").

 

It does indeed look like it won't work if the light entity itself targets the window to get the skin to change. I tried this on a stock oil lamp and candle holder: it has to be the holder, not the light.

 

I was interested to see if other objects like a crate could also toggle skins of an object when frobbed, so I copied the scriptobject and frob_action_script spawnargs over from a frobable lamp. Well it worked for one frob, after that nothing happened anymore, even if I def_attached a light entity which I thought might help the lightholder script know what to do. No matter, I was only looking for a way to make standard oil lamps work.

 

Have you read this page in the wiki?

 

Yes, that's the method I was using in Down by the Riverside, but it didn't seem right to duplicate windows to get the effect of a skin change.

 

 

AI only (automatically) use doors that rotate about the z axis. If you want something else, you'll need to simulate it. (AI arrives at path_corner, raises its hand to the door, activates the door, waits for the door to open, moves to a path_corner on the other side, turns back to the door, raises its hand to the door, activates the door, and turns and leaves).

 

Hm, that could be used for a cutscene, but it'd be problematic if the player was able to interfere with the process - things like if the door was left open by the player, or the player stopped the door's movement while the AI was using it, or a crate was dropped on the door. Horizontal doors would be on my wishlist for making ship prefabs that are too small to have two staircases (like the one I'm finishing off now).

[Bikerdude]

You'll probably have to use a rotating mover, rather than a door, because the presence of the door is going to cause the code to try to set up automatic door handling, which will interfere with the simulation.

Or look at how the portcullis are setup in Sir Talbots.

[AluminumHaste]

Would it be possible to use a button instead of a handle to open the door? That way the AI has to walk a fair distance from the door to close it.

However what about other AI walking through the door while it's closing. Would the other ai keep smashing the close button or press it once and move on?

[grayman]

Would it be possible to use a button instead of a handle to open the door? That way the AI has to walk a fair distance from the door to close it.

However what about other AI walking through the door while it's closing. Would the other ai keep smashing the close button or press it once and move on?

 

Having AI use buttons to deal with doors works now.

 

I never tested this with doors that don't rotate about the z axis. It might work, it might not.

[grayman]

Horizontal doors would be on my wishlist for making ship prefabs that are too small to have two staircases (like the one I'm finishing off now).

 

If this is a "TDM supports" wishlist, it's not likely to happen. Door-handling is one of the most complext bits of TDM code, and it relies on doors rotating around the Z axis.

 

Try the suggested "door controller" approach and see if that works.

[Aosys]

More of an academic question than one stemming from immediate need, but one that might be nice to implement later.

 

I'm interested in generating some in-game behaviors based off of the player's POV. The first has to do with the Func_Static Player Face Script by VanishedOne and grayman. Currently, the script works as intended; func_statics with it applied will always turn to face the player. What I'd like to do is invoke the script only when the func_static is outside of the player's FOV.

 

The other is to have ghosts which are visible in the player's peripheral vision, but not when looked at directly, like what's done in the Metro games:

 

 

 

I did go digging around in the TDM Script Reference page, and found getViewAngles(). I've also somehow gotten hold of a trigger_look script (apologies about not naming an author, I forget where this came from):

 

 

 

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.1;
	}
	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) {
		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 angle;
	angle=playerViewDir*shieldToPlayer/length(shieldToPlayer);
	if (angle>eps) {
		activateTargets(inflictor);
		if(singleUse) {
			ResponseEnable(stim,0);
			return;
		}
	}
	processing=0;
}

 

 

 

Would either of these be the correct solution?

Edited October 5, 2016 by Aosys

[Obsttorte]

 

I've also somehow gotten hold of a trigger_look script (apologies about not naming an author, I forget where this came from):

Itse me, Mario

 

Trigger look combined with the ai that can only be seen in the dark (I think goldwell used that one in Requiem) should do the trick. But you have to enhance the script so the ai becomes visible again when in the peripherie. The best approach is if you try to understand how the script works and ask questions if you have some. You can use that understanding to create your own script than.

[Dragofer]

 

Having AI use buttons to deal with doors works now.

 

I never tested this with doors that don't rotate about the z axis. It might work, it might not.

 

Experimenting with the horizontal door, I've made some progress: it has to be the sliding type, if it rotates you get an unmanageable chunk of dynamic monsterclip that obstructs everything. AIs are now able to go up and down the staircase if the door is open. The AIs are also able to walk over the door when it's closed.

 

So far, if I command an AI to walk downstairs when the door is closed, he sees no need for opening the door and goes to turn in circles on top of it.

 

Added a levers setup as per the wiki, but they aren't used because the AI doesn't seem to think it's necessary to open the door. Combined this with door handling positions, and also with door handling positions just on their own, but there was no difference.

 

 

After that I tried things like adding a block of wood or monsterclip to the door so that it's shaped more like a vertical door, getting quirky results. Maybe with enough experimentation it might be possible to get a working setup.

[Destined]

Good idea with the sliding door. Have you tried different angles? For example not a horizontal door but a 45° angle (like you could expect for a cellar door into a cellar from the outside). Maybe there is an angle-threshold at which the AI recognises the door as a door.

 

Edit: Another idea that just occured to me: you could try to install a no-draw vertical "dummy door" for the AI to have a handling position and link it to your horizontal door so that it opens as soon as the dummy door gets activated by the AI.

Edited October 5, 2016 by Destined

[Aosys]

@Obsttorte So I was looking at the scriptobject you created, and found the older Trigger Look script you had posted. Do I need both for this to work?

 

Unfortunately I have 0 scripting experience, so I'm feeling a lot little lost at the moment... I've tried commenting the code but I pretty much don't know what's going on :/

[Obsttorte]

https://youtu.be/5pnLZzrZTAo

[Dragofer]

Edit: Another idea that just occured to me: you could try to install a no-draw vertical "dummy door" for the AI to have a handling position and link it to your horizontal door so that it opens as soon as the dummy door gets activated by the AI.

 

Excellent, thanks for the suggestion, the horizontal door is now functional in both directions. I've added a nodraw normal-shaped sliding door halfway up the staircase, converted the horizontal door to func_static and bound it to the nodraw door, added some door handling positions and now it looks like normal door behaviour. From here it's a matter of refining it, for example making it harder to disrupt the system with moveables.

[Obsttorte]

https://youtu.be/OtYh-Yq2RMw

[Obsttorte]

@Aosys: Are you actually going to use such a ghost in a FM yourself. Just asking because you said it was an academic question and halloween is coming

[Aosys]

@Obsttorte I... may or may not have something in the works

 

 

 

Though the real question is, can I finish it in time, heh...

[Goldwell]

Is it possible to set a "func_rotating" entity to slowly warm up or slow down when being triggered rather than just abruptly stopping?

 

I have tried "accel_time" and "decel_time" but to no avail.

[grayman]

Is it possible to set a "func_rotating" entity to slowly warm up or slow down when being triggered rather than just abruptly stopping?

 

I have tried "accel_time" and "decel_time" but to no avail.

 

Apparently not. "accel_time" and "decel_time" are relevant to rotating movers only (atdm:mover* or it inherits atdm:mover*).