grayman

I can't locate my original thread post, so I'm putting up a new one. With the sky portal fix in DR 1.3.1, the skies are blue again. Thanks. However, you can see through them when there are brushes on the other side. They're being treated as transparent instead of opaque. Leads to confusion. I've updated the bug (2230) with this note.

Are there plans to add full inventory/weapon support with automatic gamesave/load when changing maps? Due to map size/complexity, I'm facing a split into 2 maps, but it will require going back and forth between the split maps, since the flow is not linear. Keeping inventory and weapons is essential, as well as restoring game state from a previous visit. I wrote some code a long time ago for a Doom 2 mod where any entities w/in a bounding box were also carried over to the next map. I.e. if something was chasing you and you crossed maps, you wanted the thing to be there on the other side to continue the chase. This is prolly not essential for TDM, but it was for the project we were working on. So I'm willing to dive into scripts, etc. to create what I need to change maps properly, but I don't want to do that if this functionality is going to be available in the near future. Thanks.

Well, how timely is this? I was just about to dress my map with a whole mess of signs. Thanks!

Thanks! Team 2 it is.

(No, I don't mean bots begetting more bots.) The lanternbot is way cool. Thanks for adding it. He's been added to the AI Relations wiki on team 16, but there's no discussion of how he relates to the other teams. I put one in my map, and he ignores me, so I guess he's not an enemy of team 0. However, I do have a test guard near him also on team 0, and I discovered that they'd gotten into a rumble in one session. The bot was crumpled over and the guard was nearby brandishing his sword and mumbling nasty 'enemy' barks. My guess is that they bumped into each other somehow and some words were said and the situation escalated. I restarted the map and went and watched them for a while, and they passed by each other twice w/o a problem. I'm planning to put the bot on team 3 with the guards. I've got him guarding a bank, so this seems appropriate. Any forthcoming discussion on how bots relate to the other groups? Thanks.

Here's what I did and it works: 1. If you don't already have one, create a sound definition (text) file (assuming a map name of "mymap"): mymap/sound/mymap.sndshd 2. Put the following in it (or add it to an existing sound definition file): my_earthquake { minDistance 1 maxDistance 25 volume 7 unclamped shakes 0.5 sound/ed/earthquake/rubble7.wav sound/ed/earthquake/rubble9_basso.wav } When testing, you can adjust the distances, volume, and amount of shaking to fit your needs. 3. Fire up DR, load your map, and add a speaker where you want to experience the earthquake. Give it this property/value pair: "s_shader" "my_earthquake" Alternatively, you should be able to select the existing s_shader property and hit the "Choose sound" button. The pop-up window should show you this: +mymap Open that and you should see this: my_earthquake Select that, hit OK, and you've added the sound. Trigger the speaker any old way. You can trigger it again to turn it off, or wait for it to die out on its own. Thanks to Fidcal for the pointer.

Posted. #2231 http://bugs.angua.at/view.php?id=2231

Issue posted, with test map. #2230 http://bugs.angua.at/view.php?id=2230

So I bring up 1.3 for the first time and notice some changes: 1. All my Portal Sky brushes are now black, so I can't see where they are. (bad) 2. The Snow patches are now nearly transparent. (okay) 3. Decals display better, instead of seemingly fighting with the plane they're next to. (good) 4. Transparent parts of decals are truly transparent (okay) Are these caused by the "load filters from all .game files" change? How do I get my sky brushes defined, so I can manipulate them? Thanks.

I want to use the new Readables Objective feature (thanks for that!) to set a new objective once a letter has been read. Maybe I'm doing this wrong, but . . . 1. Bring up the Objectives Editor. 2. Add a new objective. 3. Edit it. 4. Change its description. 5. Uncheck "Visible". 6. Add a component and edit it. 7. Select "Readable is closed" from the type list. At this point, I get an error window that says "Exception occurred: SpecifierType not found." Hit the window's Close button and another window comes up: "Runtime Error". Hit the window's OK button and another window comes up: "unknown software exception". Hit the window's OK button and DR dies. Am I doing something wrong?

Thanks!

Thanks. I'll look into these possibilities.

Is func_earthquake supposed to work? What I'm expecting is that when it's triggered, the screen should shake a bit and the "earthquake" sound should play. Neither happens. Thanks.

Thanks. Will watch out for that.

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.

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.

No.

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.

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.

Oh, it did damage all right. I got the red blood gui overlay the moment it smacked me, and my health dropped.

This one got me laughing. An archer shot me in the head, and I found myself walking around with an arrow stuck up there. Any way to not have arrows stick in the player? If you survive, you have to deal with this arrow shaft flopping around in your field of vision for the rest of the game.

First picture shows the lit model. Second picture shows the unlit model. I know the models are getting switched because I tested with the models in different locations before overlaying them.

When working with a texture on a brush face in the Surface Inspector, I can type in the scales, shifts, and rotation. When working with a patch, however, I can do none of these things. They're both faces. I ought to be able to work with them the same way. So an enhancement would be to enable those fields when working with a patch. Thanks.

I mean when the readable drops away as you back up or turn. I don't mean holding it and dropping it. I don't intend for these things to be in the inventory, though they could be.

I gave up on rats. Every one of them would eventually find a spot it didn't like. Some were stuck halfway up some steps, some were stuck on ramps, and the other night I found a couple of them going round and round and round on a flat floor with no obstructions nearby. I watched this pair for a while, way past the time when one or the other should have stopped or spun off in a new direction, then decided to fire the lot of them. One side benefit: I don't have to wait for aas_rat to be built! Before the layoff, I found one rat just sitting on the floor, doing nothing. I picked him up, and he squiggled all around in my grip, but when I dropped him, he just sat there again. I thought he was dead, but never having killed a rat, I didn't know what one should look like. I think he'd retired on the job, so the layoff prolly didn't surprise him.