Is this something I should be understanding? 'Cause I don't at all. What is this 'levelroom' of which you speak?
I thought you HAD coded that ages ago. Must be confused. Again.

All I can say is diagonal walls by unlocked walls (not swim-pool wall or stage walls) to a border have appeared stable in my base game so far.



"levelroom" is type of complex build tools like foundation, decks, stage, and swimpool. which consists of more than one build feature like walls. For all I know, it has at least wall partitions and floor tiles.
http://www.modthesims2.com/showthread.php?t=106473

Although I can try the suggested ways to de-levelroom" such product, but I have to admit they won't completely remove all the invisible elements of "levelroom". and this is what I meant to dig deeper on.



I surely want the release of "LotCorrupter", but you said you want lots made out of it either marked or unsharable.

I believe I'm not the only one who such a version.

The marker way seems not much of an advance since the last time.

So, I suggested to make those lots to crash the game when exported or uploaded to avoid them to be shared easily. I tend to believe even this sort of game crash can be a good sign to warn users not to share those lots. Surely, the type of game crash has to be specific enough. Lots can be saved in-game without any interfere except when they get exported or uploaded.

So, I see we need some helps to get that made possible.

If that sounds good, that's an ironic approach.
If not, it can be a crazy idea and joke.

Your only confusion is that you don't understand how persnickety computers are. As a programmer, I have to think of every contingency and then tell the LA how to deal with it.

When I coded the portal movement, I just didn't think about lots with an additional road on one side of the lot. So, I coded this as:
- find the middle of the lot and then put the mailbox on one side of the middle and the trashcan on the other side

This works just fine as long as there are no additional roads on the sides of the lot. It also works well if there are additional roads on both sides of the lot.

When I realized that I had forgotten about lots with an additional road on only one side, I changed the logic to:
- ignoring the roads, find the middle of the lot; put the mailbox on one side of the middle and the trashcan on the other, then adjust the location to take the roads into consideration.

One of the big reasons that bugs occur is that it's really difficult to think of every single thing that can go wrong, and then come up with a good solution for every one of those possibilities.

Programming is a lot of fun because the computer does exactly what you tell it to do. Programming is also very frustrating because the computer does exactly what you tell it to do.

Unfortunately, that just doesn't seem to be sufficient. As we've seen, we all seem to be able to make our own rowhouses without any problems, but when other people use these rowhouses in their own neighborhoods, some of them experience crashes.

That's why I found the Maxis-made lots so helpful. They were much more likely to crash on my machine after "dangerous" shrinking.

It is best if you can make a lot which crashes consistently, then find out what tiny changes need to be made to the lot to make sure that shrinking doesn't crash. The crashes can point out things which are "unsafe".

The same logic applies to things which are obviously corrupted. Once it became apparent that objects on the outer tile of the lot could consistently become corrupt, but that objects 1-tile in had no obvious problems, I decided to restore the 1-tile restriction on objects.

This is the technique that I used to convince myself that the 1-tile restriction was significantly more safe. It's also the technique that I'm using to test perpendicular walls. I tested various types of diagonal walls and they all crashed eventually - although some of them worked on some lots.

Actually, there's an important difference between what I said and what you inferred:

"If I could mark the lots as being unsafe, that would be great. If I could find some way to make these lots unshareable, even better."

Note that I don't say that this is a requirement, just that it would be nice to have.

If I can make a program who's name makes it clear that the generated lots are unsafe, and if I can create an upload post which makes it clear that lots generated with this tool are not to be shared (ever), then I've achieved some way of distinguishing the "unsafe" and "safe" lots. Marking the lots or making them unshareable would be bonuses.

If I can mark the lot so that the creator can use SimPE to check whether the LotCorrupter was used, then that's great. The creater has some way to make sure that a lot is safe before uploading, and there's no need to be sure that the mark can be seen in the lot installer (which proved to be difficult).

People who want to share lots would use the LotAdjuster, secure in the knowledge that these lots are relatively safe. People who want to create lots for themselves could decide to use the LotCorrupter - knowing that the lots are "unsafe", but choosing to take the risk.

Believe me, I want to give people access to the unrestricted shrinking option. I'm just looking for some way to do this which can ensure that a non-malicious user will not share unsafe lots.

So, my current thought is that we stop people from sharing these lots at the source. No need for warnings on lot uploads, since these lots should never be shared at all. No need for marks inside the lot that will be passed from one upload to the next, since these lots should never be shared at all.

I don't know about you, but I sometimes package lots for my own use. So, I'd prefer to keep this ability. I can't image how to make a lot so that it can't be uploaded to a web site, but that would be nice; I'm just not sure that it's do-able.

Speaking of the LotCorrupter, I've been wondering about what features I should enable / disable:
- Disable all error checking
- Enable shrinking to the very edge.
- Enable lots > 6 x 6 (without error checking, this might actually get further than in Inge's test)

Anyone have anything else that they'd like to see? Of course, I'm only talking about enabling and disabling features which are already implemented.

Also, is anyone artistic enough to create a picture for the LotCorrupter? Something which is red and menacing (lightning? ghosts? zombies?), so that people will not accidently confuse it with the LotAdjuster. Perhaps something which suggests things that are broken or destroyed, like someone being electrocuted when they try to fix a TV?

The zip file contains the LA bmp, so that you know what size I need.

I just thought of an alternate solution to the problem of removing the front road.

The LA can disable the Road checkboxes for all invalid choices:
- If there is no front road, then the user has to check the front road before the other road checkboxes will become enabled.
- If there is another road on the lot, the front road checkbox is disabled.

I think that this is a "better" solution to the problem, as long as people don't think that it will be confusing.

Thanks for the explanation, I think I got it now.
I see. Another good expanation.

i think LotCorrupter might be a sufficiently descriptive name. It would scare me off!

No matter how scary you make the upload post, some people will think it doesn't apply to them - but you have to let people take their own resposibility sometime.

If you make something that can be checked with SimPE, that will be useful both to the orginal builder and to downloaders - responsible creators will use it before sharing, suspicious downloaders can check for themselves before installing. (Or can they? Does SimPE let you look at lot packages that are not in the game yet?)

Me too. I'm often moving lots from basegame to fullgame and so on.
I can do this with help from my other half, but if someone else is interested, go ahead.
Can't think what you decided before, so I'm not sure what to compare with. This way sounds easy to deal with. The screenshots you posted above look clear enough.

That's good; that's what I want. For once, I want this upload to have a minimal number of downloads. The question is: will MTS2 allow me to upload something called the LotCorrupter, which is known to corrupt lots? Perhaps as a "Testers Wanted" upload?

I agree. Until now, I had never been able to figure out how to share this feature while protecting people "enough". I think that having two completely separate programs makes me feel more confident that I've done enough to protect people. I can now ask people to NEVER share lots made with the LC; you want to share, then use the LA instead.

I don't believe that SimPE will allow you to examine the lot until it's installed into your LotCatalog. Once it's there, you can check the LOT record (6C589723). The LotCorrupter string is clearly visible in the hex view. If a lot in the LotCatalog is bad, you can remove it without any problems. It shouldn't corrupt your game until you actually try to install it in a neighborhood.

I can also add a picture so that people can look for it during the install, but some people will remove pictures before uploading a lot. There's a lot less likelihood that they'll try to mod the LOT record. No harm in doing both, of course.

Thank you. I'd appreciate anything that you could come up with.

I like the idea of someone being electrocuted. It seems appropriate: someone who wants to fix their lot, but doesn't have the requisite skills / knowledge / cautious approach, so they get zapped.

Or, maybe a house being struck and destroyed by lightning?

The current fix is in the current test version. The new fix will be in the next version. They can actually work together, so I haven't wasted my time doing the original bugfix.

In the opening screen above, I would alter the second part of the spiel a little -

"If you don't mind corrupting your game, and have no desire to share your lots...

The LotCorrupter is for you!"

You may think it isn't scary enough this way, but it is more elegant.

You don't actually want testers, but that might be a good way to separate it further from normal downloads.

That sounds reasonable. I agree that the warnings are nicely visible in SimPE. It's not likely people will bother modding a lot with the Corrupter unless they are doing something they can only achieve that way - rowhouses, for example - so users should have a cue (from the creator's pics/description of the lot) to be suspicious when they download.

Having two separate programs is a great idea, specially if it gives you peace of mind.

I have uploaded the newest version of the LA, along with the corresponding version of the LC.

Please let me know if you notice anything odd about the LA. The LA and LC are sharing the same source code, so I need to make sure that I haven't ruined the LA with the LC-specific code.

The main thing that I need to know about the LC is whether the expected features are enabled / disabled as expected. I don't really plan to support this product, although I am willing to update it as the LA changes.

I finished compiling the new LC before I saw your suggestion... I'll put this into the next version.

I've dug deeper a bit the last night and realised there can be more differences between the levelroom foundation walls and unlocked foundation wall than what can be seen in-game. At least 6 more types of files were noticed as "different". Some are the unparsed file types.
But, I'll have to use a clone lot to redo all 3 stages to re-confirm that coz I used 2 lots made in the same location but at different times. Although I had moved the former away, it's the lot package file before the move that I copied to my research folder. But to narrow down the differences further and confirm that further, I've to re-do it with a single routine.




I hope at least a team member may be willing to host it if MTS2 testing forum won't host it.

[omitted: I guessed somehow some infos weren't updated to the monitor so that I saw something not matching. Sorry for that]



I guess a first txtr file will allow users of SimPE and cleaninstaller to view it even though it may not be instinctive to some users simply because they don't normally need to do that before.

As for the jpg files, I just thought about adding a feature to trim the default and add the warning marker into a lot package marked as "risky" as LC is scanning the neighbourhood lots. This way, users just have to open LC and select this option, and LC will do the works for users. Users just have to reload the game once more time to export the lot or upload the lot. Such reload is necessary for manual removal of jpg files from the lot package file anyway.
Just as previously deduced, jpg file will get erased anyway, yet users with LC can run that feature to re-tag that jpg file to a lot.

This or these, I guess they can learn that/those easy little bit(s).

Plus, the lighting in the jpeg files is opposite to the in-lot one, so it matches the neighbourhood lighting instead.




Are they gonna be like opening check options?

This is not an unparsed record. The LA has been changing this record since Andi wrote the code. The definition is in the wiki. The record contains the same information as the neighborhood Lot Description (DESC = 0BF999E7), but in a slightly different format. LOT exists in the lot package and DESC exists in the neighborhood package. I have changed the "Lot Description" string in both records, just in case the lot becomes separated from the neighborhood. When a lot is packaged, the information from the DESC is copied to the packaged LOT. When a lot is installed, the information from the packaged LOT is copied to the DESC.

No. I don't really want to waste my time changing the LotCorrupter, although I will consider requests to unlock other unsafe features, as long as they are already implemented and relatively easy to unlock.

I consider the LotCorrupter to be unsupported, although it will automatically get all updates to the LotAdjuster because it is created from the same source code. My only concern is that the expected features are available.

I am now convinced that the LotCorrupter can corrupt lots. I have personally seen crashes and corruption for every restriction which is lifted.

I guessed somehow some infos weren't updated to the monitor so that I saw something not matching. Sorry for that.



"all error checking" seems more critical than the others at least to me.

If I use LC to assist in exploring "built-to-the-edge", I'll need the error checking.

I'm not surprised that >=70x70 lots will crash the game simply because it has been deduced that 64x64 in the world database file is already the max allowed limit for TS2.

Rather, the other 5 type of files can be larger than 64x64. Yet, people can use LC first and then alter the W and H values back to 59x59 pretending the lot is 60x60 to avoid the crash caused by the world database file.

Not a problem. Just wanted you to know that I'm not updating some arbitrary bytes in some arbitrary record. I try to avoid that whenever possible.

Are you sure? The error checking is mostly there to ensure that the LA is parsing records correctly. This includes tests that height and width are never > 6. The LE didn't have this error checking and it worked just fine. Personally, I believe that the LotCorrupter is better off without it, since it gives you a lot more flexibility. If people really hate the LC without error checking, I can quickly reinstate it.

Oh, one other thing: if you want to do error checking on a lot, you can always run it through the LA with no size change.

This is true for versions which are pre-Castaway Stories. We don't know whether EA accidently left the ability to have lots > 6 x 6 in the code base. This way, there's an easy way for people to play with the feature. If you don't want it, then don't select sizes > 6.

I honestly believe that you will like LC as is. I think that I've removed the right stuff. The main questions are:
- Have I destroyed the LA by adding LC-specific code?
- Have I removed enough restrictions for the LC to function as people want it to?

I think that it's time to consider a public test of a pseudo-rowhouse, built with the latest LA. Plasticbox, would you like to do the honors? Would you like us all to test your lot after it's shrunken and before it's uploaded to a public thread?

hooray!
I've got a shrunk lot submission in the queue at present, but made with LA1. Hope it goes through this time - already knocked back for a change once. (Not sure what was wrong, but I altered everything that might have been it.)

Haven't done anything with the latest test version so far - it's Mother's Day here today, so busy with Real Life.

Some more infos about 3D array instances 0x14 and 0x15 based on my recent tests.
http://www.sims2wiki.info/wiki.php?title=2A51171B

Please correct me when necessary...

Yes, I'd love to (Thanks for the pointer, niol). I've been downloading consecutive versions but you were updating too fast for me to keep up =) I got 100D now, that is the current one, yes?

I have a bunch of unfinished (built but not shrunk) lots floating around .. will go through them tonight. I'll post it in the private forum.

Something entirely different: Would anyone have an idea why there are, in lot files in an entirely unplayed neighbourhood, between 1 and 95 "Unkown to Unknown" Sim Relationship records? I've been looking at lots in SimPE (yes, they do get considerably smaller when removing all the jpegs of the different floors that only the EA site would ever have a use for), at the lots in Middleground to be exact (link in sig), and was quite surprised to see those records .. I never entered live mode in my local Middleground.

The number of records could be related to how often I've been entering and exiting the lot (from what I recall, those with very few records were lots I finished relatively quickly) -- I could be on the wrong track though, seeing as this hood is more than half a year old. It could also be that pre-shrunk lots have some of these records already in them, or something. Any ideas?

Thank you for this thread, all these links being very helpful to me for future building projects. Nice work!

True, the game just adds in all those template files into a lot that has been saved more than once whether the neighbourhood is sims-free or not. Those files seem to be all the same in my sampling checks. I didn't find any real specific data in them yet.

I was "crazy" enough to trim them off, and I've not come across a problem in base game yet. But, I'll have to see in live mode though. After all, I saved about 40kb by deleting 945 files of this sort. But, the resultant compressed lot in rar or 7z showed insignificant difference to me as expected.

But, lots saved once only without such file type had been used as good as those with this file type. So, I personally assume trimming them is not a bad idea.

Yes, I've noticed that unplayed lots have a bunch of "sim" related stuff, that couldn't possibly be useful. Not just relationships, but lots of other stuff as well.

I've been thinking that there might be a use for a tool which would remove all of those extraneous records from a lot package. It could also be helpful when packaging a lot which has been played, as long as you don't intend to package the lots with any sims on it.

I believe that such a tool is do-able with my current level of knowledge, but it would require some testing to make sure that nothing was broken.

EA obviously doesn't think that much about optimizations.

Yeah I saw another one as well -- "Sim Record" perhaps?, not sure about the name anymore -- this always only occurred once so I thought it might be a placeholder of some sort and left it in. So that's also useless? Good to know, thank you.


Kind of a "lot cleaner", you mean? Yes that could be useful .. although possibly of more or less academic interest, or can those sim records be harmful?

For me the biggest issue was the jpegs (since I was mainly concerned about the file size), and those are easy to find in SimPE and it feels like a rather idiotproof process to remove them, so I'm not sure if it would be worth the effort to write an extra tool for that. On the other hand, it might be very easy to code if all you need to do is find all jpegs and kick them out (I haven't seen any other jpegs in a lot file .. everything else seem to be png. Only the icon (what shows up in the lot bin) I haven't come aross -- possibly because all the Middleground lots were modified after having been placed in the hood).

Back whan I made my complete hoods, it was a real struggle to squeeze them into a <10MB archive (I had to take several lots out of the first one, which was a shame) -- now when I cleaned out those rubbish jpeg files, the uncompressed Middleground folder shrunk from 23MB to 8MB(!).

Pardon my intrusion into a discussion that's mostly over my head, but I'd love to see a lot cleaner program. Anything that reduces unnecessary game clutter is a good thing!

It's a big leap from "these records have no value" to "it's safe to delete these records". We know that the records are useless, but we don't really have any evidence that it's safe to remove them. Sounds like no one has actually played the game after deleting them.

In general, it's probably safer to keep the records, if you aren't modifying things outside of the game. However, there is some evidence that these records can be harmful if you do odd stuff, like lot package replacement. It's my work with copying lots in Castaway Stories that made me think that a utility to clean sims from a lot would be helpful. That said, I still have no evidence that it's safe to do so.