key model problems [open]

[Tels]

The key models have some problems:

 

* they need re-orienting so that all key models face the same way. Currently some of them are rotated, meaning if you add a key-entity, you need to rotate them around different axes, which is quite cumbersome. In addition, selecting two keys and rotating them around the same axis is impossible (so you can't f.i. rotate all they keys and the board on the wall at the same time):

 

 

* Two collision models are missing. Also, the collision models for the keys with the ring do not have a hole, meaning you cannot put these keys on a "pin" without D3 complaining about them being stuck "in solid". (I am not sure if such a collision model is possible, tho)

 

[Springheel]

This really belongs in the model thread, as these aren't bugs.

[Baddcog]

It's not that cumbersome to push the x,y, or z rotate button a few time is it? I don't wanna start redoing all our models because their orientations are off.

 

How many times are ya gonna rotate 5 different keys at once?

 

Good luck with collision models with holes in em.

 

I've added collision to all my keys, if I do the lwo's the will end up ase and everyone will have to change any that are in their missions.

 

Sorry, other than those keys needing collision models I think it's a waste of time.

[Tels]

It's not that cumbersome to push the x,y, or z rotate button a few time is it?

 

Yes, it is, because you do not know in advance which button you need to press as it changes with almost every key. Change the model, and suddenly the key changed rotation, too.

 

I don't wanna start redoing all our models because their orientations are off.

 

Fair enough, then somebody else can do it

 

How many times are ya gonna rotate 5 different keys at once?

 

This situation came up already two times in two levels for me (a board with 2 respective 6 keys), and it royally sucks to end up with completely jumpled models.

 

Good luck with collision models with holes in em.

 

I've added collision to all my keys, if I do the lwo's the will end up ase and everyone will have to change any that are in their missions.

 

So are holes simple not possible, or just hard to do? About the change: Well, the key models already changed once, and broke in maps, anyway (f.i. lockpick.map had broken models). I am convinced it is better to make the stuff consistent right now, instead of living forever with inconsistent stuff.

 

Sorry, other than those keys needing collision models I think it's a waste of time.

 

No problem, I just don't think it is a waste of time to clean up.

[Tels]

This really belongs in the model thread, as these aren't bugs.

 

Can somebody please move this thread then?

[Tels]

With what (free) program can I edit .ase and .lwo files on Linux? Is Blender able to work with them? What is the prefered format for models?

[Baddcog]

I think you can do lwo with blender.

 

ase is 3dsmax native.

 

moveable collision models are VERY picky. I got a really complex weird collision model to work with my teapot before i knew what I was doing, I haven't had such luck with anything else to date. I actually spent a few days just seeing what I could do. The key collisions themselves theoretically shouldn't work either but there is much debate about what actually is the limit to collisions.

It's really just trial and error.

[Tels]

I think you can do lwo with blender.

 

ase is 3dsmax native.

 

Got blender installed now, but it can't seem to open .lwo or .ase. Going to look for a import tomorrow.

 

moveable collision models are VERY picky. I got a really complex weird collision model to work with my teapot before i knew what I was doing, I haven't had such luck with anything else to date. I actually spent a few days just seeing what I could do. The key collisions themselves theoretically shouldn't work either but there is much debate about what actually is the limit to collisions.

It's really just trial and error.

 

Ah ok. But I guess at least the two missing models can just be copied from the other keys?

[Baddcog]

Got blender installed now, but it can't seem to open .lwo or .ase. Going to look for a import tomorrow.

 

 

 

Ah ok. But I guess at least the two missing models can just be copied from the other keys?

 

Yeah, I could send the collision meshes or put it up on svn. I think I just changed the size to fit.

I can convert lwo to 3ds with Accutrans (freeware) and add the coll also, but someone would need to convert to lwo, might be just as easy for someone else to do it.

 

The problem with changing all keys to ase is we get into the 'which other models can I fix and convert to ase'... I'm trying to just not go there. Not that alot of stuff needs fixed/changed, but like when I'm adding collsion/shadow to existing meshes, there are already enough ase's to keep me busy.

 

here's a list of tools, don't know if you'll find what you need or not

http://www.modwiki.net/wiki/MD5_%28file_format%29#Tools

[Springheel]

Yes, I'd prefer people not change .lwos to .ase. Three of our modelers use Lightwave, which doesn't open .ase files.

[Tels]

Yes, I'd prefer people not change .lwos to .ase. Three of our modelers use Lightwave, which doesn't open .ase files.

 

So to re-ask my question: What is the prefered format? Should all models be .lwo then?

[sparhawk]

You can make it any format you like, just don't change it from one format to the other.

[Springheel]

The people who use blender generally save in .ase format, and the people using lightwave save in lwo. I don't think there's any benefit for one over the other beyond what you're comfortable with.

[Baddcog]

ase's are nice 'cause you can edit in notepad. I've actually been adding alot of the collision and shadow meshes this way. Then the original file is still intact (author names, shaders, mesh smoothing and whatnot) and I just add the sections that contains materials and polys for the other meshes. (I used the original mesh in Max to set-up the collision and shadow in correct positions)

[SneaksieDave]

There is that ASE is simple text, so those without editors or editing experience can change the object's materials just by text editing the file. That's often handy. With LWO, you need a compatible editor or you're screwed. There might also be something about automatic smoothing options in ASE as well, but LWO and Lightwave probably have something for that too, I'd imagine...(?)

 

Edit: yah what he said

[Baddcog]

Ha, snuck up on Sneaksie!

 

I took a look at my keys, they are all 3 oriented the same way. So I'd prefer if the other 2 keys were changed if absolutely necessary which I'm still not convinced of.

 

btw Tels, you can download Blender for free, but that is ase, it's the lwos that would need changed.

 

I think someone else had mentioned the silver/gold key skin thing too. We should probably at least do that since it'll save a model. renaming doesn't matter to me.

[Domarius]

* Two collision models are missing. Also, the collision models for the keys with the ring do not have a hole, meaning you cannot put these keys on a "pin" without D3 complaining about them being stuck "in solid". (I am not sure if such a collision model is possible, tho)

The usual approach is to set the key there as a static entity, until it's frobbed. Once you have it, and then drop it, it's a moveable. And of course the player can never replace it on the hook themselves.

[Tels]

The usual approach is to set the key there as a static entity, until it's frobbed. Once you have it, and then drop it, it's a moveable. And of course the player can never replace it on the hook themselves.

 

I asked in another thread how to make a frobable object that is also static, but it got shot down because they keys should be moveables. And since that is what the majority of people want, that is what they are now

 

(Never found out how to make a static frobable, just have given up looking into it because it wasn't nec. anymore after it was decided keys should all be moveable by default)

[Springheel]

but it got shot down because they keys should be moveables

 

Moveables by default, was what we said. No one claimed that static keys were not appropriate in certain situations.

 

It might indeed be possible to create a script to 'swap' a static key for a moveable one when you frob it (I have no idea, but it sounds plausible). If so, then that would solve the 'dropping' issue, and would indeed be useful in situations where you want the key to 'hang'.

[Tels]

Moveables by default, was what we said. No one claimed that static keys were not appropriate in certain situations.

 

Since I was working on the default entities, that would mean the same thing as I wrote (I am not that firm in English to go on a hairsplitting quest with a native speaker, tho

 

It might indeed be possible to create a script to 'swap' a static key for a moveable one when you frob it (I have no idea, but it sounds plausible). If so, then that would solve the 'dropping' issue, and would indeed be useful in situations where you want the key to 'hang'.

 

It might be possible, but then we start to get a really long list of key variants:

 

* static, frobable, droppable

* static, frobable, non-droppable

* moveable, frobable, droppable

* moveable, frobable, non-droppable

 

The "droppable" is a simple property, so it could be done by the mapper.

 

But static vs. moveable is more complex.

 

Right now all key entities are "moveable, frobable, non-droppable", with the latter being adjusted easily by "add property" "droppable".

[Ishtvan]

The usual approach is to set the key there as a static entity, until it's frobbed. Once you have it, and then drop it, it's a moveable. And of course the player can never replace it on the hook themselves.

I think we could accomplish this most easily by using "bind" to bind the key to the world when it's hanging. When you frob it, it gets unbound. No need to swap items between a static and a moveable.

 

I'm not sure if we unbind items already when we add them to the inventory. It's unclear if we should, because some items are made up of two entities (e.g., candle holder and candle), that we actually don't want to unbind from eachother when you pick one of them up. Maybe it could be a spawnarg to control whether it unbinds on frobbing, or just make a frob action script that unbinds and then picks up. In any case, I think bind/unbind makes more sense than swapping the whole entity between static/moveable.

 

If you didn't mind if it fell off the hook when hit with something, shot with an arrow, etc, you could also just set it to wait_for_trigger, or whatever the setting is that makes moveables hang in space until they're bumped or frobbed. In that case you don't even need to worry about the bind keyword, although if the thing it's hanging on is moving it wouldn't respond correctly, you need bind for that case.

[Baddcog]

We can make a small keyhook model too so there won't be probs with the collision inside terrain.

[sparhawk]

A static entity is still an entity, and you should be able to make any entity frobable by setting the, surprise, frobable keyword on the spawnarg to 1. Of course that doesn't automatically make it highlight as well, because you have to use an appropriate material file for that.

[Ishtvan]

Yes, we have had plenty of static entities that were frobable in the past. Before we made loot movebale, it all used to be derived from statics. Tels already said he set frobable and set the frob action script though, so I'd need more info to know what is wrong with the setup. If he could post the whole entityDef, that might help.

[Tels]

We can make a small keyhook model too so there won't be probs with the collision inside terrain.

 

That would be very cool, because making keyhooks out of brushes/patches is tiring, and doesn't look as good, anyway