Jump to content
The Dark Mod Forums

separate aas run


grayman

Recommended Posts

Is there a way to separate the creation of proc, cm, etc. from the creation of the aas files when dmapping?

 

I'm hitting the malloc failure more often now. Sometimes I'm able to clean up the map, but I find myself doing more debugging than creating these days, and that's frustrating.

 

My current malloc failure is in the aas part of dmap. It creates all the other files just fine, then bails out when it starts the aas creation. I'm thinking maybe I can run aas separately, which would allow me to hopefully bypass the memory issues. Maybe.

 

Any hints would be appreciated.

Link to comment
Share on other sites

If you're running into malloc issues its usually because you have badly portalled areas.

This usually happens when you have a hub area (middle of the spiders web) and then areas connected to it are portalled either badly, not sealing or leaking back into the buh which creates a mess and runs into complexity issues.

 

If you want someone to take a look at what's going on, let me know.

Link to comment
Share on other sites

If you're running into malloc issues its usually because you have badly portalled areas.

This usually happens when you have a hub area (middle of the spiders web) and then areas connected to it are portalled either badly, not sealing or leaking back into the buh which creates a mess and runs into complexity issues.

 

If you want someone to take a look at what's going on, let me know.

 

Thanks.

 

I've checked the portal boundaries and all seems well. I'm not seeing into spaces I'm not supposed to see.

 

I'm closing in on the problem, which is caused by func_static trim around the top of a building. Take it all out, no crash. Put it all in, it crashes. Since the trim is all func_static, it should have no bearing on portalization. There are 8 pieces of trim, none of which crosses visportal faces.

 

I'm currently taking them out one-by-one, to see which is causing the crash.

 

To clarify my initial post, the proc file is created, and neither the cm nor the aas32 file is created. So it's crashing either in cm creation or aas32 creation. Don't know which is done first.

 

 

 

Link to comment
Share on other sites

Removing all the trim worked this morning.

 

Removing the trim piece by piece until it's all gone (again) crashes.

 

Comparing the two *.map files, they're the same. Rerunning the earlier one now crashes.

 

"dmap noAAS" crashes

 

"dmap noCM" crashes

 

"dmap noAAS noCM" succeeds. If I follow this with "runAAS" in the same session, it crashes. If I quit, restart, and do "runAAS", it succeeds. In the first case, AAS is reading data already stored in its data structures. In the second case, it reads the data from the proc or map files (don't know which). So there's definitely a memory-handling problem that AAS trips over if it has to read from data structures left behind by the process that creates the proc file. Map complexity tickles the bug.

 

Well, I guess I'm off to recreate the problematic area brush by brush, since I don't want to abandon it.

Link to comment
Share on other sites

I'm starting to get the feeling that mappers are going to maybe have to start creating multi-mission campaigns rather than complex single missions? Seems like memory allocation and deallocation bugs are built-in to D3?

 

I know it's got to be easier said than done at this point, grayman, but if you are having these problem just getting compiles I imagine the missons themselves will choke even some to level machines. Maybe you might start thinking about if/where you could split the mission rather than Visportal it?

 

Just a suggestion for consideration.

"A Rhapsody Of Feigned And Ill-Invented Nonsense" - Thomas Aikenhead, On Theology, ca. 1696

Link to comment
Share on other sites

Its unlikely that chunking the level into multiple parts will solve it.

 

And now for some complete theory-craft and speculation.

The only time I've seen this issue was with the visportalling of Sons of Baltona, in the release version they work fine for the most part and only cause crashing during playing, however once I started to simplify them and optimize some of the remaining ones there were times when the aas compiler(or whatever you want to call it) would get abused as it was possible for the whole area above the mansion to be open if one portal was open, from there it would have about 30 adjoining areas which all had like 2-3 areas making a huge graph; which then all have to be recursively processed(I am going on guesswork now, however it makes sense to me... perhaps greebo or Tels knows more) however due to this happening its possible to create a loop, it doesn't take much thinking to realise that a loop is going to do very bad things. Once this happened it would just hang doom3 until I realised that I needed to make 100% sure that the area above couldn't be opened like that. In this case I could lower a large sky portal brush in the same outline of the mansion. Problem solved.

 

I've had similar encounters on my own maps, but that experience always told me to look for possible leaves that would have dangerous branching, and I'd fix them up in 1-2 compiles and never investigate further.

Link to comment
Share on other sites

I've noticed func_static trim doing fishy things before too (really slowing down performance, killing portals). I was suspecting they might affect the normal brushwork around them, like bugging up the rendering where there might be a sliver or z-fighting between them, which might open a gap between leafs and be like an internal leak (?), then bug up other stuff from that. So even though they aren't BSP themselves, they still might bug up BSP-type stuff ... was my theory anyway. Or something like that. I was never sure because (in my case) I just changed the func_static back to normal brushes and it stopped the fishiness, so I didn't investigate.

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to comment
Share on other sites

Back to normal here.

 

I backed up a bit and moved forward again.

 

In the end, I was able to retain the troublesome trim, and I converted some halfway-up-the-building trim to func_static. This mid-trim has been around for a while (in worldspawn form), so I doubt if it contributed to the problem. No major changes to the architecture were needed. The order of the brushes is rearranged; maybe that helped.

 

I'm nearing the end of this map, which is probably a good thing. A few more weeks and it'll be ready for beta testing.

 

I have considered breaking this into two maps, and might end up doing that. Will have to study docs on changing maps and how to get the maps to "talk to each other", since you'd have to go back and forth between the maps, not just linearly forward.

 

Thanks for the comments and the instructions on how to run w/o cm and aas.

Link to comment
Share on other sites

It's also true that to best utilize func_statics, you should seperate your trim so it's as convex as possible.

 

If you have 8 pieces of trim circling the perimeter of a building, and you turn the whole 8 pieces into 1 func_static, the location of the origin (likely either inside a different visleaf, or smashed inside some brushes) can cause dmap and runtime issues.

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

It's also true that to best utilize func_statics, you should seperate your trim so it's as convex as possible.

 

If you have 8 pieces of trim circling the perimeter of a building, and you turn the whole 8 pieces into 1 func_static, the location of the origin (likely either inside a different visleaf, or smashed inside some brushes) can cause dmap and runtime issues.

 

Thanks. Will watch out for that.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...