R Soul on 15/7/2013 at 21:59

---

It's more likely it's taking a long time than it's freezing. Dromed also reports the object ID of each light as it's processed, so you can have a look at it and make sure the Light/AnimLight property has a radius set. 0 is infinite, so if the light is surrounded by complex terrain, it will take a long time to process it.


'Simplify your terrain' is better advice. If you increase the grid size and then snap all unsnapped brushes, the results won't necessarily be good. E.g if you have stairs that are 0.75 feet high, snapping everything to size 12 will bugger up those stairs.

MysteryMan on 15/7/2013 at 22:11

---

I agree although looking at his map,nothing is snapped to the grid at grid size 11, is the reason I suggested it.
Snapping also eliminated a lot of errors. I would think some bad cells would spring up, which might be the reason it won't light at 32x2. It is common to have to make some internal adjustments after snapping such a large mission. At grid size 11 the entire map is off .17 x,y,z

The map may have to remain at grid size 11, because of it's size.

MysteryMan on 15/7/2013 at 22:59

---

I tried the snapping check and commands on grid size 11, but the brushes won't hilight or snap at 11. Only 12 and up. I don't think you will be able to snap to 12 because your mission is so large. Possibly, is that thousands of cells have already been created using grid size 11, and the processing can't take place without alot of difficulty. Grid size 12 and up is a common practice in dromeding, but I have known a few authors who swear by grid size 11 , and have little difficulty at that grid size. Grid size 11 is good for brushes .25 and for fine detailed work.

Edit: There is a possibility that a more powerfull machine could change everything on grid 12. I know, that my machine won't light all of the big maps sometimes.

Here is a list of things to try to find out what is making it crash: It could be that the room itself is 1 bad cell.
A.Leave it at grid size 11-Fully process it.
1. If it is a local or distant view of objects causing the crash, use blockable brushes on one wall at a time, until you have all 4 walls, the ceiling, and floor blocked off from view. Do one wall at a time .Experimental only!
2.Use show_stats in your command window prior to going into game, and note your postion x,y,z, and your direction you are facing when getting the crash. Then try to pinpoint the exact direction and position by triangulating from 3 different angles. Enter through the other doors,ect.
3.Remove the room entirely along with roombrushes,objects,doorways, ect, and see if the crash still occurs while in the perimeter of the ex-room. Removing the room entirely would be the last resort, if the problem only exists within the walls of that room,and if that room was not crucial to your game play, or story.

MysteryMan on 16/7/2013 at 12:48

---

You can look at it before deleting, by using the command show_cells, then go in game. If it were a bad air brush, then more than likely a bad cell. If that or the air brush leading to the stairs, then a possibility if the route was needed to have access to another room, a small hallway in it's place?

The main idea is to find what ever is causing the crash 100 percent of the time-every single crash, and alter the brush(s) change the cell,or eliminate the bad cell all together.

Edit: I used show_cells first to observe the intersecting lines, then show_cell to show the different colors, but couldn't find anything out of the ordinary in that room, or any of the surrounding rooms.

MysteryMan on 16/7/2013 at 15:26

---

In the reported bad room.
I just had a crash going into the room from the hallway, heading north through the double doors, going to x=383 ,y=401, z=458, then looking East. Looking toward the small set of steps.

And another, same route as above but turning to the North East, once in the room and staying at x=395, y=401, z=458, then looking to the corner North by North East. (Adjacent corner where small group of steps are located)

The only thing in common is the y=401, and z=458, the x=383,andx=395 but mainly looking east by north and east by south.

This only happens about every other game, and not consistently. If the steps you eliminated and made a ramp are the same as described in the first report of crash, maybe you have eliminated it.

I took fraps video of each of the described crashes, if you think it would help anyone troubleshoot it, let me know, and I will post them here.

Crash toward steps: x=383 y=401 z=458 Looking East by South. You can forward it near the end, and that is the crash.
******** width="420" height="315"><param name="movie" value="//www.youtube.com/v/bjZtxxFMe8s?version=3&amp;hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="//www.youtube.com/v/bjZtxxFMe8s?version=3&amp;hl=en_US" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>

Crash: looking North by North East:x=395 y=401 z=458
******** width="420" height="315"><param name="movie" value="//www.youtube.com/v/mdOO0jh9KUw?hl=en_US&amp;version=3"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="//www.youtube.com/v/mdOO0jh9KUw?hl=en_US&amp;version=3" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>