Here's my current to-do list. Feel free to comment on these ideas, or make suggestions of your own.

Current To-Do List for ConvertiWall:

My first priority is to fix problems which prevent people from using ConvertiWall. Bugs which have a workaround will be fixed as time permits.

New Functionality:

- Lot Catalog selection should be handled by a button, rather than a checkbox. This should be more intuitive.

- When changing a normal wall with the default wall covering to a brick foundation wall, change to the default brick wall covering at the same time.
Difficulty: easy (I think)
Workaround: The actual default wall covering has actually changed, so you should just be able to fill the wall with any wall covering, and then remove the wall covering again. You may need to save the lot between adding and removing the unnecessary wall covering.

- Provide an option to see the lot names for all lots within the LotCatalog.
Difficulty: easy.
Note: It will take a while for the program to fill the listbox, since it requires opening and parsing all of the files, but should make it easier to find the lot that you want.

- Provide descriptions for all known custom walls from the wall repository.
Difficulty: easy.

- Change any wall into any other wall.
Difficulty: pie-in-the-sky.
Note: this will require quite a bit of research before we actually know how difficult it will be.


Bug Fixes:

There are no known bugs at this time.

How should the program handle populating the lot list with lot names? Should it automaticaly populate the list, or have a button to allow the user to request the time-consuming operation? Should the program block while populating the list, or should it populate the list "in the background" while awaiting user-input?

Good question. How about displaying an empty list on the "Select Lot" screen, along with a button to "Populate list"? Then, people can use the Browse button if they know the lot number.

People will have to wait for "Populate list" to complete, since there's really nothing else to do on the "Select Lot" screen and none of these programs can proceed without knowing the lot that they're working on.

And, I'm not sure that I want to get into the hassles of populating the list in the background, for now. TS3 *is* only a month away!

Hmm, I`m not sure we`re on the same wave-length. Populating the list withOUT the lot-names should be a quick operation, right? I was thinking of populating the list without, then, while waiting for the user to select a lot, open each file in turn and extract the lot name, updating the list in real-time as the names are retrieved. This could easily be done, I think, by providing an "idle loop" that is far from idle. "Has the user hit a button? If yes, deal with it; if no, read a[nother] lot name." Even if this isn`t practical, you follow me now?

You're suggesting populating the list with the file names of all files in the current Lot Catalog, then updating each line with the lot name in turn. That could work.

It may not be necessary... not sure how long it will take to open and parse each file, but it may not be too bad. Surely people don't have huge lot bins? Why don't I try just getting the lot names first. If it takes much too long, I can fallback to your idea.

Fair enough. I only came up with it because you warned that "this could be a time-consuming operation" or words to that effect.

Oh, and the same idea should work for selecting lots by the names of the families who live there, as I suggested for another tool.

No need. Family info is stored in the same record as the lot name, within the neighborhood package, so the amount of extra work that the program does for family names approaches nil. It's just me that has to do the extra work.

Huh? That tells me that the same idea WOULD work for selecting lots by the names of the families who live there. It also tells me that doing either is exactly as easy/difficult as doing the other. It further tells me that doing BOTH is almost as easy as doing either alone.

...unless I totally misread something...?

...I`m confused...

When populating the list of lots, where *do* you get what information, and where ELSE *could* you get it?

The lot name (and family ID?) for lots in neighborhoods are stored in the DESC record of the neighborhood package. The LotAdjuster has had the logic to open the list of DESCs and extract the lot name, size, U11, etc since I took over the LotExpander from Andi. However, I am not currently parsing the family ID from that record, nor attempting to parse the family record itself (FAMI?), to find the family name from the family number. That is two chunks of work (parse DESC for family ID, parse FAMI for family name).

The lot name for lots in the lot bin is stored in the LOT record of the lot package. I've added the code to parse the lot name from that record, but not the code to step through each package in the lot bin and open it to extract the lot name. I'll also need to add code to handle a missing neighborhood record in the lot selection screen, which currently relies on the existence of the neighborhood info. Another two chunks of work (fill listbox with lot names, handle no neighborhood package).

Since I'm not currently parsing the FAMI record at all, that's likely to be the biggest chunk of work.

Most of the code was written expecting a hood package, so removing all of those dependencies is likely the next largest piece of work. However, I have already done some of that work by creating a virtual base class for DESC and LOT.

There's no overlap in the work required, so the work to do both would be the work to each one, added together.

Does that answer your question?

[Update:]

Actually, I realized that you might also be interested in the amount of additional work that the program needs to do.

Since the programs already open the neighborhood package and parse every DESC record, doing the extra work for the FAMI record should be fairly minimal (perhaps twice what it's doing now to fill the listbox).

However, right now the program is only opening one lot package: the one that we're working on. I know that the SimPE DLLs have to do some amount of work for each package that they open, but I don't know how much work that is. So, opening and parsing every package in the lot bin is going to be a significant amount of work.

I know that when I run my automated tests, it can take a long time to do all of the lots in a neighborhood (approximately the number of lot packages as in the lot bin). Long enough that I never sit and wait for the tests to finish.

I know that's not a very satisfactory answer, but the best way to tell how long it will take is to write the code.

Sorry for the confusion. ::blush:: Re the "update": I //was// thinking *primarily* of the work the program would be doing, not the work required of you to write the code to perform the actions. IE, I was concerned with how fast the program would seem to the user whilst still providing additional flexability in lot selection: "how much extra work would the program have to do to do A vs B vs A&B vs neither?". That kind of thinking; wondering if adding either would cost less if the other was already there, etc.

Clear as mud, now? I program too, remember; I have an idea how much it "costs" to *add* a feature, but I`m somewhat unfamiliar with what it costs to *use* particular features in this environment, as I don`t know much about where the information is available. With Adelle, my previous "best computer" dead, and Sabrina, my current "best computer" not fully "ready for Prime Time" yet [I still have some "clean-up" to do with the stuff I migrated from Adelle, and haven`t finished installing all my Sims 2 tools yet], I`m not doing any active development at the moment. It`s been almost two months since I was last in a position to do any, and even then it was slow going as I spent too much time here at MTS2 and in-game to have much left over for development.

My time is my biggest concern; I have a chunk of time available to work on this stuff and I'd like to try to get the maximum results for my effort. Plus, TS3 is out in about a month, at which point it may be pointless to work on TS2.

The time that the program takes to extract lot names from the lot bin is primarily a function of how long SimPE takes to open, parse, and decompress the files. The only example that I have of doing multiple files at one time is my automated testing, and that is slow. So, I concluded that extracting the lot names from the lot bin might also be slow.

My apologies. I understand, though I personaly am not planning on going to Sims 3 any time soon, and fully intend to continue to work on Sims 2 stuff, if only for myself.

Fair enough; understood.

No need to apologize. I appreciate the suggestions that you've been posting and it's worth having all of this stuff documented, in case TS3 bombs.

Besides, I'm hoping that some amount of this work can be ported forwards to TS3.

Aww, thank you! ::hugs::

lol, just post out the wll-wgra data pattern I just found last night back due on 08, 2008 when I last edited.

don't wanna lose it again until solved.

I snagged that, niol, for yet another level of back-up; besids, it might be either interesting or useful to me someday. .

Greatly appreciated, :nod:
But, sooner, I'll have an updated version to add in the latest infos. :P

PS:
guess we may need a lot with just a fireplace which has a foundation attached coz it seems it has a reference on fence-arch which yet a partition type.

This time, just a normal smallest lot like 1x1 (10x20 or 20x10) which contains such fireplace is good.


If one has checked out the differences foundation wall and the unleashed one,
one will realise the followings will be necessary, too:
Unknown 0x8B0C79D6
Unknown 0xEC44BDDC

I don't recognize 8B0C79D6, but EC44BDDC (neighborhood view) is beyond the scope of this tool. General modding info belongs elsewhere.