Just some stuff... - Another #%*& Sim Site

^{A very special episode...}

Adding/Changing Tiles

This is an explanation of how certain parts of an iff file work together. This will cover the basics, and illustrate through abstract examples how one may add tiles to an object, delete tiles from an object, move tiles around within an object, create a multi-tiled object from a single object, create a group of single- or multi-tiled objects within a single iff file, change the sprites used in an object, add sprites, delete sprites, and just all around OBJD manipulation.

Many of you will use tmog to make your new objects, and I often utilize it as well. This will hopefully allow you to use tmog even more to your advantage, with the aid of iffpencil2 and some knowledge. Firstly, let's verify what tmog does. Graphics stuff aside, it changes the Globally Unique ID number in each OBJD section of an iff file. That's about it. This is called cloning. When an OBJD is cloned (think of it that way, it will help later), certain things happen. Bitmaps and catalogue strings are left intact, as well as ttab and ttas sections. Since tmog is a graphics-oriented cloner, however, any unused spr2 and dgrp sections are discarded, as well as all spr# sections (this is the gapped-door problem we've all come to know). So what does this tell us? It tells us that GUIDs must be unique, or the OBJD will dissapear, and that sprites are connected exclusively through the OBJD section.

Let's say we have a one-tiled object (like a fishtank or something), and we want certain attributes of it translated into a two-tiled object. {If the object we want to alter is, like paintings or sculptures or sinks, one object within an iff file with several other objects, we would clone the original - tmog will discard all the unused bits. If it's just a lone object sitting in a far file somewhere, however, I usually just extract it and rename it - we'll be changing the GUIDs later, so there's no need to clone it}. Open up your lovely iffpencil2 by Tom, and open up the single-tiled object you want to change. Go to the OBJD section - you'll likely see only one OBJD resource. Now, in order for the object to actually be two objects, we need 3 OBJDs - any object with more than one tile needs a master OBJD that glues everything together. So let's go ahead and "duplicate" the existing OBJD twice, making sure to change the number of the resource (68155 to 68156 for example) so it doesn't overwrite the original {note for n-tiled objects you're adding an additional tile to - you don't need to make a new master OBJD}. You now have three OBJD, one master and two slaves. You should now have an idea of what your object will be, its name etc. - since iffpencil2 has an undocumented feature whereby occassionally changing a resource's properties can corrupt the resource, duplicate each resource one at a time - changing the title of the resource to reflect its destiny, for example, "master," "tile 1," and "tile 2," this time not changing the resource index number.

Now let's make them part of one happy family. Open up your master, and look for the line that reads "Master ID." Choose a non-zero number here, it doesn't really matter, as long as any other object in the if file doesn't share it. That master id must be the same in the additional OBJD sections - this will make them dependant upon the master OBJD, and you'll get that little "+" sign in a sqaure in tmog*. So go ahead and change the master id of each OBJD section in your new object.

Note, to make it cleaner, go into your master OBJD, and go to "base graphic index" - change it to "0". Your master OBJD doesn't have any graphics, it's just a placeholder.

*Just For Advanced Fun: you can use a trick with the above if you're daring - say you've built two sinks that you've cloned, and for whatever reason want downloaders to only download them together, as a set. Follow along the tutorial, and import your sprites in, adjusting some newly-created OBJDs to point to the new dgrp and spr2. Create two master OBJD, and give each a different non-zero master id, then make their slave OBJDs have the correct corresponding master id's. This will give you a maxis-flavored "stoves2"-style *.iff file - one *.iff, with two or more little boxes with a "+" in it when viewing in tmog. If you further refine the OBJf and add the correct init, main and miscellaneous BHAVs in the file, you could conceivably deliver an entire kitchen set in one single *.iff file! Virtually useless, but you are, after all, the boss of your own creations.

Since you duplicated your OBJDs, almost everything else in the OBJD is fine - all the catalog and thumbnail indices are correct. However, you have to tell the game not to display the master object. Open it up, and on the "subindex" line, type in "-1" - this takes it out of the world, so it can better act its part.

Your other OBJDs subindices are likely "0" - this means they will both occupy the same tile, tile 0. This can't be good. Go change one of them to "1" - later we'll find out if this is an amenable direction for your object. If it isn't, perhaps "256" might be better. It's explained mathematically later. You'll even get a formula.

You're almost there. You have a multi-tiled object - almost. The next step will require (for the easiest route) some tmogging, but before we go on to a program that's going to be strict about our object's architecture, we have one more thing to do. This part is very simple, but there are some more fun things we can do here, depending on your advancement. We'll just stick to the necessary for right now, though. The OBJf section. Some objects don't even have one. But if you're making multi-tiled objects, you'll want these eventually - they'll make a world of difference. Just duplicate your original OBJf piece, and assign a different number to it - you don't need these for master objects, just the real-world ones. So for a two-tiler, that means you just duplicate one. I can't emphasize this enough. It's easy to miss, and hard to troubleshoot if you've convinced yourself it's correct. DO NOT make an OBJf for your master OBJD. I forbid it.

There's one more thing you need to do to your OBJDs to ensure that they work - remember how we duplicated the existing OBJD? we've made a couple changes of placement and such, but these are still non-clones - they have the same GUID number. Open up your OBJDs again, and look for (what else) "Global Unique ID." If you've cloned your object out, this number will have your magic cookie in the middle. If you've merely extracted, it will be the original GUID of the object. Either way, however, you need at least two new GUIDs. Quirckiness follows this sentence. What I do here is go into tmog, and clone some random multi-tiled object, and using tmog's "edit" feature, check out a couple of its GUIDs - then I open up my edited object, and do the same. I'll then copy one of the GUIDs in my random multi-tile tmogged object, and paste them into the corresponding GUID field of my new to-be edited object - this is better than just randomly assigning a number, because tmog won't assign a number that's already been used by one of the objects in your sims directory. Just be sure, that when you're done swapping GUIDs, that you delete the temporary multi-tile object you cloned. It's very important to get rid of those OBJDs. If you can't handle the Tmog-randomization thingy, just assign a few digits yourself, and maybe reclone the whole thing right at the end of the process - but know that random digit assignment other than via tmog can lead to conflicts.

Now, if you go into tmog at this point, you'll see your new multi-tiled object sitting in there, and if everything has been done carefully, you can go into the game and place it. Unfortunately, it looks like both tiles are still using the same pictures...

Let's start off with a lecture: how do sprites hook up with your object? Via drawgroups, or dgrp. There's a section in the iff file for them - in fact, the OBJD directly calls the drawgroups, not the sprite resources. Remember, OBJD -> dgrp -> spr2. The OBJD (which is cloned and manipulated) has no direct connection to the sprites in spr2. The amazing iffpencil2 has no sprite editing powers, so don't ever, ever try to open the resources with it - actually, save your file RIGHT NOW. Done? Good. Now go open an spr2 resource. Learned your lesson? Never accidentally open an spr2 because you're not paying attention because your significant other is half-naked or you're on the phone or Futurama is on. Okay. Now, know that ip2 has a wonderful dgrp viewer, which themselves display the sprite resources. The dgrp is a very fun section, if you're willing to play around with it. But for our purposes here, we want to merely add sprites to our object, actually, one tile of it.

Remember when we changed the "base graphic reference" to 0 in our master OBJD? Go to that line in one of your other OBJDs, and see what it is. Now go to that section in your other OBJD - the same number, isn't it? Well, change it. It can be pretty much a lot of numbers, I've found, other than obviously "0" - but to ease confusion later, increment it by the first digit, not the last - i.e. if it's originally "200," change it to "300," instead of "201" (as ong as 300 isn't already a dgrp number) - now just remmeber that number.

Remember that number I just had you remember? Go to the dgrp section, and duplicate the resource "200"(or whatever it is) - but change the number to the one you remembered. Now what you have is a two-tiled object with different dgrp, but the same sprites. Yes, that's correct, you must change the spr2 as well. Just go ahead and duplicate them, changing the numbers in a systematic and memorable way - you'll need that. Because what do sprites need in order to be shown by an OBJD? - dgrp reference. You now need to go into the dgrp resource sections, and open them up - in the dialog pop-up, go to properties, and choose the corresponding new spr2 resource (it will have been updated in the drop-down menu automatically). When you're done with that, because you systematically copied the spr2, you shouldn't have to change any other numbers or offsets. Pres OK. Now - heheh - do that for each rotation of each dgrp. You can also do this slightly faster in the xml file that tmog creates when exporting all zooms, all channels - but it's really not much better than doing it while you're in iffpencil2 anyway. Different strokes, as they say. Besides, the ip2 interface makes it easier to keep track of which numbers mean what - if you go the xml route, make sure you pay attention to what you're doing.

Well now, that was fun, wasn't it? You should now be able to export your object through tmog in order to get at the sprites and change them - here's hoping you picked an object with enough rotations for your satisfaction. You are now ready to unleash this monstrosity upon the world!

I learned all the subindex info from p8ntmstrg's site - he has a nice diagram of the subindex values for each tile laid out in tmog's default view angle. column 1 begins with 0, column two begins with 256, column three begins with (256+256=)512, column four is (256+256+256=)768, and etc. So presumably, an object could be 255 tiles long by (infinite) tiles wide - but there aren't any lots quite large enough, although I don't have the later expansions yet, so maybe...(sarcasm).

By the way, all this subindex info can be used to simply rearrange other objects as well - although if tiles are unattached, there's occasionally a problem with the game showing it. Also, you can just put all your tiles on the same square - rather convenient if you're editing an animated object and want to build it out of a series of simple animations.

That's "fun" - it's a pun. Anyway, the OBJf is what tells the game how to treat objects - most notably, "main" and "init" but also things like "load" and "gardening tree table(which the gardener uses to water plants - you get the idea)" - so you can actually assign different initiation and main routine BHAVs to any tile. Simply have the BHAV you want to use, and open up the OBJf and change the corresponding numbers. This is helpful if part of your object needs a wall, or water, or can be placed next to walls - if you've made a large object out of a one-tiled object, you don't want it to be able to intersect walls, right?

I mentioned this in passing a while ago, but didn't elaborate. And I shouldn't have to, either. Try it out. You can import spr2 like crazy, and then assign them to your new object. Don't forget the original offsets of your import, and make sure you don't fumble up the zooms, or it's a world of hurt. You can also add on "layers," if you choose - it's surely a lazy answer to someone's problems. Give it a shot, innovators, and show us what we can do.

If your object shows up with a hole in it, you didn't fix all the GUIDs. If it's invisible - same thing. If it doesn't show up at all, better make sure you don't have an OBJf for your master OBJD.

If you're doing an animated object, use the BHAV routine ‘update multi-tile’ from the global iff file — I kind of forget where it’s supposed to go, but probably in main for most simple hacks — more complex usage items have seperate routines, but basically whereever the call for animation goes. And if you're making an object that reacts to neighbors, like the arches or counters, make sure you add some "dynamic sprite update" codes in the BHAV sections.

- end of tile info -

Adding/Changing Tiles

More Randomness... More Fun... Click Here...