I did twice the experiment in the base game to confirm the followings:

1. additional jpg files with altered instance values will still be deleted along with old ones when a lot is saved. So, additional jpg file is not a good choice.

2. additional txtr files with altered instance values remained after the lot was saved. So, additional txtr files can work.
FYI:
http://www.sims2wiki.info/wiki.php?title=RCOL_TXTR
Attached is the txtr template I used in the testings.

Marking a lot by adding a jpg or txtr value will be easy to change, if anyone wants to do so.

Mootilda,

Lol, BTW, which string value you have in mind to alter for "adding a new string value"?
Where will such string value be added?

I think adding a new string value can be pretty easy, but still it may need some small testings to see if it lasts after lot-saving, right?


Lol, the "template" I meant is just an exported txtr file I used for the testing. The graphic may need revision for more relevant symbolisation or representation.

Just suddenly thinking of moving the lot out of the neighbourhood and test it in an another one to see if such maker remains through binning, exportation and re-importation or even maybe a cycle of 3 repetitions.
I feel I first test was just too brief, but hopefully suited for the pilot state.

I'm also thinking of a text list addition due to its simple structure.
But like the others, it may take some simple tests to confirm they remain after lot-saving, exportation, relocation, binning, reimportation, and 3X transfers.


So, now:
we've got addition test subjects like:

1. string value
--[location unsure yet, so no test yet]

2. txtr file (in a lot package file)
--[well remained in the lot package file after lot-saving, binning, relocation to both original and new neighbourhoods, exportation, re-importation, and 3X transfers]
--[viewable as a preview image @ a lot package file in Karol Rybak/phervers' sims2pack Clean Installer (S2PCI) ]

3. text list file (in a lot package file)
--[file structure simpler than the txtr and lifo files]
--[not tested yet]

4. lifo file (in a lot package file)
--[file structure simpler than the txtr files]
--[well remained in the lot package file after lot-saving, binning, relocation to both original and new neighbourhoods, exportation, re-importation, and 3X transfers]

Any more suggestions and probably with more details for where they're added?

That attached is the lot I used for the testing after the 3X-transfer.

Sounds like a lot more work than is really necessary. We only really need one way to mark a lot. If txtr works, then that's fine.

The only reason that I was thinking about a string value is just that it would be small...

Niol, I tried the lot you posted above - it works in my game, but I don't see how it is marked as shrunk. What should I be finding?

Just elaborate more for such description:
[viewable as a preview image @ a lot package file in Karol Rybak/phervers' sims2pack Clean Installer (S2PCI) ]


The procedure to check for the marker:

1. Open a ".Sims2Pack" file with Karol Rybak/phervers' sims2pack Clean Installer (S2PCI)
2. Select "lotSegmentForUpload"
3. at the external pop-up "Preview images", click "next" to check out what images are in the lot package file.
4. Click till the end to see if there's a image with a red "Mark" in black background. If so, the lot has been used with whatever feature.

The chosen image size is 64x64 px^2 with only 2 colours in it, but maybe with non-anti-alias and 8 bit colour base (or maybe even just white and black), the file size should be closer to the smallest it can be. May also utilise the in-game compression, but it only makes a "significant" difference (>= 100 kb) when the image size is large.

The advantages of txtr and jpg files over the others is that they can easily show up with lot preview by Karol Rybak/phervers' sims2pack Clean Installer (S2PCI).
Since the the jpg file doesn't appear to work out after lot-saving, txtr files seem to be the only choice for this extra advantage.

A fundamental beneficial assumption for txtr files is that most users know how to use Karol Rybak/phervers' sims2pack Clean Installer (S2PCI).
Also, it still takes SimPE to remove the marker.

I'm still making my tutorial on 3D array instance 1 modding. I realised it took more to explain as smoothly as I can. Hopefully, at least moderate level of SimPE users will be comfortable with it.

Oh, I see. However, many users probably won't see that mark, even if they do open the package with CleanInstaller. (I did, but it didn't occur to me to look through all the images.) Niol's marker turned out to be the sixth image.

To be effective, we need something that shows immediately - on the lot, or straightaway when opening CleanInstaller - something like that. If people have to go hunting specially for the marker, they probably won't bother.

Sorry to be a wet blanket, but there's no point marking lots if no one will notice it.

I'm all wet blanketed out. I think this is another lot of extra work no one needs to do. Sims 3 is out in a little over a year and at this rate no one will get the chance to really appreciate and enjoy all the work that has already gone into this utility.

aelflaed,

It has to take a user to click on the lotSegment file in order to get the pop-up preview out and then click on the "next" button to check with this method.

The thing is that the Clean Installer normally preview the jpg files first and then the txtr files probably due to the alphabetic order. The most I can think of presently is to name the additional txtr file with a character the Clean Installer is likely to pick earlier.

I know the jpg replacement sounded so appealing for most causes stated.
Yet, since all jpg files will get erased everytime the lot is saved, I don't see the marker can be any more frontier than the first txtr file to be shown in that rationale we want the marker to stick to the lot in a long term until it's manually removed or technically removed.

BTW, the order of where the marker will show up depends on how many jpg and txtr files are in front of it in the queue..
Lots of higher layers/levels/stories will have more jpg files than those of lower ones.

Hence, I said "A fundamental beneficial assumption for txtr files is that most users know how to use Karol Rybak/phervers' sims2pack Clean Installer (S2PCI)."
Apparently, many users probably don't even know or realise that feature of the Cleaninstaller because they needn't check out files (like recolours, clothes, body skins or objects) with those mentioned graphical file types or maybe else (such as jpg and txtr files)...

To teach people about this little feature may be a good idea though.


To archive what you want, we'll need any of the followings:
1. to find out another file type that can show up even earlier than the jpg files.
2. to mod the Cleaninstaller to force it show the predefined marker as the first detected graphic or text list or else.
3. to use an another means to mark a lot.
4. to make a temporarily hide-able object and stick it to the lot, but users have to graphically silence it everytime is loaded.
5. further input(s) by you and/or other concerned...


Inge,

Oh well, I still mostly care if the fixed final version will be released.

Thanks for the explanation, Niol. I'm interested in releasing as perfect a version as possible, and I also acknowledge Inge's desire to have -something- used and appreciated, sooner rather than later.

I don't mean to say we can't use the txtr marker, just that it isn't very obvious. If the perfect option isn't there, or is too hard, well, so be it. I can't help with the programming, so I'm offering what assistance I can.

Niol's other suggested methods don't sound any more hopeful so far. Of course it's Mootilda's call - she has to do the work, and it's her name on it in the end.

Mootilda, what would you rather have - such a marker as Niol has already made, not very obvious but definitely there if someone looks? Or no marker, relying on the builder's responsibility to mention the possible risk? Or something else entirely.

At this point, I'm still trying to decide what to do with the shrinking code. Only two people have downloaded the most recent version and I've only seen feedback from aelflaed.

Did you make the test publicly available? If not, the danger is that the handful of "specialists" you have on the testing team are busy on other stuff. For example, I am currently up to my neck in sorting out TRCN formats ready for the next SimPE release and haven't had the opportunity to fire up the game in about two weeks. That's likely to be the case now until we get the next SimPE out.

She posted the headsup here, and the file is on the private forum.

Mootilda, do you want me to do any more specific testing on that version, or do you need other people's testing now?

The testing that you've been doing has been very good and has certainly been pointing out the remaining problems. There is still one area which hasn't really been tested: shrinking where the area to be removed is empty. I've done some testing on this, but it couldn't hurt to do a bit more.

Okay, I can do some of that over the weekend probably. Of course, others could do it too - feel free!

All lots I shrank were done so while empty. No lot had a problem reported that was revealed to be the fault of the lot. The lots have been DLed over a hundred and fifty times.

MB, great that your lots were so successful! But they must have been created with a previous test version, so Mootilda needs some new ones done with the current LE.

You're welcome to test that and post your results. I'm not wanting to hog the feedback at all, it just seems everyone else is too busy right now.

Except Mootilda won't be able to read them, as she's got her on ignore...

yes... So I won't bother.

Lol, I believe as long as tests are made reasonably enough, they may get noticed and considered sooner or later due to the present filtering. As one gets busy in life, one needs to optimise the time one can have, and so reputation becomes a criterion for one to consider if to read a source based on that..
One may use the point form to list out the brief procedure and/or conclusion for fast and hopefully clearer readings

Since maybe different people have different time budgets and concerned field(s), I guess a team may have a higher probability to sort out useful resources.

Gonna have to install a CD-ROM back to my PC for testings...

If anyone posts useful testing feedback, on any thread or site, and we think Mootilda isn't seeing it, we can always pass it on.

Anyway, that's my sixpenn'orth. I'll go do my own thing now too.

Slightly off-topic - someone asked whether I could make the Sunnyside lots in a desert terrain version. I expect it's beyond my capabilities, but I don't know if it is worse than that. Is it possible?

For later EPs the lot seems to pick up the hood terrain as a base, but it doesn't for basegame, so a desert set would be nice. If someone made a 1x1, I could do the rest with the LE.

I seem to remember niol doing some research on this... I think that there's a simple field which can be changed... niol?

Update: Guess I was wrong. Used the thread search tools but couldn't find the information that I was thinking about.

This is a bad time for me to try to do any research on this, because I just got Free Time and will be spending my time updating the LotExpander.

However, remind me after the LotExpander for Free Time is released and I'll see whether I can figure something out.

Sorry, I thought I read the last 2 posts while not .






The post was 295
http://www.modthesims2.com/showpost...3&postcount=295

The relevant quote:


the file be "lot-terrain-texture-template.rar"


Just major 2 things to do:

1. import the desired terrain type template into the lot,
2. in the newly imported file update the lot width and height from the old one and commit
3. delete the old one
4.. save the lot package file

please ask for further questions if any.

So Niol, do you mean that switching that template on an existing minilot will make a save-able/shareable desert lot?

I find it very hard to understand this kind of thing, but I'll go and have a try. Thanks.