Baddcog's Models

[greebo]

I'll try and get some chains sometime soon, I saw a tex, I thought someone made a model already

I think PinkDot has some chains in his graveyard model set.

 

Nice jewelry btw.

[PinkDot]

I think PinkDot has some chains in his graveyard model set.

That one suits only (mostly) graveyard theme. If you need ordinary chain texture there's chain.tga texture (made by Oddity (? don't know)), I made a normal map for it when using for my locked crow's cage.

http://img.photobucket.com/albums/v305/Tod...hainpadlock.jpg

[Baddcog]

OK, back to topic

 

Added an emerald and pink gem (not sure what kind) to the textures and a skin for each. Touched up the ring tex. Resized.

 

Uploaded most of it, except the mtr and skins. For some reason SVN says my copies are out of date and won't let me commit my changes.

So I updated my mtr file and now alol the files have no breaks, instead they have a box(instead of paragraph break) and all the text is on only a few lines.

Anyone know why this is? All my mtr files are screwed.

[Crispy]

Ah... this would be the recent end-of-line indicator change talked about here: http://forums.thedarkmod.com/index.php?showtopic=6633

 

The files aren't actually broken; they're just using Unix-style line breaks instead of Windows-style. The change was made in order to be more consistent, since with both Windows and Linux users working on the files, we were using both styles.

 

The best way to work around this problem is to use a text editor that isn't Notepad. Most decent text editors can handle Unix-style line breaks. I use and recommend TextPad, but there are lots of other good choices.

[Springheel]

Don't forget to add your new models to the webpage once they're in-game. We're getting a little out of date again.

[Tels]

Ah... this would be the recent end-of-line indicator change talked about here: http://forums.thedarkmod.com/index.php?showtopic=6633

 

The files aren't actually broken; they're just using Unix-style line breaks instead of Windows-style. The change was made in order to be more consistent, since with both Windows and Linux users working on the files, we were using both styles.

 

The best way to work around this problem is to use a text editor that isn't Notepad. Most decent text editors can handle Unix-style line breaks. I use and recommend TextPad, but there are lots of other good choices.

 

If you still have problems committing your changes, send me a pm and I help you sorting it out.

 

One reminder to all others, tho: If you change something in the tree, commit it as soon as possible!

 

Every day you wait before commiting your changes increases the chance that somebody else modified the same file and you risk a conflict!

 

Resolving conflicts must be done manually, and can be a lot of work. Basically you must move out your modifed files to a different location, run "svn update" to get the latest revision from the server, then manually merge your changes to the files back in. Note the word "manually" here

 

So, make "svn update" quite often, and "svn commit" as soon as possible

[Baddcog]

OK, I thought 'end of line indicator' had more to do with extensions for some reason.

Textpad sounds complicated but hey, I'm a wild and crazy guy, I'll give it a try.

 

-EDIT

 

Cool, textpad is cool, multiple doc in 1 window!

 

 

cool site for gems, gem cut guides, ect...

 

--EDIT

bunch of messing around with files, my lantern bot spotlight went missing, screwed textures, someone deleted my switch hieght map???

Everything should be back to normal.

 

added model pics of gargoyle, gears, rings, teaset, doors to model gallery

[Crispy]

Resolving conflicts must be done manually, and can be a lot of work. Basically you must move out your modifed files to a different location, run "svn update" to get the latest revision from the server, then manually merge your changes to the files back in. Note the word "manually" here

Not entirely true... there's no file-moving required. You can just run the update and you'll get a notification of a conflict on the file and the means to resolve it. For example, suppose the file is called blah.mtr. If you run an update and end up downloading conflicting changes, then you'll get a notification of that and files named something like blah.mtr.mine, blah.mtr.r### (where ### is the revision number), and blah.mtr (which has the contents of both modifications, with added markers to denote which conflicting parts are from which file). It's not so difficult to edit blah.mtr manually to remove the conflicts IMO. Then, using command-line svn, you can just run svn resolved blah.mtr and you're done. Now you can commit your changes if you want to.

 

It's even easier with TortoiseSVN in Windows - just double-click on the file in the Update dialog when it's done, and TortoiseMerge will pop up. TortoiseMerge makes it quite straightforward to resolve conflicts, once you know how to use it. Just hit the "next conflict" button, pick which file should take precedence for that block, and repeat until done. Then save and click "resolve changes" on the toolbar.

[Springheel]

blah.mtr.mine, blah.mtr.r### (where ### is the revision number),

 

I thought it did this, but for some reason I didn't get that with my most recent problem with a merge.

[Crispy]

Well, it does normally. Maybe it misplaced them, or they were there but you didn't see them for whatever reason. Or maybe it wasn't a conflict, but some other error? I dunno, there could be any number of reasons.

 

The info you need is usually all in the file itself anyway.

[Baddcog]

added another ring to model gallery, uploading files now.

 

thanks for explaining the 'mine' files,ect... didn't know what they were.

[Tels]

Not entirely true... there's no file-moving required. You can just run the update and you'll get a notification of a conflict on the file and the means to resolve it. For example, suppose the file is called blah.mtr. If you run an update and end up downloading conflicting changes, then you'll get a notification of that and files named something like blah.mtr.mine, blah.mtr.r### (where ### is the revision number), and blah.mtr (which has the contents of both modifications, with added markers to denote which conflicting parts are from which file). It's not so difficult to edit blah.mtr manually to remove the conflicts IMO. Then, using command-line svn, you can just run svn resolved blah.mtr and you're done. Now you can commit your changes if you want to.

 

Well, this doesn't work as you write, maybe it depends on the client. I never got the .mine files. Likewise, some people get the old content just spliced into the files, etc. (which is even worse than the .mine files as they will usually just blindly commit the garbled files to the repository :/

 

Trying to resolve the conflict with SVN is only good if you know already what you do and how your SVN client works really - I prefer to move my files out of the way and then merge them manually as to whatever the SVN client might do

[Crispy]

I know it happens for sure with command-line SVN on Linux. I thought TortoiseSVN did it as well, but maybe my memory is letting me down.

[Baddcog]

Lockbox and lever with 2 skins

The trim plate is alpha so new normal skins can change the look of the box. I recomend leaving the keyhole and pivot the same on new skins.=-0

 

Old lockbox is gonna have to change, way too big for the keys. I'll adjust the size of the keyholes in my door skins too.

 

2 keys on left are mine, the other key and padlock are PinkDots. I'm thinking about making the fancy key top thinner like it is stamped.

 

The lock box may still be a little too large, appreciate it someone could take a look and give opinions on size, ect... no specular map yet, also need to get them working properly.

Did we ever decide if we want the lockboxes on chest models? Or should the author add em? What is gonna frob, the lever, the lockbox, the whole chest?

 

 

[Springheel]

Those look good, bc. They keyhold can probably be a little larger than the keys so that it's easy to see, but yours probably is still too large.

[Baddcog]

right on, I think I need to shrink the whole box anyway so I won't have to fudge around with the tex.

 

OK, resized, touched up normal map a bit.

[Baddcog]

Ornate cell door and cell door.

I'll probably only commit the ornate model, the corners can be no draw to look like the other door.

The bars are alpha with a shadow mesh so it'll probably need new models for different bar configs. the ornate model is only 210 polys so file size is small. door frame will end up same tex as bars.

 

(Gotta fix the alpha still and make all bars same length.)

 

Wondering if I should make the lock boxes on doors a bit larger? looking kindof small there but fits the keys real nice.

 

[sparhawk]

Did we ever decide if we want the lockboxes on chest models? Or should the author add em? What is gonna frob, the lever, the lockbox, the whole chest?

 

They look quite cool. Haven't checked them ingame, so I can't comment on the size. As for placing them, the best thing is if the author just applies them wherever he needs them. The lever should definitely be a seperate object, because this is the thing that moves when being picked.

 

I'm going to look at these locks in my lockpick map.

 

The cell doors also look great, but I don't really think of them as cell doors. They look to strong and well done for that. They remind more of vault doors, because I have the feeling that cells in those times didn't have such well done doors. More like simlpe bars to block the exit.

 

The lock looks indeed a bit small for that purpose, but I guess these locks can also be used for other things. You can check if they work properly when using the multiplication tricks, but I fear that the frobbing will not work properly with that.

 

When the code is released, we have to apply the matrix to the collision model as well, because otherwise we need to create many different sizes for the same objects, which is a waste of space.

[Springheel]

One thing about the lockboxes--those little levers are for when they're attached to chests, right? I was going to say that the handle might obscure them, but I guess you wouldn't have a handle and lever on at the same time.

 

The cell doors look good, though I agree with Sparhawk that they look too intimidating for casual cells. Also, I'm wondering if it wouldn't be better to actually model the bars? Otherwise, you couldn't shoot arrows or frob through it. Since you've already modelled a shadowmesh, how hard would it be to just use that as the basis for the texture?

 

Wondering if I should make the lock boxes on doors a bit larger? looking kindof small there but fits the keys real nice.

 

I think they should be a bit larger, personally. It doesn't matter if they don't match the key size exactly--no one is going to be holding the key up to compare.

[Ishtvan]

Yeah, being able to shoot arrows/throw objects through the bars would be better IMO. I also realised in Sparhawk's test map that, if the bars are wide enough, you can actually lean your head out thru the bars, but you can only turn so far sideways before your head gets stuck and you can't turn any farther. I thought that was pretty cool, and could imagine leaning through bars to pickpocket someone, or extending a mop handle thru bars to hit a button or something.

[Baddcog]

@Spar,

please do try em and let me know what you think, I just haven't had time to mess with that stuff yet but since you've already got a lock test map ;D

 

 

@Spring,

I made them exactly 2x1 proportions, mainly so the tex would fit good and easy to reskin. I agree, they might still be a bit large as the keys are probably oversized a bit themselves.

I'll let Spar mess with em a bit first, I think I'm also considering how to line them up with the grid also, most likely the center of the lever pivot will be on a large grid point so the lever is easy to line up correctly (the pivot on the front plate moves with the lever)

I don't think it matters as much if the outside of the box doesn't line up exactly with grid.

The normals were from a renderbump, I used alpha mainly as a polycount issue, I'm open to other options too. I was gonna do a crisscross style pattern also.

 

Well, I hadn't really thought about NOT using them without the levers. On a chest or wall I think they are needed. I don't know if I even like these lockboxes for doors.

I am going to redo the size of keyholes on the lock plates on my doors, guess I was thinking that the doors would have lockboxes on them already in the textures.

If you want lockboxes for doors I suggest we use the skins that are made/will be made for my doors. Can just make a seperate model that can be attached to terrain doors, ect... then it'll look more like the lock mechanism is inside the door not added on to it.

The door handles (I uploaded handle_curved_rotate - good shape,bad texture right now) would just need to be aligned with the lockplate.

 

@Ish/Spring,

I wasn't sure about collision, currently you can not shoot thru, but I can duplicate the shadow mesh and have a proper collision model. I wasn't sure how this would effect a moving door. Does a door fall under the moveable catagory?

[Ishtvan]

@Ish/Spring,

I wasn't sure about collision, currently you can not shoot thru, but I can duplicate the shadow mesh and have a proper collision model. I wasn't sure how this would effect a moving door. Does a door fall under the moveable catagory?

It falls under the moverer category. I think those can have complicated collision models, but I'm not sure. Sparhawk's cell door with bars worked fine, not sure how that was set up.

[sparhawk]

Yeah, being able to shoot arrows/throw objects through the bars would be better IMO. I also realised in Sparhawk's test map that, if the bars are wide enough, you can actually lean your head out thru the bars, but you can only turn so far sideways before your head gets stuck and you can't turn any farther. I thought that was pretty cool, and could imagine leaning through bars to pickpocket someone, or extending a mop handle thru bars to hit a button or something.

 

Really? That's cool, even not strictly intended. Never tried it though.

[sparhawk]

@Spar,

please do try em and let me know what you think, I just haven't had time to mess with that stuff yet but since you've already got a lock test map ;D

 

I definitely do. Actually I already started to use one of your padlocks, because that locker, where the keys are stored, was supposed to be locked. I just hadn't had time to apply the lock. Don't know if it is on SVN, because I already added the lock to the case, only it's not funcitonal yet.

 

Gameplaywise, it doesn't really make much sense anyway, because if the player can leave the cell, he already has the lockpicks, so he wouldn't need the keys. But of course, it's maybe logical for the setup, to have the keys for the guards somewhere near, as they would need them frequently. Maybe I can hide something in the second cell, which the player will need, to make it worthwhile to pick that lock and get the keys. I usually try to open all doors, so I would definitely grab these keys. But I'll make the heavy door unpickable, so you would definitely need the keys anyway.

 

Well, I hadn't really thought about NOT using them without the levers. On a chest or wall I think they are needed. I don't know if I even like these lockboxes for doors.

 

For regula doors, they would look a bit out of place, but for the heavy door, that I have in my lockpick map, I think they look good there.

 

I wasn't sure about collision, currently you can not shoot thru, but I can duplicate the shadow mesh and have a proper collision model. I wasn't sure how this would effect a moving door.

 

Don't know if you can do that. Aren't collision models supposed to be limited to 16 faces? Or am I confusing this with something else?

 

Does a door fall under the moveable catagory?

 

Yes. It's derived from it.

[sparhawk]

It falls under the moverer category. I think those can have complicated collision models, but I'm not sure. Sparhawk's cell door with bars worked fine, not sure how that was set up.

 

I created the bars and the frame from brushes, and then just combined it into a func_static, from which point I can simply set it to the doorclass. I also created the lockplate and the bars out of brushes, as they are simply rectangular anyway, but I thought for such cells, it looks good enough if they are crude. Only thing I don't like is the rusty metal on the cell doors. There is a noticable dark bar going through all of the bars, which doesn't look good.