Using the repository tecnique on lamps is exactly the same as usual (btw, bravo! seems that you have mastered the repository tecnique! ).
The Ilistara lamp has already two "Maxis" recolourable subsets, whose names are already perfect to be linked to slave objects.

What I don't understand (I don't remember now exactly what JWoods has wrote in the Repository tutorial) is why you deleted anything from the package: the clone should be complete, with its shadows and even the debrispile (that is quite useless in lamps, but removing it needs care).

Once you have cloned the Ilistara, remesh it at will and you'll have a perfect recolourable repository.
Just remember that you can link to a "lamp" repository only other lamps, because of the lit/unlit nature of these objects (you can link non-lamp objects, but only to the "post").

The slave objects must have, as usual, the same subsets names as the repository (post and lampshadow). Do not change the name of the subsets, neither in the repository, nor in the slaves, unless it's strictly needed (and in this case is not needed): though you are good at this "linking" job, you may miss a step and the links would be broken.

I returned the names in the repository to post and lampshade and it works! It's recolourable anyway. It's got to have something to do with the Material Overrides or something. I'll use the texture for the post in lots of other things, I've been careful to make the textures for the repository items very distinct from eachother, it's tricky - but it makes it worth the space on the drive. I know JWoods said that he had more than two recolourable subsets in his repository but (I had a look at the packages and I couldn't, for the life of me, figure out how) I thought it would be simply a case of adding extra models in the gmdc and extra Material Definitions and Overrides and an extra tsMaterialsmeshname in the geometric node, and adding other arrays here and there but... that's like walking on the moon for me!



'What I don't understand (I don't remember now exactly what JWoods has wrote in the Repository tutorial) is why you deleted anything from the package.'

I deleted things in the repository to start with, but then not deleting them didn't make any difference because I had changed the subset names. The repository only needs to have the Material Definitions, Material Overrides, Shape references, Models in the GMDC, texture images and references in the Geometric node (tsdesignmodeEnabled and tsnoshadows) for the textures you want to borrow? That's very likely part of where I went wrong.

I have changed the names of the subsets in the other two independant repository items I made but they were just for beds and chairs and tables. Single state textures.

In the slave objects I delete Material Overides, Definitions and Texture images that I need to borrow from and link to the repository. Shadows are always kept. And then I name the models (in the gmdc) to be the same as the models in the repository item(s) change the shape parts name and material definition to whatever it is in the repository item(s). Go up to the Geometric node and change the tsDesignmodeenabled and tsnoshadows.... Would anyone else need any help in the linking of basic objects to repositories? I think I'm just about there with the easy stuff. Nobody but me is needing help with this now though (not for ages). I must be a bit slow.

What makes a good repository texture, Numenor? Considering it has to work for many different things. I'm using windows with my repository items but they can't be as good as the Maxis ones no matter how carefully I map them - because, in Maxis, they are mapped for windows! It offers many more colour options (yes) and they match little bits of tables and beds. How many different repository textures does someone need do you think? I would like to be prolific and make lots of nice things that lots of people will want and that's my reasoning behind taking on this idea of seperate repositories sooner rather than later. I would 'like' to be! I now have three repositories, I've been able to delete the massive colour options that were previously appended to the originals and I've just about mapped everything I've linked to these repositories. It probably is a matter of conjecture but is this a good idea or not? The Maxis textures are so perfect. It saves space on the hard drive of the originator! If the textures are up to it then perhaps they can be linked to by other meshers while they add their own? I'm not that great at textures. I managed to utilise Paint Shop Pro to work with the Maxis textures when I first found SimPE but they are extremely proficient and artistic artists at the Maxis place.

Trying to reuse Maxis textures is really a good thing, since they are so beutiful (though sometimes it's a bit tricky map a mesh over them...).

As for having more than 2 repository subsets, well, that's a creation of mine :D
The only object, as far as I know, that uses 4 subsets is the Floor Mirror from the Grand Trianon set. The trick, in that case, was to add an additional GMND, not linked to anything else; its tsDesignModeEnabled contains the subsets # 3 and 4 (while the main GMND, that is part of the object itself, contains the subsets # 1 and 2).
For both subsets 3 and 4, I have then added a default TXMT and TXTR, that are not used by the object itself: they are only available for the slave objects.
Very easy, once you have understood how the repository works...!

As for the "perfect" repository, no objects are better than others... The only limitation, as said, are the "multi-state" objects, lit/unlit and clean/dirty: a slave lamp needs a repository lamp (at least for the subset that lits up), and so on.

Still having a problem with linking lamps to a repository, but it's a bit of a weird one that made me go and check the 'flashing blue object' thread. It's to do with the lampshades on the slave objects. The repository lampshade is recolourable and works fine but all of the lampshades that I linked to it flash blue. All of the colour options (for both the repository and slave) appear in the catalogue and the shape subset name and material definition file (in the slave) is identicle to those in the repository. The only thing I can think of is that the slave's material definition reference in the Shape is ##0x1C050000!reposcube3_lampshade_plainshade_lit and perhaps it should link to the unlit state instead? As I said though, it's exactly the same in the repository and that works. All of the lamp bases work and are linked. I'll try a fix integrity on one of the slaves and see if there's any difference. I remember reading something somewhere about having to change or delete a reference in multi state objects but if the repository works, I can't think of a reason why the slave shouldn't.

Samekh: Before I ask you to upload your package try exactly what you said , linking it to the "unlit". I believe that may be the solution... If not you are free to upload it to have it looked at...

I have tried that, linking it to the unlit state, it didn't work. I'll do some more checks to make sure I haven't made a stupid mistake before I submit it for checking. I can't have made the same stupid mistake with all of the lamps I tried to link to the repository though. If it's been done already there must be a solution.

I think you need to map each item, but you only colour one. That way, each object kows where to put each texture.

I could be wrong, but that's what seems to make sense.

I need a little more help (it seems the only thing I'm able to ask ).
I've tried to use the repository for my Xmas tree with lights; the idea was of linking the tree to the texture of Maxis pine tree (which could make my package really lighter), while leaving in the package the texture of the decorations.
I followed all the steps of the tutorial, but the result was a flashing blue tree.

I must say that I used as new subset name "treepine_tree" which I gathered from a cloned package, but I don't know if it is correct. So...
1) How can I retrieve the subset names used in Maxis objects?
2) Is there anything else that I can do to solve the problem?
3) Would it be enough to follow only part A of the tutorial?

Thanks Silvia

When you want to link your package to an external object, you need to know the original names for the Resource node and the subsets. In order to do that, you have to *clone* the "master" object, unchecking all the cloning options; this way, the internal filenames will not be changed or nemamed.

For instance, the Christmas tree has the following names:
CRES = christmasTree_cres
subsets names: tree (recolourable), christmastree_ornaments (not recolourable, animated via effects) and christmastree_presents (not recolourable).

Remember that when you link your object to a Maxis object, you don't have to put any ##0c1c050000! prefix, neither in the GMND nor in the shape, nor in the MMAT.

As for your question #3: the "Repository object" in this case, is the Maxis christmas tree, and it's already done; you have to follow only part B on your object (but remember not to use the prefix).

THANKSSSSSSSSSSS NUMENOR (sorry for shouting, but I'm so happy I did it).
Actually, I used the mesh from the pine tree (the one in gardening section) and not the Xmas tree, but I followed easily all your explanations.
I made two mistakes in my first attempt: I got the wrong CRES name and I put somewhere the ##0c1c050000! prefix.


I'd like to say a BIG THANKS to JWoods too. You two great men are teaching me a lot of things.

Silvia

I should have returned to say that I gave up on trying to link the shades to a shade repository!! I know you say it's possible but I had several lamps on the go and it's halfway to texture economy if I can link all the bases to a master which is possible. I think the repository technique is brilliant once we can understand the bones of it. I still look at the colour enabling thread and, in my experience, many of the problems with colour enabling can be avoided by linking to another object. I don't know how to efficiently add a material definition and overide and a texture image (and all linked together) which is what is needed for having two recolourable parts. I've read, somewhere, that all you do is export these things from another package and then import them but the linking is profoundly difficult and then there's the risk that the hidden data might crash the game. Linking to something else is much easier. It also means you can add a second recolourable model where there was previously only one because you get rid of all the definitions and overides of anything you want to link.

Is it true to say (this is something I think I learned) that for all models you want to be linked to a texture image held within the same package you need a definition and an overide (apart from shadows which just have a material definition)? So it goes, from the geometric data container (which hold(s) every part of the object) to the shape which can direct the models to use the material definition from their own package or look elsewhere. Then those models in the shape file, that are told to look internally, are pointed to their own material overide and from there to the definition? Is there a breakdown (luddite level) in the wiki for me?

If it's ok I'd like to ask a question here that I found it impossible to get the answer elsewhere. Why is it sometimes very hard to pick up an object in game? Like a remesh of a sofa I ran off - it's almost as if I need to select a precise point on a leg to move or recolour it? Is that data held in the Object data somewhere? It was a sofa when it was cloned. It would probably explain what to do about a complaint I had that people couldn't click on a plate on a table.

I still think the repository technique is a brilliant, powerful tool. It can go wrong. It takes some tinkering with independant repositories. For a while I thought the perfect independant repository was something that had a hard surface, a textile, a metallic portion, but the bleed through was horrific (zooming out bleed) particularly on tubular metal.

I recently discovered the perfect object to clone as a repository, or what I thought was perfect, and that was the crib. It has two subsets linked to the same texture. In effect you can have two different sorts of wood, or plastic, or fabric and you don't need to duplicate the textures. However, I discovered that the alpha channel of what would have been the bedding part was making any models linked to it diminish until they vanished on a zoom out. When I realised the problem I copied the data from the material definition of the frame to the same places in the bedding. Voila. Works now. I thought I had done something ridiculous and would have to remesh everything but a bit of clear thought prevailed. Should I make a clone of the crib and fix the material definitions for people who want a repository (for a template) where they can have two subsets sample the same texture image? How are you anyway?

Samekh, adding a subset and making it recolorable is not very hard, I have written a tutorial on it.

Numenor has a post about package structure. As far as I know, the Shape points to the Material Definition, not the Material Override. Not all subsets need a Material Override, but recolorable ones always do.

For the unclickable sofa, it might have something to do with the clickable area determined for the mesh. With newer versions of SimPE, when you import a mesh, you can select which parts will be included in the Bounding Mesh. The clickable area is determined by the area of those mesh parts.

Oh, can anything be changed within the gmdc then, or upon import?

If you're talking about the bounding mesh thing, yes.

I have an odd problem that I cannot figure out.
I'm making a living set.
chair = repository
loveseat and sofa = slaves

the loveseat and sofa are working just fine, the chair however, only picks up the textures when I'm placing the object down. I get "not designable" when I tried to change the texture via design mode.

I fixed my problem by recloning the chair with all textures, when I had only pulled one initially and it works fine now.

Thx a lot god Jwoods !

I tried my hands at this repository technique again after failing miserably and needing help from Lethe_s last time. Yesterday, I made a set of objects that all shared one texture in a repository object. It turned out wonderfully.

Today, I tried something I have been wanting to do for a while, but didn't feel like messing with the repository technique. After yesterday's success, I figured I should try it out.

I made a set of crosses a while back and I wanted an inverted series. The floor cross on a base works perfectly fine. The inverted cross pulls the stuff from the normal cross perfectly. Both inverted wall crosses show up in the game fine. They are even pulling the texture from their respective normal cross fine. They just aren't pulling any of the recolors of their respective repository cross.

I tried recloning them again and starting over from scratch in case I missed something, but it's still not working. I'm not sure what I'm doing wrong. I'd like some ideas on how I can correct this problem.

If the slaves borrow only the default texture, I'd say that you have correctly set the references in the Shape, but there is aproblem in the GMND (the tsMaterialsMeshName).
Double check it, and be sure to have the "##0x1C050000!" prefix in front of the CRES reference.

Or perhaps you have created the new block in the GMND, but you forgot to update the DataList Extension List.

Cool, I fixed it. Problem was in the GMND. Must have skipped the step where I add in the cObjectGraphNode's Datalist Extension Reference. Both times. And the next time in each when I tried recloning. Talk about absentmindedness...

Thanks for the help. Sometimes just need an outside mind to get out of mental loops sometimes I guess.

Giddy with rediclous amounts of JOY!

*does the happiest dance!

Ok I have nothing constructive to add here except THANK YOU! My window frame now pulls the proper textures (from Maxis) because trust me I suck really bad at textures, so bad I HAVE to use the texture coordinator editor in Milkshape rather than the uvmapper. (now if could just out a way to export those coordinates...) Its all those little lines, they totally confuse me!

so so very happy.

Thanks JWoods and Numenor for all this great information. I'm trying to make kitchen islands that use the same texture as a new kitchen counter I made. Ignorant Bliss sent me over to Numenor's counter templates, but by then I had already spent a week making my counters and I couldn't bring myself to give up on them yet. I have the island made - the mesh not quite perfected yet- and it works great but when I made a recolor of the counter it didn't show up as an option for the island. I've been fiddling with it all day without success. I was wondering if someone would take a look, if indeed it is even possible to get it to work with counters and islands.

Mage, cloning a Maxis counter the normal way will likely result in a non-working package, because the textures are not linked properly. That's why it's recommended to use the templates instead, fixing the bad packages is possible but quite complicated. You could still use your meshes and textures on new clones for the most part.

Thanks again, Ignorant Bliss. You mean I could make the island a stand alone object with it's own texture etc.?

What I meant was that if you reclone both the counter and island, you can reuse your current meshes and textures. Then, according to Numenor's instructions in the template thread, you can link the island to the counter for textures.