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...)

I've made a port of the expensive bed! I probably could have even left it with its original OBJD since it doesn't appear to have conflicts, but instead I cloned it and grabbed that OBJD instead just so that it has some magic cookied GUIDs for the tiles. Typical concessions to make it work have been done--adjusting animations, editing the TTAB to properly advertise, using base game bed SLOT resources, etc.--but it's otherwise in all its Eurydice converted glory! http://www.simfileshare.net/download/6066360/

...It IS named v0.5.0 like bed3 was... but partially because the animation, while still not quite right... frustrates me. The animation is so clearly in the right SPOT but is just a little too high! I tried seeing if there was some magic I could do with the SLOT that would lower it. I tried figuring out if the animations were editable in SimPose somehow so I could lower them. ...It's painful that the animations are so close to working but yet so far away lol

A couple of Iff You Really See Eurydice notes, because one of them looks semi-serious and I need to figure out why it happened, and neither have been compiled into a new release yet. Both of these came about because I wanted to play around with MealSnack and see if I could mess with it the way some hacked fridges reference custom food, just to see if there was another way to do it besides the existing default replacement LUCPIX made. To experiment, I converted MealSnack and NewFridge (the cheap fridge) in the converter and cloned them in T-mog (so that the meal in particular would have a unique GUID).

1. MealSnack's NAME resource causes an out of bounds exception when trying to verify whether or not it's a 1998 NAME or a 1999 NAME. A fix for this was made (that just assumes it's a 1998 resource if it throws an error, quickest way to fix that) but I haven't compiled a new version. Yesterday that was just because this was kind of a low priority error for now (only so far discovered in something that already has some form of a port, something I wasn't even going to bring up here until I might have done a new release). But now it's because I also ran into...
2. NewFridge's spf successfully converted all resources so far as I can tell, and IffPencil put them all in the file correctly when importing the spf to the (rest of the) iff. T-mog didn't see any part of the fridge more than two fifths open when I cloned it and MealSnack and as a result didn't include those resources in the clone. I need to check if this is the converter's fault (it should not be capable of incorrectly formatting the actual data of a chunk, because its logic for everything other than label conversion is predictable and consistent) or a quirk of the resources themselves. If it's the converter's fault, I'll try to get it fixed. If it's the resources somehow... uh... it's something to watch out for. (Importing the resources back into the cloned file results in the game ALSO not utilizing them correctly or seeing them, so... *confused shrugging* (MealSnack's sprites are also having issues... 🤔)

Hey, is this viewer available anywhere? I'm still trying to figure out the sprite issues I mentioned in the previous post (and in the 1999 thread) and I think having more data points for which programs are deeming the problem sprites okay and which are freaking out may help me figure out WHY the issues I'm seeing are happening and if I can update the converter to fix them or not.

Is there actually any documentation on how the neighbourhood overviews were designed?

If I may ask, which of these readings of your question is closest to what you mean?

- Are there any documents that describe why the neighborhood looks the way it does/why they changed its look between the prototypes and final?
- Do we know what they used to actually design the screen? And whether/how that was different between the protos and now?
- How do the prototypes and/or the final game provide the screen they come with? (I know this is known because custom neighborhood screens are a thing and I even know how to do one myself.)
- How are the clickable areas that load into lots provided? (This is known for the final but I'm pretty sure it's NOT known for the protos?)

EDIT: Incidentally, this message made me go do this again:



...If I were actually going to sit down and make a UI/neighborhood replacement pack, I would try harder, but replacing NScreen.BMP and giggling at the results is far easier...

Yes, and funnily enough, I am 90% sure its main purpose ("selling point") is definitely NOT being a sprite viewer -- it just happens to be effective for this specific purpose.

I'll return with the name of the program + download link after work since I can not remember right now. It's been foreverrrrrr

Errr there you go

Possibly the only standalone simtool that does not struggle at previewing all the graphics in Sprites.iff, by the way (oh wait there's Simplorer 1.1.1)

Thanks!

...This gave me absolutely no further insights on what the problem is with the converted files I've been having issues with (it has the same ability as IffPencil to view the one with the SPR2 (grill) and about the ability to view SPR# (fridge) that I expected, which is to say it shows all extant sprites).

At least it transported me to the fridge dimension?



(I do think this is a useful program to have, though I had to edit the shortcut to actually point to the program, and it only finds files if I drag them onto it, not if I browse for them... 🤔)

EDIT: Apparently for the grill it was a problem of the number of graphics identified in the OBJD rather than a sprite issue (looks like that was the fridge's issue, too, but I haven't actually tested that)... I MIGHT be able to control for that with the converter but it might not be easy to identify that a given drawgroup is intended for one tile or another... (I mean, it SHOULD be easy to identify that under normal circumstances, but still.) It might also be possible that I decide it's out of scope since it requires me editing the actual chunk data for the OBJD and my converter very deliberately does not touch resource data, just headers so that the overall chunk is structured right...

All the questions sound interesting.
But it would be really nice to get an insight into how the neighbourhood view works. The way the graphics are swapped is something I remember from back then. However, even these are dependent on how Maxis arranged the lots on screen.

Anytime! And you bet - it's your ad hoc views-it-all exe when absolutely nothing else works. Helped me tons as I sorted graphics out for further documentation

These bad psychedelic trip sprites are z sprites. The SPR# resources seem to have this idiosyncrasy where Z channels have indexes of their own (or at least are interpreted by the sprite viewer as such) separated from their respective color sprites. OTOH, when viewing SPR2 graphics, marking the Show Z-buffer checkbox is what it takes for their z graphics to show up

Possibly a simplistic answer for your open-ended inquiry, still a piece of the jigsaw...

(source)