AS THE LEGACY OF THE SIMS CONTINUES, SO DOES OUR PROJECT'S PROGRESSION...


Maxis Beta Conversions Mega Pack

Players who are new to installing CC will also be able to download all (state-of-the-art) object ports at once using our new Mega Pack. Cursor/Walls/Scenarios from the "Miscellaneous Goodies" not included — only Buy/Build mode things that can be held with the Hand Tool!

Platform	Comments	Download
	1-Click Mod Install for The Sims Legacy on Steam. It automatically installs all objects for you! Recommended if you're new to installing mods.	lpx_betaobjs_megapack_steam.zip — 13.6 MB
	1-Click Mod Install for The Sims Legacy on EA app. It automatically installs all objects for you! Recommended if you're new to installing mods.	lpx_betaobjs_megapack_eaapp.zip — 13.6 MB
	1-Click Mod Install for classic The Sims (2000-2005). It automatically installs all objects for you! Recommended if you're new to installing mods.	lpx_betaobjs_megapack_original.zip — 13.6 MB
	Manual Install file. Can be used for all Sims versions. Recommended to advanced users who are used to installing mods.	lpx_betaobjs_megapack.zip — 14.1 MB

Figured I'd ask this here instead of using a whole new thread since it's directly related to what I'm doing in Level 3: Is it known which individual EPs understand interests in single digits 0-10 versus which understand interests in multiples of 100 (i.e. 0-1000)?

Because it turns out the zeroed interests are actually just REALLY REALLY low interests in a Complete Collection/all EP installation and thus I think I need to put in an EP check and modify the behavior accordingly... but I want to make sure which EP it actually changed with (and whether it's specifically "has the EP" versus "has that EP or any released afterward"). It looks like it MIGHT be Hot Date that did it which would make me think Hot Date+ rather than "has Hot Date", but I dunno. (What's not helping with that: The Unleashed families have low non-HD interests and only have normal HD interests.)

(The alternative is to just use hundreds everywhere--Edith doesn't seem to have a problem writing hundreds to the interests. But then depending on how a non-hundred-interests installation interprets it, it could inadvertently make things VERY easy.)

ooooh let’s investigate.

First, the obvious: Vanilla game logic still handles character talk interests using single-digit values (0–10). So, that’s not where we’ll find our answer.



Edith 2.0 (used for object programming up to The Sims: Hot Date) lets us peek at the BHAVs of objects made for the game until 2001. Checking out the scripting tree for Livin’ Large’s telescope, you’ll find the alien abduction code does more than tweak personality traits—it rewires the Sim’s entire set of interests, leaving them hyperfixated on aliens and violence. And yup, it’s still stored in that classic single-digit format.




House Party doesn’t seem to have an object with scripts that explicitly handle character interest scores, so I couldn’t dig into that expansion in detail. I skipped it for now.

Hot Date, on the other hand, introduces something different: the "just chat" phone feature (which made its debut on Hot Date as far as I'm concerned, and it's handled by a separate global iff) has conditional nodes that, for the first time, track Sims' interests in multiples of 100!!



I can definitely take a later time to raid a classic House Party CD copy to see if the any of its NPCs are born with 0-1000 or 0-10 interest scores, but it's safe-ish to say that the EP that modified the interests score system has has has to be Hot Date. It makes sense in the context that it brought the concept of interests that can be upgraded the same way as the work skills can— the decimals between 00 and 99 would basically serve to update the head icon that shows how much of the interest has been "learnt" as the sims read magazines.

...It only occurred to me AFTER that prior post (upon reading "check NPCs" in your post) that I could check the generated Sims' values and not just the ones that came with Unleashed. (I think it's likely this is a Hot Date+ situation and not a "Hot Date specifically" situation, but let's take a look at all Maxis created/generated Sims anyway.)

- Base game families: I'm making an assumption they're single digit still because the tool I cracked these open in for this quick check was SimEnhancer and it refused to read neighborhood 1??
- Mashuga (LL, Deluxe in my case): Singles for ALL values (most HD values are 0 but one (technology) is 2?)
- Townie (HD): Hundreds for all values
- Vacation: Hundreds
- Burbs (UL): Single digit interests for everything other than five of the Hot Date interests, which use hundreds (Johnny Burb, as a child, has no Hot Date interests and only has single digit interests)
- Charming (UL): Single digit plus five HD
- Goth Sr (UL): Single digit plus five HD
- Hick (UL): Single digit plus five HD
- Ginia Kat (UL): Single digit interests for everything other than five of the Hot Date interests
- Strays (UL): ... 🐶
- Somebody/Anybody (SS): Hundreds
- Strange (MM): Hundreds

At minimum this suggests the Unleashed families were created in an environment that did not have Hot Date style interests AND that an all-EP installation (which includes Hot Date in its EPs) generates hundreds-based interests. At most, this suggests all post-HD EPs generate hundreds-based interests (a Hot Date+ situation rather than a Hot-Date-needed one).

Perhaps it's safest to do a Hot Date+ check rather than a Hot-Date-specifically check and if there's some edge case where that's wrong then people who have some sort of higher EP but DON'T have Hot Date just get free super personality points. XD

I always knew there was something minimally weird about the Mashugas



I second that; when I checked the pre-Hot Date NPCs' "do I like topic" BHAV, they referenced single-digit interests, while they were in their hundreds when I checked the same tree in a Complete Collection copy via Codex, so maybe the game has its way of 'upgrading' the characters' interest system the moment we first interact with them



Just out of curiosity: how are you handling the characters' interest scores in the port? Obviously, topics like religion and that other Blah Blah Blah one didn’t make the cut, but are you trying to assign equivalent ones, or is the sorting done more arbitrarily? Oh and is there a specific piece of Level 3's code that checks the characters' interest score at all?

...Why did I say personality in my prior post? 0_o I meant interests the whole time. XP



Nothing in Level 3's original behavior from the beta looks at interests at all. The checks for progression in the level basically check if Ross has built the relationship to a certain level with one of the women and (barely) guides the player toward doing that until their relationship is over 95 (they both have to like each other; it can't be one-sided). (The extra version I've put together that allows Mercedes/Sam as a win (which is currently named Level (E)3 ) is the same other than that it includes a check for Sam and Mercedes liking each other.)

It's just that when I went to test it in my all-EPs game, it took several times longer than doing so in 1.1/Edith because interactions kept going negative, and my best guess as to why is that it's hard to talk about interests when you barely have any (and thus the game's built in social interaction logic is kneecapping the scenario because they don't like any topic). (And then when I just let them sit there autonomously after fixing some object issues on the lot and reimporting it, they all quickly hated each other.)

So adding an optional setting (i.e. not required in order to start the scenario) for changing the characters' interests is mostly a way to allow for avoiding making building a relationship harder than intended by at least making them have interests in the first place (since this is probably mostly a HD+ issue I could probably have gotten by with just offering a setting that's only available for HD people but I might as well offer it for everyone as a "hey, make the Sim's interest match the beta!").

I believe I consistently mapped beta interests as follows:

Sports = Sports (sports is sports)
Religion = Outdoors (...I think my logic is that some outdoors people treat it like a religion? I dunno)
Art = Music (music is a type of art)
Politics = Politics/Pets (politics is politics)
Gossip = 60's/School (I think I based this on the logic that people gossip in school... even though the adult interest is the '60s)
News = Weather (weather is something you see on the news)

I left Travel/Toys and Violence/Aliens untouched.

🏳‍🌈🏳‍🌈🏳‍🌈
I'm curious to see what the Sam/Mercy kiss dialogs will be. No spoilers, please



Dunno if it speaks for my chronic inability to sustain healthy relationship scores in HD+ builds, but....wow, this scenario might take a long time to be completed, even when they interest points are well ported!



First thing that came to my mind was the saying “if the mountain won't go to Mohammed, then Mohammed must come to the Mountain”


===

ooook, my next contrib would be porting the default beta food SPR2 —> or, at least, creating an alternate default replacement hack that only modifies the food graphics whose appearance stayed the same across versions, to those who are not on board with the concept of having diploma-looking items as pizza boxes! Some of the sprites didn't change much from their finalized iterations (if at all), plus they have the perk of being extravagantly ROTATABLE!

edit p.s.: The group meal graphic objectively is a plate with chicken/green beans/red potatoes! Dive into this design document (mind you, the food trivia bit is the least interesting bit in the great scheme of the document haha).

I've gotten the EP check into the Level 3 objects and have for the most part tested them! With the hundreds/singles fix, the level takes about the same amount of time in Complete that it takes in Edith. (Though it's worth noting: I tested these with the advent of being able to switch off motives (Edith) or use a Simlogical party plant to make social the only important motive (Complete), since my testing protocol was "make sure the win condition is achievable" and "make sure all dialogs can pop up provided the scenario runs in such a way that they're allowed to".)

The EP check looks to see if the game edition is more than 3 (HD or higher) and then additionally checks if the game edition is *exactly* 5 (the highest release installed is Deluxe, AKA Deluxe has not had UL/SS/MM installed over top), and if it is 5, it then checks if Hot Date specifically is also installed. I don't have an extra computer handy to test if my memory is correct (I found out when I was having reinstall issues that apparently every laptop in the house has multiple EPs installed, except for one which only has the base game... which no one here owns???? the lowest in this house should be Deluxe????), but I have vague memories of when I only had Deluxe installed and seeing single digits in the interests cheat, so Deluxe is treated like base game/LL/HP for that reason unless the user explicitly has Hot Date installed.

If my memories or assumptions are incorrect, this could mean that for someone with only Deluxe (or Deluxe and HP and/or Vacation but NOT Hot Date) the level could be harder than intended (if I misremembered and Deluxe actually uses hundreds). 🤔

Alright, in light of this thread hitting 50K views, here’s something different. I dug through some old unreleased files in my inbox and landed on this one—partly because a few folks had asked if there were any more prototype assets floating around. Turns out, I had an old email from Don Hopkins (The Sims engineer) with a 3d max mesh of an early plumb-bob iteration...



It’s now swapped in as a usable skn/bmf mesh, so if you ever feel like replacing the final plumb-bob with this beautiful thing, have at it!

Sample	Source	Comments	Author	File
	head-arrow.max	A late iteration of the plumbob accessory (still internally named as "head-arrow", taking its semantic approach quite too literally, shaped like a real-world plumb-bob. I almost certainly assume it's from March to April 1999. It's noteworthy that, prior to E3 1999, the plumbob was already finished. The zip file contains an "ExpansionShared" equivalent, if you also want it to be used during the dating scenario.	LUCPIX (courtesy of D. Hopkins)	lpx_early99_head-arrow.zip

On to a loose fact: upon opening the .max mesh, it'll warn you about a chunk of missing files, as well as their expected addresses... are the file names familiar to you?

It gives me the feeling the source code could be floating around as well! Stay tuned for the next chapters of this soap opera...

Ooh, that plumbob almost looks like a UFO, ha.

In completely unrelated news! I've done it! Level 3 is "done" so far as I can tell! http://www.simfileshare.net/download/5342236/

The houses and objects should be fine, though I created the readme so fast I'm convinced I left something out of it. It contains all the same options for importable houses as the other two (base game vanilla compatible, Steering objects, and Steering match). It has TWO versions of the object in the zip, though--the standard edition that matches the beta, which is what's placed on the prepared lots, and the "all pairs edit" (AKA "Level (E)3: The (Gay) Kiss") which is a version that is exactly the same (other than its catalog entry/icon) but counts Mercedes and Sam falling in love as a win too, and includes corresponding new dialog text for that branch of options. These are two unique objects with two different GUIDs so they can both be put in the game just fine (though I wouldn't recommend having them both running the scenario on the same lot at the same time, though ).

I've made a few changes to some of the Level 2 house versions (and slight changes to the Level 2 object itself) that mean I should probably put an updated zip for that together, too... but I don't wanna right now, lol.

Worked smoothly on my end! I played it with a simultaneous prototype window side-by-side with your port and sometimes I mistook between the two! I am very proud of how far we've come with this project. Loved the extra "Sam+Mercedes kiss" outcomes. Made me wonder... why the heck didn't I include the WALLS to the mega pack?... ... ... ... ... ...

Mind if I eventually record and upload a youtube video demoing the scenario?

Sample	Source	Comments	Author	File
	Level3.iff	The prototype's third "learning" scenario... now playable in high fidelity in the final product — even with a "bonus" level file that allows Sam and Mercedes to be the ones to kiss each other and win the game!	purplewowies	pw_steering_level3 (object and houses) v1.0.zip

(summer, summer, summer is almost gone... I predict I will have less useful time to work on ports, or anything. Or, at least, they will be done at an intermittent pace)

Something I found out the other day (while trying something in the hex that didn't pan out) I was surprised to learn... the Jefferson Demo goal strings exist in Steering Committee's files?! Wild.



Go for it!

...At some point I've gotta figure out which weird things I think would be good to include with Level 4 since it's guaranteed to be both simple to make AND very empty. Do I include fun things I've been playing around with but haven't mentioned here? Do I share Outside.iff even if I don't figure out its weird looping issue? Do I put off Level 4 and try to play around with the bed some more?

A bit of a nothing kind of update as I had already basically manually ported it (though not yet released it), but I decided to give pulling EVERY resource out of the beta's Outside.iff purely via importing the hex just because some other plans I had today did not work out how I wanted (and I wanted to investigate the sound playing settings to figure out the loop issue)... and it worked! IffPencil did not recognize the STR# correctly as structured (and I couldn't verify whether or not that was due to error on my end (i.e. guessing at the hex to copy) since the beta's resource viewer won't show me the hex for the STR# chunk) so that was the only one that I just did manually in IffPencil by making a resource rather than importing it.

I have not tested it in-game (if I had, it would be a "silly sounds" version of the object since it's relying on old IDs that in the final game are sighs and failure stings and such--to use the proper sounds it'd need what I did to the manual port with FWAVs), but I *did* crack it open in Edith just to make sure it wouldn't explode. The act of doing this showed that every part of each BHAV survived... and also converted the OBJD from version 136 (beta) to 138 (final) and the POSI to TREE (and TPRP?). Interesting! (But not unexpected. Documents regarding iff say that the POSI will be removed if a TREE of the same ID is saved, so I presume Edith did that when I was looking through the BHAVs.)

I'd say this could have interesting implications for other objects except that hex editing is just annoying enough that I was mostly interested in doing it on this object since it had pretty small/simple parts.

Another sort of nothing kind of update but less nothing than the other nothing! I attempted a hex frankenstein/reconstruction of the aquarium and have determined a few things (why am I starting to enjoy the hex editing life??):

• I *think* that the aquarium will function properly if I get working sprites onto it so I can actually properly click and interact with it. (I need to move the beta sound effects over, though. Could try using the final sounds instead but if we're going for accuracy...)
• The beta aquarium has the same GUID as the base game aquarium. Fun! (I still have the matching GUID version for some investigation mentioned lower down (because the matching-GUID version I'm working with hasn't been opened to convert some resources to newer versions in Edith) but I did clone it in T-mog specifically so that I didn't have any especially weird effects when testing it in my install.)
• If an object doesn't have a CTSS then the game can and will use a CATS! Fun times 2!
• The aquarium's POSI resources were WEIRD (several in the hex editor I was using just did not match up with what beta Edith was saying they should contain) so only about half of the BHAVs retained their original box positioning and comments in Edith because I left out POSIs I was unsure about.
• The SPR# issue the bed had in my couple of tests with it persists on the aquarium so it's not just a fluke (specifically, the sprite if using the beta SPR# resource will produce constant C++ errors in basegame Edith, just doesn't load (but doesn't error) in an all-EP non-dev install, and crashes T-mog if the sprite is viewed or the object is exported in an attempt to change its sprite). It also crashes some other Sims 1 programs that can display SPR# like Sim Explorer.
• The exact WAY that T-mog crashes on export made me want to dig deeper and see why some SPR# resources, like the ones in the pedportal, work fine while these beta ones don't. I didn't get very far but I do find it interesting that according to information online about SPR# hex structure (https://web.archive.org/web/2022021.../tech/spr1.html ), the pedportal--a working SPR# object--has 12 sprites in its SPR# but the beta aquarium SPR# seems to have 24. I wonder if that could be part of why... Then again. Maybe not now that I've typed that out--the ped portal has flipped sprites so it only needs half the amount...

All this to say that I get the feeling I'm probably going to get the aquarium into some sort of releasable state sooner rather than later... but I want to spend a little more time exploring whether or not there's any way to actually keep the SPR# and edit it to have it work somehow without manually converting it into SPR2 (i.e. by throwing final sprites in there and editing them the old fashioned way with T-mog).

hi,can you share edith 2.0?

Small update to my last post: It turns out the SPR# import breakage has a non-zero chance of having been caused by IffPencil itself... but also, if that's the case, it ONLY happens with "data-only" imports, and if a properly structured iff-with-resources import is done, the breakage is not there.

Granted, I have only tried this with one file that was not actually FROM the beta--the actual resource part of the SPR#/PALT (and probably also the DGRP) inside the pedportal is identical down to the byte with the beta's end table so I made a safety copy of the SPR2 version of that I've already shared here and started going to town getting the pedportal sprites to just... *work* in it. Had a lot of problems until I just imported the spf for the pedportal and from THERE I'm now obsessed with whatever is causing the different import types to work differently (such that a data-only import causes a crash whereas an iff import of the same data is fine).

ALSO granted: Making a *properly-structured* iff for importing with the beta SPR# resources in it but *without* whatever's making them crash stuff is easier said than done. But I still want to explore if it's possible just a bit longer before pivoting to SPR2.

EDIT: IT WORKED WITH THE AQUARIUM! THE ROTATIONS IN THE DGRPS ARE WRONG (wait no that's beta accurate) BUT THIS IS NOT A DRILL

Okay, so a little context on my last post:

The reason SPR# resources were causing so much crashing and weirdness in my previous tests is that when you import a "data only" resource, IffPencil sets up its header as appropriate. This is normally fine... but the game (and T-mog. and SimExplorer.) seems to expect SPR# resources to have a flag of 00 in the resource header. IffPencil makes this flag 10 (which, again, is normally fine). If you import a SPR# from an iff then IffPencil uses the existing header, so if the header in that is fine then the flag will stay 00. It is also possible to directly edit the flags via a hex editor, though I had some slip-ups that kept breaking the iffs so I was essentially making spf files, fixing the SPR# resource headers in THOSE and then importing the fixed SPR# resources to keep extra safe. The pedportal was invaluable in figuring this out, since I could import the data-only iff from that data, find out it didn't work, and then compare the two including the header to realize what was different.

SPR# resources when used directly in an object (rather than cracked open, sprites pulled out, and manually turned into a SPR2) appear to behave differently in-game than they do in T-mog. T-mog interprets it as having a really bad Z that does not match the beta. (I get the feeling if you were to export from T-mog and import unchanged to the same object, you'd get a messed-up Z version too that then propagates to the game.) The game seems to interpret the SPR# either identically to the beta or substantially similarly to it, at least as far as I have been testing with the aquarium. If T-mog's behavior is similar to whatever was used to extract the beta resources that have been provided in the first post, then it is possible that for objects with multiple sprites in a given drawgroup where the Z buffers of manually-created SPR2 sprites are obviously off in strange ways, the fastest way to achieve beta-accurate Z behavior might be to try to directly import and use its SPR# (one could of course manually start messing with the Z buffers instead, but funnily, working with raw hexadecimal might be a simpler option XD). I'm trying again with the bed using the beta SPR# resources there to see if this hypothesis plays out for two different objects, but it's not currently in a state where it will load in-game.

The aquarium is mostly done. It's using final game aquarium animations and has had child animations added--I'm going to make sure there's not a better alternative for the feeding animation in particular (it's just off enough compared to the beta that I want to see if some other animation fits closer). What I'm having a real problem with is the sounds. Everything should be correctly formatted but the sounds aren't playing in-game. I'm going to see if this is user error on my part but if it's not then in the next few days I might release a version that doesn't use beta sounds, just to get it out there. (Then again, with my luck, the aquarium will no longer work with the normal aquarium noises. XD)

Okay! So! I've put the aquarium up! It turns out the problem was an issue with how the FWAVs were formatted in the beta (as in the sound names) that I completely missed when directly grabbing them for the port. The aquarium DOES have the same weird looping issue I'm experiencing with Outside.iff but I put a kill-sounds line in the relevant BHAVs that should keep it from continuing forever. It feels like only a partial fix, though, so I've numbered the version of the zip accordingly. The entire folder inside of the zip should be placed directly in the Downloads folder. Putting it somewhere else or in a subfolder will keep the sounds from working.

http://www.simfileshare.net/download/5552974/

I might need to change one of the child animations to match what I went with for the feeding animation for adults (I copied the restock animation because it more closely matched the beta's feed animation). But I only realized that after I uploaded and I didn't want it to affect sharing it.

External tools like T-mog and SimExplorer (the two programs I have available that will display the SPR# objects at all) do not display this object's sprites correctly, but they show up correctly in-game from my testing.

All functions work as expected, though I was only able to test the restock behavior using the all_menus cheat in Edith (I could not get the fish to die naturally in an easily manageable amount of time).

...Have fun? (Well. Don't have fun actually. This object doesn't raise it! )

Relatedly: I did this process that made the aquarium a second time to make the cheaper bed (the blue one, which shares a GUID with the final game's full size sleigh bed, funnily enough). I had similar good SPR# behavior (it does not have the Z issues the SPR2 import version with T-mog was having, just weird issues the beta ALSO has). However, it has an issue with its routing slots that is preventing testing its functionality until I fix it.

Eat this!

Sample	Source	Comments	Author	File
	mealsnack.IFF	This mod is currently incompatible with the "Child Sims Can Cook"! mod! — This tiny mod replaces the Maxis graphics of some foods in your game to their early renditions used in the 1998 prototype. It's a modified clone of Complete Collection/Legacy Edition's own food objects, so it may not work in the base game. Beyond the obvious different appearance of most of these sprites, you will notice that some of those graphics look exactly the same as their final renditions (most noticeably the pot and regular meal ones, described in one design document as "a plate with chicken/green beans/red potatoes", in case you ever asked yourself what the hell your Sims have been eating this whole time), but now with the slight (quantitative) advantage of manifesting in the game with unique pre-rendered graphics per rotation/zoom, rather than always facing the same direction, no matter the current perspective of the dollhouse world. Sure, the prototype does not have early equivalents for every food graphic that you see in the final product: During that time in development, the characters still couldn't buy a BBQ grill and prepare burgers, for example. Then you will see that the graphics for certain foods (burger, fruit cake, box of chocolates) won't look any different as the mod is installed, as early equivalents of these graphics are not known to exist. Furthermore, while you can (in its own uncanny way) dial a pizza place in the proto so a nonsensical rectangular pizza box appears right next to you, a further check at the prototype's food sprites file informs us that its ID is labeled as "Cracker", so I chose to leave the pizza's final graphics unchanged as well, and only replace the graphics of the default snack that the Sims grab from the fridges.	LUCPIX	lpx_1998_food.zip
	aquarium1.iff	Prototype graphics/behavior/sounds/goldfish included! If you buy this aquarium and believe there's something suspicious about its presentation in the game itself — talk about those algae of swapped rotations that extend far beyond the glass and defy many rules of physics — know that it speaks volumes about how brilliantly ported it was, for that's the kind of uncanniness that the object's draw groups were subjected to in its original prototype form. I'm secure that this marks a cool new phase for this project where we will focus on benefitting ourselves with some hex tricks to ensure the porting processes are agile so we can keeeeeeeeep swimming.	purplewowies	pw_aquarium1_steering v0.8.zip

The aquarium was added to the revision of the megapacks, but you can also get it as an individual download

Sprite pack updated -- It now includes the mealsnack/toilet1/floorlamp1 graphics. I believe all the objects' color/z channels have been properly extracted now. Download here

toilet1 and floorlamp1 were added to the final set of pending conversions.

========================================================



Edith is not a standalone tool like HomeCrafter of SimShow! You will have more luck finding it bundled with a development build of the game. The only 2.0 version of Edith that I know of comes as part of the Pre-Alpha build of Sims Online... it's somewhere around archive.org software repository, that's for sure... but you will have to look!



Interesting -- and they don't seem to be different from the texts of same kind in the design documents written around that period. I very loosely speculate that some unused graphics in the final game listed as part of an old sprite hierarchy that goes by "headline" also come straight off of Jefferson.



Nice cclogging (custom content logging?) all around! But it's much cooler to see that the effort paid off after all. Can't wait to try these hex magic myself in case I find that one or two of my ports didn't quite meet their potential (VERY likely!!!). Although the mysterious fountain2's draw groups have have have to be, say, 95% faithful to Maxis tile placement coordinates, both their twinkling-water and fountain-per-se sprites are probably a few pixels off.

Since the datamining/modding DIY aspect of this project justifies it a little more than its "CC" aspect (I mean... people are not downloading that phone or flamingo on the basis of how aesthetically cool they look in the final product... are they?), maybe we have more enough to compose an "Object List" proto sub-article on TCRF listing our ported items in a half-technical way, but friendly to curious readers, comparing them to their closest final iterations (if there's any). There are pending ports, but nothing can refrain one from labeling it as an article in progress down the line! I think that a conceptually similar article written for Super Mario World is a good reference for what can be done here on The Sims' end, except it (fortunately) won't be as lenghty and time-consuming, since the 1998 proto does not have as many items as 2020 gigaleak SMW's cache of graphics. Deciding upon how the objects must be displayed on the article's tables would be a problem to be solved, but I believe that having their DGRP-y representations listed in all their available rotations would be more than enough, as long as their indexes and names are also commented in — dissecating their graphics into individual sprites would perhaps make it more "advanced" but disorienting or hard to visualize to casual readers.

A first shot at the Object List article is here

Definitely some potential ahead!

Table layout is temporary (probably), but I think it's sufficiently informative

Sample:

As with the final build of The Sims, IFF files are used to store all the information relative to objects in the prototype, including tree code, name, description and graphics. Conflicts in how the different resources are organized in both the early and final object files — for example, the former's utilization of the deprecated resources CATS and POSI (early versions of CTSS and TREE, respectively) appears to keep the prototype objects from being natively compatible with later releases of the game.

Many of the prototype objects were not included in the final product, or were to a notably large extent enhanced. Aside from stylistic decisions, these objects possess several shared traits that distinguish them from the final objects — in fact, it's a safe bet to assume that such traits are one of the key reasons why these objects were ultimately scrapped, to begin with.

1) Edges of the objects are not antialiased, therefore missing smooth edges.

2) The dynamic object shadowcasting effect wasn't yet introduced. Yet, many objects (phone, computer...) have an intense pre-rendered lighting that causes visual conflicts between rotated objects of the same kind, thus looking unsatisfactory.

3) Save for a few exceptions, symmetrical objects have unique pre-rendered graphics per rotation/zoom. Again, this highly contributed to lighting/shading divergencies between rotated objects. The object rendering method in the final product avoids this by having flipped dupes of existing sprites to fill the missing half of rotation/zoom slots in draw group ids whenever necessary and possible.

4) This prototype has a sample of an old experiment associated with the implementation of diagonal objects (duck), containing draw group ids that support twice as much sprite rotation indexes as any other objects, being the only known object in the entire game that has such trait.

Something about seeing the objects page has reminded me I've been meaning to stare at the hexadecimal again, not because I think it will further help me create the bed (bed3 I think will need to become a frankenstein of the beta code and the final bed's code, because Sims will go to sleep beside the bed rather than in it and then sleep forever even if you cancel the action...).

Rather, I've been wanting to see if I can figure out the differences in the way a 1.0 iff is structured versus a 2.0/2.5 iff. Learning the structure of resources (and their headers) in a final game iff from some of the established documentation on the subject was rather useful for trying to uncover what was up with the hex conversions when they were being weird, and now I kind of want to see if I can suss out a deeper understanding of how a 1.0 iff is built different, especially since for the most part all the different kinds of resources a beta object is likely to have include actual *data* that is final game compatible, it's just the surrounding iff that isn't.

(Also some part of me wants to figure out if it's possible to get clean in-game screenshots that replicate what the sprite of the aquarium looks like a bit better but that's a job for tomorrow me. Or next week me. XD Hopefully not next month me. XP (I have been saying to myself that I wanted to get a comparison image using the bed and show the original SPR2+beta DGRP attempt in T-mog, the beta SPR#+beta DGRP in T-mog, and the beta SPR#+beta DGRP in game, just to show how different they all look despite ostensibly being the same sprites. I wanted to do it a week or two ago and then I just. didn't lol )

If it helps, you can hit A or S when grabbing an object in Buy Object Mode to switch its gfx state, one DGRP at a time (works both on the proto and the Edith development base build)

EDIT: This whole time I overlooked the fact that the stub beta graphics in controller objects are compressed as "SPR#" described here as "8 bit RLE Sprites with no alpha (channels)"... is that really the case for the controller object gfx?

I think the overhead blue dot (plumb-bob's "grandpa") is an "SPR#" too -- it can be found in every build's "Sprites.iff".

This pre-release SimTool generates 2.0 IFFs of walls, floors and painting objects. However, at the time of the tool's compilation, "SPR2" already was the dominant sprite compression form (I believe final walls/floors are all compressed SPR#?). Otherwise. My rule of thumb does not help me figuring out what makes a 2.0 different from a 2.5





As for me, it's my generally low stamina time of the year, when I have some more days to work on Sims stuffs, but then, in planning to work on Sims stuffs for so long (and at a time all I could do was plan), it's more or less as though I've been given the feeling of accomplishment in advance, so I'll basically be inclined to take a nap right when I am about to run the SimTool exe's but I'm cleaning up my own rust at last. Something you mentioned earlier and I'm enjoying to find out is detecting (unexpected) matches between certain proto/final object GUIDs, which took me, for example, to the realization that "houseplant.iff" (the most weird looking proto obj IMO) later "became" the Rubber Tree Plant (the most beautifully rendered base game obj IMO) :p

Ooh that graphic state cycling advice is very helpful, thanks! *jots down* Also, I managed to fix one issue the bed had today so hooray!

[X] Figure out why sleeping puts Sims in a forever coma and make it stop (it's because it was checking for a state the object could never naturally enter, even by canceling the interaction, because of a change I made to try to adjust alertness numbers to sleep state ones--copying the base game bed's BHAV was enough to fix it)
[_] Animation weirdness (AKA the animations aren't for THAT bed so they look wrong)
[_] Slot weirdness (AKA the slots as originally utilized in the beta object don't work but changing them to something that worked caused them to break in a different way)
[_] Make sure I maintain beta-like behavior after all the changes are said and done

I don't know if there are significant differences between a 2.0/2.5 iff myself (this suggests they're MOSTLY identical)--I feel as if I may have JUST enough knowledge of them, though, to figure out what's different about a 1.0 iff at least partially. Such knowledge could be useful if anyone ever wanted to try to port a final game object into the beta... (Then again, such a feat might be easier said than done as far as some resources are concerned...)

Hey hey I had almost forgotten that the template ghost house where the NPCs live is a 2.0. That FatBag person was like a tornado that changed everything we knew about how the things in the game function until summarily drifting away (countdown to the moment somebody comes here and says "nah, he's on Discord, here's their @.")

And when you look at the proto bed's intended behavior... it does not have that even they will have the Sims sleeping in a very weird pattern; you can see that the game waits until circa the beginning of the evenings until the Sims' energy bar begins to get filled up (does that mean they reached the rapid eye movement state?). I think the sleeping interaction started to see tweaks that (at least to a certain degree) match the finalized Sim sleep patterns from Jan '99 on (see page 66 of this document. It's also the only technical e-mail segment where a wild Will appears!)

---


And, hmmmm, in keeping with our tradition of doing something cool every time +50.000 (definitely not exclusively unique) visitors view this thread (previous goody was the plumb-bobesque plumb-bob, remember?), object list now accommodates the entire data mining efforts off this project (obviously biasing towards the object's DGRP representations, and some unsubstantial comments about one object or two's noteworthy behavior or vestiges on later builds, at least for now), sufficiently neat for me to spread the good news everywhere! Some crazy folks might want to read it. Now there's nothing left for me to do but fixin' and tweakin' my existing mods. Crap!