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.