Funnily enough, the global for sighing contentedly in 1998 is the global for creating a flood next to the object in final. The tub called that line during the "luxuriate" BHAV and for a bit I was like "why has the tub sprung a leak!?" (but that would be why one thing I said I did for the tub was "changing a call to a global whose purpose was completely changed to point to a sound instead")

Yeesssss -- The disorienting thing about us muddling through it is that having the flood in the situations we saw them happening was contextually plausible (or half plausible) enough for us to just accept it on auto pilot and don't question it as a script oddity!? My TV watching dummy Sim was watching a given channel calling the crying 'n' sobbing cmx (wish they kept this behavior for the final TVs btw... wait, do I?), and the prototypes are known for their relative over-the-topness. A recurring thought of mine was that the flood summoning was meant to exaggeratedly represent Sim tears as a superweird beta behavior that thankfully was not carried over - the object was being called directly between the TV and the character, hence the illusion.

Pointlessly named Aquamarine Mega Pack is here:

Platform	Comments	Download
	Manual Install file. Can be used for all Sims versions. Just extract its contents to "Downloads" and you're ready to go! Recommended to players who are used to downloading CC and/or have manually modified the game's default install path.	lpx_betaobjs_megapack_b.zip
	1-Click Mod Install for The Sims Legacy on Steam. It automatically installs all objects for you! Recommended if you're new to downloading CC or haven't manually modified the game's installation path.	lpx_betaobjs_megapack_steam_b.zip
	1-Click Mod Install for The Sims Legacy on EA app. It automatically installs all objects for you! Recommended if you're new to downloading CC or haven't manually modified the game's default installation path.	lpx_betaobjs_megapack_eaapp_b
	1-Click Mod Install for classic The Sims (2000-2005). It automatically installs all objects for you! Recommended if you're new to downloading CC or haven't manually modified the game's default installation path..	lpx_betaobjs_megapack_original_b

Eeeeeeeverything is here (including all-time essentials 'floorlamp1' and 'duck'.). Except what isn't (things that are not buy mode items). Sorry.

The motivation force behind the creation of this mega pack: downloaders seem to care about it more than the individual downloads at this point. Good for them! Just imagine how nuts it would be to miss out on...:

Sample	Source	Comments	Author	File
	bed3.iff	This download's thumbnail is an in-game snapshot because all the third-party object viewers I own fail to display it correctly. Yeah, you've guessed it: it's a testament of the fact it's an accurate port that uses the partially deprecated SPR# gfx resources just like the betas do!	purplewowies	pw_bed3_steering_HE-v0-5-0.iff
	floorlamp1.iff	Quoting pw herself: This IS a beta recreation, and wow is it interesting! Well... the object itself isn't that interesting. It's just the floor lamp, the one that totally looks like a base game floor lamp. What's INTERESTING is how I made it! The base I used to start before doing things like modifying the GUID (so it doesn't conflict with stuff) and getting things updated so they properly work in the final game? ...It was ENTIRELY manually converted by hand in hexadecimal. What does that mean? It's not like the previous routes I've taken of exporting the data of given resources and importing them one by one in Iff Pencil. What I did this time, after studying a few 1.0 iffs, was take the 1.0 iff and open it side by side with an empty iff generated by IffPencil... and then manually copy each entire resource over one by one, paying attention to what its label in the NAME resource was, and make each resource have a version 2 compliant header (this mainly consisted of changing the label reference in the 1.0 chunk header to a label as a 2.0/2.5 chunk expects it. This whole project really helped me put to work my learnings and investigations about 1.0 iff structure.	purplewowies	pw_floorlamp1_steering_hexport.iff
	tub1.iff	Quoting pw once more!!!: [...] It's the bathtub! This tub has the honor of being the first object to have its initial conversion base done via IFF You Really See Eurydice! Still needed a fair bit of editing. For instance, like the cheap bed, it needed to use a final game SLOT in order to work (and needed the OBJD and TTAB updated in various ways). It also had the customary sound and animation changes (the sounds are base game sounds for the same reason the lamp's were) and slight changes to behavior to yield more desired behaviors (for instance, being able to get out of the tub when you are clean instead of being trapped in it forever, or draining the tub if the interaction is canceled in the queue instead of leaving it full, or changing a call to a global whose purpose was completely changed to point to a sound instead). [...]	purplewowies	pw_tub1_steering.iff

I feel like this project is nearly coming to an end. Me big sad.

...I suspect that feeling may be part of why I have turned my attention to some unfinished non-beta objects as of late... 🤔 If I turn my focus elsewhere I can pretend it'll never end!

possible minor bug: I noticed that IFF You Really See Eurydice 1.0.1 freezes up when asked to convert (1998 demo's) chair2.iff. The problem does not seem to occur in version 1.0.0, but the resulting converted data misses most of the resource labels

...Ooh. I'll try to take a look at that tomorrow! (I can potentially take a look at it tonight and just not do anything to FIX it tonight, but I'm not sure...) (EDIT: I'm downloading IntelliJ IDEA to my laptop literally right now purely to see what happens in what it's printing to the console when it runs because checking the file in a hex editor wasn't clear enough to me...)

*makes note that this might turn the NAME "feature enhancement" meant to lessen possibility of errors into an actual fix attempt...*

EDIT: I don't actually know quite why my band-aid is causing this hang here but not causing it with literally EVERY chunk and file (this is happening on a random BHAV with a known valid entry in the NAME chunk, but I'm expediting fixing it by planning to try to implement the more robust way to handle the NAME resources. (I want to try to move to making a table of all labels and their identifiers but this will require me to more heavily adjust how the program functions "under the hood" so it might take longer than a quick fix might.)

EDIT 2: Of course! If the only instance of the label's ID isn't ACTUALLY the label's ID and happens to trigger the "it's not an even length so it's wrong" loop, it gets stuck in that loop because the loop's length is always odd. I've put in a check that will force it out of the loop if it loops several times, but I won't be able to make an exe until next time I'm on Windows. (The "make a table" solution would also fix this if I code it right, but what I pushed to Github tonight was a faster way to avoid the bug.)

...That won't solve the label not found issue for this file because it is the mythical iff file that thwarts my shortcut, where there are three NAME chunks in the data and a lot of used labels are in the second one--it's not finding them because it's coded to check the last one, which is the third one. (The "make a table" solution WILL fix this the way I'm imagining it working, but the quick fix will not.)

IFF You Really See Eurydice 1.0.2 has been released, now with 100% less infinite looping! https://github.com/citrusella/iffyo...ases/tag/v1.0.2

(The better fix will come later. When "later" is, I'm not sure. I feel like I want to do a LOT of refactoring with it, so it might be pretty far off yet...)

So... the missing labels of chair2.iff was a native oddity all along? And not a post-Eurydice error? 🫣 well at least it worked as an accidental troubleshooting aid!

Like the trees/stereo/etc, it is one of those rare moments of questioning myself the need for granting chair2 a beta demake for the sake of it, anyway, as it is one of those cases where a fan-made quality gambiarra follows up, with a generous dose of assumption, what the protos left off — the final has more chair2 animations than the proto does, the beta behavior might come across as a little janky [...]...



There's a thing also where the character turns themselves around when they 100% shouldn't and messes up with everything*. I predict the same will happen with the toilet, but the weird animation that comes with it (and can be located hidden in the final build weirdly enough) will make it worth it!!!

* just like Orpheus. *laugh track*

---

On parallel Sims projects --- join the club there is this diagonal object bases thing I zealously pursued earlier last year, and was dreading the moment I'd need to cast it aside due to the scenario of not making enough connections that would give it proper extra-forum fruition. Moral of the story: connections were made, but I kind of sabotaged myself anyway 🫣 but, hey, as a voluntary hobby, there is no such thing as running out of time...

I didn't check Edith to check how it interprets them in the resource viewer today (half forgot, half didn't have time) but for most objects the NAME either looks like this:

NAME: entry entry entry

or this:

NAME: empty
NAME: entry entry entry

(they aren't always next to each other. usually the empty one is at the start of the file and the one with the labels is at or near the end)

The shortcut I took to quickly get label finding off the ground is to just find the last instance of NAME in the file, which corresponds to the last NAME chunk, and get the labels by looking at the data after the start of the NAME chunk. This is fine and works when the file has one of the things I listed above, and the several several files I checked when putting together the tool work that way so I made a guess few or no files would have this problem.

However, the NAME chunks in chair2 look kind of like this:

NAME: empty
NAME: entry entry entry
NAME: entry entry entry

Because my tool checks only the last NAME (because it was far less complex to get set up) that means it's missing the entries in the second one. This is a bug in my tool that I anticipated happening but wanted to wait to fix because fixing it would be more difficult. There is a high chance that Edith checks and finds/uses labels in them all, so my tool should probably do that instead. That's why what I want to do is make a list of all NAME in a file and make it so those three for instance become one list that's just [entry, entry, entry, entry, entry, entry] because then it won't miss entries that might be in a list it didn't check because there will only be one list. (EDIT: Now that I'm at the right computer to check: Edith DOES find and use labels that are from the second chunk. You can tell because BHAVs other than init (4105) have labels in Edith lol)

Sometimes missing labels *are* also a thing in Edith (as far as I can tell, for instance, floorlamp1 has its attribute labels incorrectly IDed, so neither Edith nor my tool can find the label correctly, though it does exist), but this one is probably the converter's error.

EDIT 2: Actually I'm noticing the converter *says* chair2 only has 2 NAME. Will have to figure out why that is. But the file itself does have 3 NAME.

Got it -- in the meantime I'll measure the chances of final-izing floors.iff (1998) +++ concomitantly feed the nearly done list of objects in Object List (eventually I will need to make it a main "Proto:" page that wraps up the CATS and sprite data of the 2 known prototypes at once. Piece of cake, in practice).

For what it's worth, I tried getting the 1998 floors into a 2.0 iff when working on the converter (before I released it). It didn't go well--trying the unmodified SPR# for a particular tile inside a flr just made the game go "I think this floor is corrupt, do you wanna trash it?", and trying to transplant just one zoom onto a single-tile test object (so I could export it and re-import it in T-mog in the hopes of turning it into SPR2) just crashed T-mog. ...Then I thought about trying to manually adjust the SPR# hex into SPR2 hex myself and went "...nope". (Trying to directly pull the houses out also went similarly badly, though I think the chances of making houses work is far lower... or at least very likely not worth the effort versus just manually recreating the house.)

I definitely do think conversion should be possible, though (whether through one of these methods except making it work, or some other way)... or at least I hope it is lol

(And to de-stress after it didn't work, I put the unused floor tiles into a floor creator program (IIRC I couldn't find my copy of the Maxis program and used the online maker instead)... but that's because those are all one solid color, so it was very very easy to just make an image to put into a flr with a fun description. )

Little update on chair2 and IFF You Really See Eurydice: ...I don't actually know how to fix it! ...Because the converter SHOULDN'T be having a problem, actually, if Edith is not ALSO having the same problem, unless something about the entirety of my NAME decoding is off-base. Huh???? Let me explain.

chair2 only has 2 NAME that either the converter OR Edith should be able to see, because the last NAME I thought was in the file is actually inside of an XXXX that takes up the entire last part of the file. All of the labels in the NAME that are not being found SHOULD be in that second NAME. At least one of them is appropriately IDed in a way that the converter SHOULD be catching it. I've GOT to do more investigation.

I'd like to think the changes I'm trying to do with the NAME finding and conversion should still help, but it's currently a mystery to me as to why it's not CURRENTLY working...

EDIT: After investigation, it's recording ALL label lengths for the bad chunks as 0 length. There is no reason it should be doing this (literally. the NAME chunk does not have anything in it that should be making this happen so far as I can tell), but I DO think that implementing the newer system will fix it. (Largely because the newer system will step through each label, find the next byte if it needs to in order to get length, and then record the label in a mapped list like ID:label as opposed to the current system of getting the ID, flipping it, and then looking directly through the last NAME chunk.)

IFF You Really See Eurydice 2.0 is out! A big change to NAME handling warrants a big change to major version number! This version of the converter changes from the shortcut method of finding labels to building a label list from every NAME chunk in the file before it ever starts looking for the labels in question. This is a bit more of a robust way to list and retrieve the labels, and I can personally vouch that it fixes the issue with chair2 specifically! It's possible there are some edge cases that might still break (particularly with files from the 1999 build that use a different format for the chunk, where I had to do something that felt like it was still a little bit of a funny way to write it in order to prevent errors), but overall it seems to work pretty well with any file I throw at it. No gibberish, no chance of infinite loop it seems. Just an accurately converted iff!

Feel free to give it a try! https://github.com/citrusella/iffyo...ag/v2.0.0%2Bdeb (EDIT: Changed url since I had to give it a new tag due to making a few minor changes to allow for a Linux build today.)

(The mythical 3.0 will only come if I ever eventually take it upon myself to make all the hexadecimal strings into byte arrays...)