Elevator not moving...

[AluminumHaste]

So i followed this tutorial on multi floor elevators: http://wiki.thedarkmod.com/index.php/...rs,_multi-floor and the buttons don't make a clicking noise and nothing happens...This is a very good tutorial and I followed all the steps, this was working before but it's not now.

 

Does anyone have any insight?

[greebo]

The buttons are probably missing their "translate" spawnarg?

[AluminumHaste]

The buttons are probably missing their "translate" spawnarg?

 

Would that make the elevator not work?

[greebo]

Yes, because when the button is not moving, it won't change its state and won't trigger its targets.

[AluminumHaste]

Yes, because when the button is not moving, it won't change its state and won't trigger its targets.

 

Wow what? lol so the entity moving is more important than being frobbed? Okay I'll give it a try thanks

[Fidcal]

I've raised this problem before that by default buttons and levers don't work. I think really they need a non-zero default. Nobody really cares in most cases whether a lever moves 30 degrees or 40 degrees or a button moves one centimetre or three - they don't usually care about it being a mover; only about its function as a button or lever.

[AluminumHaste]

The buttons are probably missing their "translate" spawnarg?

 

When the entity is created it should by default have a "translate" spawnarg with "0 0 0" as the value.

[Fidcal]

By 'should' do you mean 'I would expect it to be 0,0,0' or do you mean 'it is best for it to be 0,0,0', ie, it is best for it to fail by default.

[AluminumHaste]

By 'should' do you mean 'I would expect it to be 0,0,0' or do you mean 'it is best for it to be 0,0,0', ie, it is best for it to fail by default.

 

It failed because when the entity is created it's missing the "translate" key afaik.

[Tels]

It failed because when the entity is created it's missing the "translate" key afaik.

 

Greebo added an "editor_setkey" (or so) spawnarg which makes it possible to add/create a translate key by default

[AluminumHaste]

Greebo added an "editor_setkey" (or so) spawnarg which makes it possible to add/create a translate key by default

 

Sweet, perfect.

[Fidcal]

I've now given the button and elevator button a default translate of 0 0.5 0 which fits the default model button (if you can find it!) north south. So it will work by default and it will also show by default in entity inspector so can be changed easily for other directions.

 

Similarly the lever now has 0 0 45 rotate which again fits the default lever direction - up down facing south.

[AluminumHaste]

LOL you beat me to it, but thanks. I always thought it should be created by default just like when you create a door, it has a rotate property by default, even if it's not the right value.

[AluminumHaste]

K question; Why does putting a rope arrow into an elevator make it stop working only when it's going down, but going up is fine?

[Ishtvan]

It's probably colliding with the rope or the arrow. Did you try putting a rope arrow in the top of the elevator and seeing if it can go up?

[AluminumHaste]

It's probably colliding with the rope or the arrow. Did you try putting a rope arrow in the top of the elevator and seeing if it can go up?

 

I sure did and it continues on up and the rope deploys and then goes through the elevator. But on the way down as soon as the rope is deployed the rope stops moving, like physics calculations have stopped working or something and the elevator stops.

[Mortem Desino]

Something extremely similar happens to physics props as well.

Rope arrow planted on top of a crate (movie)

Rope arrow planted below the crate (movie)

 

One guess is that it might have something to do with the actual arrow behaving like a func_static when it hits and deploys (looking at weapon_ropearrow.def). Since D3 deals with calculating collisions instead of weight, perhaps the crate thinks it's colliding with a func_static and sits still?

[AluminumHaste]

Something extremely similar happens to physics props as well.

Rope arrow planted on top of a crate (movie)

Rope arrow planted below the crate (movie)

 

One guess is that it might have something to do with the actual arrow behaving like a func_static when it hits and deploys (looking at weapon_ropearrow.def). Since D3 deals with calculating collisions instead of weight, perhaps the crate thinks it's colliding with a func_static and sits still?

 

See for me the difference is that when I put an arrow in the top of the elevator platform, it keeps going up, I can climb the rope and swing and stuff. As soon as the elevator starts going back down though, if there's an arrow in the elevator anywhere it stops moving, as soon as I take the arrow out, it keeps moving. Incidentally the elevator sound keeps looping like normal even if it's stopped.

 

The first elevator that I made was one elevator entity, and it stopped working up or down, as soon as I put an arrow into it. So to get around that, I made the elevator entity itself just a small 1 foot by 1 foot by 1 foot square and built some brushes around it. I then converted these brushes to func_statics and bound them to the elevator. This worked except for the current situation in which the elevator is going back down and the arrow causes it to stop working.

[Fidcal]

I'll put this on bugtracker but it may be we have to avoid materials like wood on elevators.

[AluminumHaste]

I'll put this on bugtracker but it may be we have to avoid materials like wood on elevators.

 

I'll try and make a movie tonight with fraps, maybe to help illustrate what I'm talking about.

[SneaksieDave]

Something extremely similar happens to physics props as well.

Rope arrow planted on top of a crate (movie)

Rope arrow planted below the crate (movie)

 

One guess is that it might have something to do with the actual arrow behaving like a func_static when it hits and deploys (looking at weapon_ropearrow.def). Since D3 deals with calculating collisions instead of weight, perhaps the crate thinks it's colliding with a func_static and sits still?

Those vids are great (especially the second one ). Thanks for this info, it's been tracked.

[Ishtvan]

I think this behavior has come and gone a few times based on whether we set the rope arrow solid. Setting it solid fixes some other issues, but causes this issue. I thought we also had a setting such that the bindmaster wouldn't collide with bound team members, but that doesn't seem to be working here.

[Tels]

I think this behavior has come and gone a few times based on whether we set the rope arrow solid. Setting it solid fixes some other issues, but causes this issue. I thought we also had a setting such that the bindmaster wouldn't collide with bound team members, but that doesn't seem to be working here.

 

Isn't the elevator a mover, too, and does this change somethings (e.g. opposed if you shoot an arrow into a crate which is a moveable?)

[Mortem Desino]

/****************************************
*******************************
weapon_ropearrow.def
****************************************
*******************************/
...
...
...
// greebo: Set the attachment arrows to func_static, otherwise they collide with the fired projectile
"spawnclass" "idStaticEntity"
"noclipmodel" "1"

"frobable"	"0"
"angles"	"90 0 0"
"origin"	"31.2 0 0"
"noshadows"	"1"
}
...
...
...
// bind arrow to object when it collides

"bindOnImpact"				"1"
}

// result inherits the broadhead
entityDef result_arrow_ropearrow
{
"inherit"		"result_arrow_broadhead"

"def_active_spawn_obj"	"ammo_ropearrow_small"

"copy_bind"		"1"
"remove_delay"	"1"

"snd_active"		"arrow_rope_deploy"
}

It seems simple enough (Without seeing any of the other scripts it calls), I don't see why setting it solid (idStaticEntity) should cause any problem with this kind of behavior.

 

Edit: I've also quickly made an elevator in DR. I get the same kind of behavior that AluminumHaste has.

Edited January 3, 2009 by Mortem Desino

[Ishtvan]

You can't tell all that much from the def file. To really see what's going on, you'll have to look at the actual physics code in the SDK where the mover tries to move and checks if it's blocked. Ideally it should not be blocked by things bound to it, but we don't want it to clip into the rope in this case either.

 

If you'd like to help with our physics code, we could definitely use another person working on that.