Crash on resized lots at 7PM -- any ideas?
Zazazu:
All this focus on roofs being on the edge being the issue feels wrong. The only lot of mine I've gotten to crash consistently is my 1x1 brownstone, unreleased. It doesn't have a roof in the traditional sense. I never used the roofing tool. It's a multi-level floored surface.
If anyone wants to test it, here's the link: http://www.4shared.com/file/28206022/94ab3616/Corner_A.html (requires all EP)
Inge:
Quote from: Zazazu on 2007 November 03, 17:22:43
All this focus on roofs being on the edge being the issue feels wrong. The only lot of mine I've gotten to crash consistently is my 1x1 brownstone, unreleased. It doesn't have a roof in the traditional sense. I never used the roofing tool. It's a multi-level floored surface.
Well that's pretty much how I feel about the wall issue. Usually once a computer-related problem is tracked down there is a Eureka moment when you realise that it is totally reproducible once it's properly defined. The walls on edge of lot is not a repeatable cause of a crash in isolation, even related to EP. Else I would be able to run all row houses without problem, while someone without whichever EP would be able to run none of them.
My bets so far are on the deleted object idea being a better trail to follow. Maybe in BV the core objects and controllers are not put in the same location as they were in earlier games so they're not getting deleted to the same extent.
Mootilda:
Quote from: Zazazu on 2007 November 03, 17:22:43
All this focus on roofs being on the edge being the issue feels wrong.
Quote from: Inge on 2007 November 03, 17:39:57
Well that's pretty much how I feel about the wall issue.
I don't believe that roofs are the *only* issue. However, the roofs seem to be *one* issue.
There are several possibilities:
1) There is one issue which is causing all crashes - unlikely, but it would be wonderful if we could find such an thing.
2) There are a finite number of issues which are causing all of the crashes - I'm still hopeful that there are a finite number of fixable issues, but we just don't know yet.
3) This is a black hole. All energy put into the issue will be sucked into the void, and in the end there will be nothingness. If so, then we are wasting our time.
The question is: which of the above is true. I'm reasonably sure that there isn't just one issue. I'm willing to spend some finite amount of time on trying to resolve multiple potential issues. But, at some point - if we haven't found the answer - it just won't seem worth the effort.
I took a quick look at the roofs and I now know that I don't understand roofs well enough to do anything yet. The Roof record type for a shrunken lot doesn't contain any coordinates which are off of the lot. If someone had some idea of what to try, it would be helpful. Record types, instances, etc would be the most helpful information for me.
If you have other suggestions as to (relatively) quick things that I can change in the LotExpander to help narrow down the problems, I'm very open to doing them. My main criteria are that I don't spend too much time and energy on something really nebulous.
I hope that this doesn't sound too harsh. I'd love to be able to provide this feature, but I have very little experience with modding - just my work on the LotExpander. That's why I was hoping that testing might shed some light on areas of interest.
Inge:
Quote from: Mootilda on 2007 November 03, 17:50:52
If you have other suggestions as to (relatively) quick things that I can change in the LotExpander to help narrow down the problems, I'm very open to doing them. My main criteria are that I don't spend too much time and energy on something really nebulous.
You already came up with the idea that seemed good to me - not deleting objects that are on the shrunk bits. Obviously I don't know how well that fits in with your idea of relatively quick, as I am not aware of your implementation process. I have already given a concrete reason why I think this is a good idea, earlier in the thread.
Now this could result in actual visible objects like wall segments and windows being plopped into weird looking places, but the instructions to the user were to make sure no visible objects were on the deleted part of the lot first. If instructions have been followed, that *should* just leave a few invisible objects and controllers being moved onto the part of the lot that is remaining - which I think is a good thing because of the resources these things can contain.
nil:
I can say what I've seen so far on the visible elements of a roof.:
known from Materials:
1. RoofTop
2. RoofUnder
3. RoofEdges
known from wall.txt
4. attic walls
From my experiences and observations, attic walls is added by the roof tool only at the perimeter loci of a roof product and is not added for those sides where the roof edges reach down to the grid layer the roof is on. The latter observed condition is the reason why rooms by the roof tool alone are not a closed room to be considered as "inside" although graphically it appears so.
Note, a build tool can add >1 components into a lot for a given use.
As for whether Mootilda can utilise her first approach to reach the goal to trim off the over-hangs depends on whether the over-hangs are a part of the mesh group that occupy grids at the in-roof side or the out-roof side (the extra one grid outside the roof body predefined by the roof tool and user's drag). If it's the former, I think, the trimming may be completely unnecessary when no other settings is actually affected. If it's the latter, we're likely to see a hole gap but we can add the attic walls to fill those gaps in advance.
But at least, such optional trimming may help analyse the roof.
There're different types of roofs. Some have attic walls at some of its edges while some have no attic walls at all.
If one doesn't count this, it's harder to draw a conclusion if any is deducible.
Please forgive me for my still learning some programming things and my wondering about different "crazy talks". I didn't major in that field, nor I learn them enough to tell.
I'm looking forwards to the new LE version that may ensure all objects to be in-lot to see if that is a factor.
But shrunk lots for row houses are still much more stable and tolerated by the game than wall-at-the-edge lots by means of the fence-based default replacement on Wall1. The latter crashed at lot-loading.
After all, to say the least, should all fail, we can share lots before shrinking, and let those who want row houses to shrink the lots by themselves for uses in their own testing neighbourhood(s) or even custom folder or game copy to set aside from those they expect to be relatively safer. In such given cases, the users know the risk that their neighbourhoods can absolutely go bonker corrupted, but they're willing to use them in such a way.
Navigation
[0] Message Index
[#] Next page
[*] Previous page