I asked this before on MTS and never got a satisfactory explanation other than Pescado claiming that I do not know how to look at the internals of my PC and figure out what runs on startup, which I can assure you I do.

So, the question is; What, exactly, is this supposed to "install to run on startup"?  Becuase I've looked, and I can't find a single thing.  Absolutely no evidence of anything TSR related running on startup or otherwise unless I load the TSR workshop, which obviously then gets the ads and latest uploads so on.  msconfig shows nothing, and neither does the much more in depth autoruns.

Motoki: Err, Peggy has absolutely nothing to do with "getting closer to getting more hair out there".  We *have* tools to do that, we *have* proper custom content hair working in game here, with zero help from Peggy.  So I'm a little confused as to what you are saying.   The only delay is in getting things *right*, making sure the layering works, texturing, etc.  But that's being worked on right now... so... soon.

Zaphod, that dark screenshots issue happens only in full screen mode.  Windowed mode doesn't suffer from the same issue.

jriggs: Yes, she used Q-Mesh, ie Wes' tool. 

Well, the thing is... the way she's done it can easily be done with a hex editor and by reading some threads on MTS - especially the ones fairly recently regarding new non-replacement meshes.  It's done *so* badly (and the fact that only the main VPXY is modified) that I suspect this is the way she did it.

Considering that all she's done is replace a bunch of 00 to 01, it's really not that hard.  I most certainly didn't help her with any of this, and I suspect Pescado knows next to nothing about hair files.

...Except that Peggy wasn't the first one to figure it out.  I posted up a flowchart I did a week a week and a half ago, and there is a thread on MTS with screenshots of new non-replacement custom hair from days ago.

As I posted on MTS, she's done it *extremely* amatuerishly, too.  Just the basics, to get it to show in game but she's left a whole heap of linkages back to the store hair still.

There's a big long list, as well as icons, located here: http://www.sims2wiki.info/wiki.php?title=Sims_3:Traits

It would be nice to add your other notes though.

That's the weird thing - I *also* use ReadString to read those strings, and it's worked in absolutely every case I've thrown at it, until now.  I think it might have something to do with the wrapper I'm using though, so I'll have to investigate further.

Thanks for the feedback.

I posted this over in the compressoriser thread but figured I'd duplicate it here.

Essentially, my DBPF code for the DDO has issues with SHPE refs in files that are re-compressed using this program.  It reads normal SHPE refs and other compressed ones fine, that I can see.

On *normal* Maxis/SimPE compressed SHPE chunks, the DDO works fine.  It is only on the SHPE chunks that are run through the Compressoriser that it borks.  The reason is that there is an extra byte inserted after the length of the sgResource string but before the actual string.

For example:

Normal compressed SHPE ref, in Hex view in SimPE: 66 42 72 61 6e 64 69... etc.  This is 1 byte for the string length (0x66 - 102 bytes) and then immediately followed by the actual string (Brandi...).
For a compressorised SHPE ref, in Hex view in SimPE: 95 01 62 72 61 6e 64 69... etc.  This is 1 byte for the string length (0x95 - 149 bytes) and then a 01 and then followed by the actual string (brandi...)

A string in the SHPE ref chunk *should* be encoded with 1 byte for the length and then the actual string.  I'm guessing Simpe either ignores this extra byte, or does something else with it - I can't find anything in the SimPE code specifically mentioning it. 

I can put a catch in the DBPFClass code to check if the first byte of compressed string is 01 and ignore it, but I'd like to know why it's there in the first place.  Perhaps my understanding of the actual string storage is not complete, but the code for the DDO works with basically every other file you can throw at it *except* the compressorised ones.

Can you shed any light as to why this extra 0x01 value is getting in there?

Regards
Delphy

It affects only SHPE chunks that are in files compressed with the compressoriser, but as for why, I don't know.  I'm currently trying to track down the issue, so expect a DDO update in the next few days.

Edit: Okay I figured it out.  On *normal* Maxis/SimPE compressed SHPE chunks, the DDO works fine.  It is only on the SHPE chunks that are run through the Compressoriser that it borks.  The reason is that there is an extra byte inserted after the length of the sgResource string but before the actual string.

For example:

Normal compressed SHPE ref, in Hex view in SimPE: 66 42 72 61 6e 64 69... etc.  This is 1 byte for the string length (102 bytes) and then immediately followed by the actual string (Brandi...).
For a compressorised SHPE ref, in Hex view in SimPE: 95 01 62 72 61 6e 64 69... etc.  This is 1 byte for the string length (149 bytes) and then a 01 and then followed by the actual string (brandi...)

A string in the SHPE ref chunk *should* be encoded with 1 byte for the length and then the actual string.  I'm guessing Simpe either ignores this extra byte, or does something else with it - I can't find anything in the SimPE code specifically mentioning it. 

I can put a catch in the DBPFClass code to check if the first byte of compressed string is 01 and ignore it, but I'd like to know why it's there in the first place.  Perhaps my understanding of the actual string storage is not complete, but the code for the DDO works with basically every other file you can throw at it *except* the compressorised ones.

Actually, if the program is done right, the index entries wont matter - what counts is the offset to the file, not the TGI information.  A resource can have exactly the same Group and Instance but be a discrete chunk within the .package file and work perfectly fine.  Another point to be aware of is to not rely on the DIR index for the compression flag - I use a combination of this and checking the first four bytes of the chunk to make sure it's compressed.

The DBPFClass.dll I made with my Download Organiser (in C#) handles that file with no errors whatsoever, and even detects the type correctly.

What I would do is write either only the first or the last file with the same TGI (although don't forget to check high-instances too) just so you actually have part of the data.

No offense to Quaxi and all the people that work on SimPE, but back when it was DatGen vs SimPE, DatGen wanted to be this huge be-all-and-end-all monster Sims modding program, and SimPE (then) was the small lightweight version.  I supported SimPE back then becuase it seemed the right thing to do.

However, I agree that smaller, simpler, faster tools are better than one big huge one.  It would enable functionality to be folded in much quicker, EP updates to go in easier, and so on.

Thats not to say SimPE itself should be destroyed - just that we should provide other alternatives for people.

I've been doing quite a bit of package/DBPF programming using PHP lately for MTS2... and my background has always been tool writing, so this kind of thing to make small tools interests me immensely.

Also, thanks to Pescado for giving me access here.