grayman
-
Posts
13591 -
Joined
-
Last visited
-
Days Won
199
Posts posted by grayman
-
-
Hmmm, are you by any chance using horizontal VP's up there?
No.
-
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.
-
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.
-
Very funny. Did that arrow do health damage, and/or is it possible that it is stuck in the players hood, just above their head?
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.
-
Do you mean literally "drop" or just "stop reading and put back in inventory"? The former might never happen if the player carries the message around.
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.
-
Using an immobile readable is a bit more "stable". That way if the reader's read it, well, that's the only thing he can do with an immobile readable.
Make an invisible button and link your readale to it with "frob_peer" "whateverthebuttonsnameis", and have the button target a objective visibility entity. Not too hard - took me forever to figure it out though (anoot has like 5 of them)
But doesn't that cause the objective to be satisfied when the player picks up the readable?
I don't want an "objective added" message popping up before the player has had a chance to read what it is he's got to go do.
I can't control whether the player actually reads the text, but at least if I wait until he drops it before adding the objective, it'll be the closest I can get to what happens in real life.
-
7244 brushes
1256 patches
2845 entities
245 shaders
369 models
106 skins
tons of visportals
I have a memory utility running all the time, and with nothing else running, it shows:
22% before I start TDM.
26% with TDM idling at the main menu.
Start dmap . . .
54% when dmap completes.
52% after a couple minutes of idling at the main menu again.
4Gb memory.
Given the two quite different memory usage levels before and after dmap, it looks like dmap is hanging onto nearly all the memory it requested to crunch the map and create output files.
-
I used to drive myself nuts aligning textures whose faces didn't share the same plane until I figured out a crutch.
Change the misaligned texture on adjoining faces to a texture that is so easy to align you could do it blindfolded, like stone/cobblestones/flagstones02_plain_cornerstone_right.
Do the alignment, then paste the true texture onto the faces. The editor won't change the horizontal and vertical offsets or orientation, so you end up with perfectly aligned textures.
-
The glass in the unlit skin (lights/electric_wall_fancy_up_unlit) for the model lights/non-extinguishable/electric_wall_fancy_up.lwo is bright, so when the light is turned off and I change the model, the lamp still looks lit in the dark.
Any chance of getting the glass darkened?
I haven't tested the unlit skins for any of the other electric lights that are similar to this one.
As a comparison, the unlit skin for the grille light (lights/non-extinguishable/grill_light.lwo) is perfect.
Thanks.
-
if you cant wait its
frob_action_script <name of script>
on any of the moveable readables, with a delay in the script if you dont want the objective to trigger as soon as you pick the readable up.
I want the objective to be added when the readable is dropped. That's the only moment when I can assume the player's read it.
-
Have you been editing the .map file manually? This is one possibility I can think of where things can be moved around after the next map load.
No, I've never manually edited the map file.
I just had an incident where I added a handle to a door with one layer visible (not Default). I brought up the layers window and selected another layer to be visible (while retaining visibility on the first layer) (also not Default). When I clicked on the visibility box for the second layer, my new handle disappeared and I found it in Default.
So there's definitely something weird going on. Maybe models are getting assigned to Default in the same way as patches, and the editor doesn't move them until later.
-
And let's pretend I wrote NHAT, and not NOAT, to my utter embarrassement. I shouldn't use phonetic abbreviations...
But you should really play that one, it's very enjoyable.
Ah, but the H is silent, so you're still good.
-
NOAT => No Honor Among Thieves, GoldChocobo's and Mortem Desino's campaign.
Okay, haven't played that one yet.
-
I reached a milestone yesterday.
Apparently the size/complexity of my map no longer allows me to dmap and test in the same session. If I dmap, then map, the game crashes with a malloc error. If I dmap, quit, restart, and map, everything works fine.
Looks like there's a memory issue.
Just a note in case others have a game crash they're chasing down.
-
This feature will be available in TDM 1.02 and DarkRadiant 1.3.0, where you can have readable-related objectives, which in turn can trigger stuff.
Meanwhile there is a workaround of using frob_peers and triggers, I think the third mission in NOAT uses a setup like that in the citywatch building.
NOAT?
Thanks for adding this to TDM and DR.
-
I don't recall any fan missions doing this, so I'm asking here.
I want to add an objective after the player reads a readable. I can't find anything in the wiki about this. I can activate a script when the readable is frobbed, but I don't know how to recognize the moment when the player turns away and the readable is dropped, which is when I want to add an objective.
How do I do this?
If there's a fan mission that does do this, just point me to it.
Thanks.
-
I'm using (relying on) layers in my mapping.
I'm around 7500 brushes now, with a couple dozen layers. I'm finding that many brushes are getting moved to different layers automagically, probably when DR loads in a map. As you can guess, this is a royal pain, especially if I have to move an entire layer.
As an example, I keep the player start and a trigger together in the layer PlayerStart so I can move them around the map for testing. Yesterday I loaded my map and found that a lantern was the only thing in PlayerStart. The player start and trigger had been moved to a different layer.
I know that some mappers don't use layers, but, for me, layers make DR usable on my 5yo computer.
Anyone else experiencing this?
-
I like the rats, but I wish there was rat_clip, because they eventually get stuck on steps or ramps.
Since rat_clip is prolly a big job, can anyone suggest a way to keep them off steps and ramps? I've watched them go up steps and come back down, but at some point they can go up the same set of steps and get stuck. They just press their little rat paws against the next step and sniff around. Even walking over them doesn't dislodge them.
-
All of a sudden locked doors won't open, whether using the lockpicks, the master key, or a key specific to the door. The door handles just jiggle and give me the "I'm locked" sound. I don't even get the red flare around the item icon when this happens.
I went back a few revs of my map, and the problem occurs there also.
The only thing I've done since yesterday--when locked doors could be unlocked--was go off to play a fan mission, then come back to editing.
I started up the fan mission again, and I'm experiencing the same bad behavior using the lockpicks. They worked correctly last night when I was playing.
So it's not a problem with my map. Perhaps some global setting?
Has anybody seen this before? A forum search turned up nothing.
Thanks.
-
Sorry, I missed out part of the doom 3 shortcut. This is what the arguments should be...
+set fs_game_base darkmod +set fs_game mymap
currentfm.txt is used only by tdmlauncher. If you use that method then whenever you play some other FM then currentfm.txt will change and you will have to remember that you may have conflict.
That works now. I'll use that method so I don't have problems switching back and forth to published missions.
Thanks.
separate aas run
in TDM Editors Guild
Posted
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.