Newbie DarkRadiant Questions

[RPGista]

I havent opened Arcturus's map yet but the reason you cant see the terrain model could be that first you need to point DR to the mission's folder, so it will load the assets on top of TDM's ones (a bit tricky, its explained on the startpack map wiki article, on the "project" section).

 

Either way, I also cant see a reason why the obj export wouldnt work, my only suggestion right now would be to try loading the model on another program and if that works, export again and see if you get a better result (I would try Wings3D, Hexagon (still free I think) and TDM's Assimp ASE exporter, here on the forum).

 

Good luck with your mapping experiments, btw, and in my opinion, focus on that first department - story/plot. Not only it is the most fun and creative part, its also what makes the mission unique.

Edited September 29, 2012 by RPGista

[SeriousToni]

No you're not alone. Doesn't really work for me in 3ds max too

[Obsttorte]

hello,

 

i have a strange problem here which i don't understand

 

i had a map with AI and patrol waypoints added on the lower floor

everthing worked fine

than i added some guards and patrol waypoints to the upper floor and now the game crashes

when i try to load the mission

the only error message i get is the windows prompt "doom3.exe doesn't work anymore, nanananana"

dmapping / AAS runs without errors

 

any idea what might be wrong

[Sotha]

Tough one as we don't get an error message.

 

Please verify it is the added AI. Make a separate copy of the map, delete all AI and test if it crashes. If it still crashes delete patrol nodes and check if it crashes.

 

I also had once this kind of odd crashing, but it went away with small changes. Don't remember what I did though.

[Obsttorte]

i just deleted th ai

i can start the map now, but when i move the mouse it crashes

very strange

 

EDIT: ive put the fm in the state where it worked by deleting the ai and paths ive added afterwards, the game still crashes

 

AAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRR

Edited October 2, 2012 by Obsttorte

[Radiant]

You may have a look at it in a texteditor at the AI parts, paths, etc. Maybe just a {} or " is missing.

What happens if you delete your aas, cm, etc. files beside the mapfile, compile and start it?

Try to compile your map with these parameters:

dmap noflood nocurves noaas noCM noFragment noopt YOURMAPNAME

Edited October 2, 2012 by Radiant

[Obsttorte]

What happens if you delete your aas, cm, etc. files beside the mapfile, compile and start it?

 

already tried this

[Sotha]

This problem has the word 'bizarre' painted all over it.

 

So you are absolutely sure you did not build some strange geometry before the crashing started. That you only added AI.

 

Do you get strange errors during dmapping? (After dmapping, open the console and scroll the last rows if there are errors.)

[Obsttorte]

So you are absolutely sure you did not build some strange geometry before the crashing started. That you only added AI.

 

Do you get strange errors during dmapping?

 

nope

 

EDIT: OK, so I just reloaded and old snapshot and dmapped it, it works

 

but what i recognized is, that with the working version the AAS-build only takes 4 seconds, while in the not-working version AAS takes 25 secons approx., although the only difference between both files are three guards and a couple of path-corner path-wait entities

Edited October 2, 2012 by Obsttorte

[Sotha]

Can you upload the .map somewhere? I could test if it works on my system?

[Obsttorte]

here ya go

 

https://www.yousendit.com/download/TEhXcXl0NEhVVG1HR3NUQw

 

thanks in advice

[Sotha]

Don't thank me yet...

 

Dmap was okay. D3 crashes in the loading screen when I try to launch the mission.

 

It is not obvious why.

 

During dmapping I see this kind of error:

WARNING: idCollisionModelManagerLocal::ChopWindingWithBrush: primitive 4 more

than 128 windings

WARNING: idCollisionModelManagerLocal::ChopWindingWithBrush: primitive 59 more

than 128 windings

WARNING: idCollisionModelManagerLocal::ChopWindingWithBrush: primitive 75 more

than 128 windings

WARNING: idCollisionModelManagerLocal::ChopWindingWithBrush: primitive 75 more

than 128 windings

 

I've no idea what these are. I've never seen this kind of error in my maps. Maybe it is the culprit? What if you check the area around these primitives for errors. Try to rebuild it if necessary. Try to get rid of that error? I think you can check these 'primitives' with map/find brush and the brush number should be the primitive one. I checked the primitives but they were so simple I cannot understand why it complains about them.

 

Finally, I saw you had "wander 1" spawnarg on multiple AI's. I've never seen such a spawnarg. Are you sure it is supported? Can that cause the error?

 

That's all I can do, I'm afraid... =(

 

EDIT: The wiki says nothing about a wander spawnarg. What if you remove that from all the AI?

[Obsttorte]

i ve set the wander spawnarg because the description said, that the ai would wander around if so, but that was long before the error accured

same with the primitives, this error occures since some time (I dont know for sure how long)

 

ive now reloaded a snapshot and continue on from there

 

i guess i massed up something with the waypoints or fail-selected another entity and dragged it somewhere it shouldnt be while moving around the paths, i dont know, doom3 error feedback is really ...

 

but thanks anyway

Edited October 2, 2012 by Obsttorte

[Fidcal]

I had that error long ago but can't remember what I did. I found a note I'd downloaded from a google search at that time:

 

 

During the compiling of a Quake 4 MP map the following error may crop up;

 

WARNING : idCollisionModeManagerLocal::ChopWindingWithBrush: primitive [n] more than 128 windings

 

Where [n] is a number associated with the corrupted brush (primitive)

 

A : This happens for a similar reason to when the error crops up during Quake 3 map compiles (see below)

 

As this error can happen with very large brushes try cutting large brushes into small segments.

 

This is the link. For some reason I couldn't insert it above.....

 

http://www.katsbits...._from=&ucat=15

[Sotha]

Yes... I observed you had a lot of worldspawn brushes intersecting near those areas... But surely that can't cause the crash?

 

I am not sure what exactly is officially recommended, but in my view a TDM worldspawn geometry should be as simple and boxy as possible. The details are in func_statics. That is, only the walls, ceiling and floor of a room is worldspawn: the parts that seal against the void. The rest, details, support beams, windows, etc are models or func_statics that have to be monsterclipped.

 

Overall it is a good idea to avoid intersecting brushes as it is easy to get ugly z-fighting mistakes.

 

Is it possible that if you leave too many brushes as worldspawn at some point you will get a crash? At least leaving every support beams into worldspawn in a room would generate a lot of useless tris.

[demagogue]

It sounds almost like a big brush being intersected with countless little ones. Anyway nine times out of ten, I'd wager crashes like this one way or another are just because of messy brush work. Try to keep brushes snapped to the grid, avoid grid sizes under 2 or 4, avoid brushes intersecting at odd angles, especially if not grid-snapped, avoid brush splinters, tiny overlaps, and tiny cracks at all costs, etc, etc... Remember brushes are mostly just to seal the void & leafs, blocky walls so there are no gaps. Leave the detail & border work for func_statics if possible. That's just my guess, but I wouldn't doubt it's the problem.

[Obsttorte]

these warnings doesn't seem to cause the crash as i have them and the map runs fine

i think i messed up the map with some keys attached to some guards

i copied the keys and maybe forgot to change the attachment on one of them, i dont know

by now i readded the patrols and guards and everythink is ok, so this key-think is really the closest guess

 

btw. i have some worldspawn, but the most complicated i think are 8-sided cylinders or so, of whom i havn't too much

i now have about 4000 brushes, 2000 patches and 2500 entities

the oddest angle i have is 45 degree, what should be ok i think

most of the ceiling and details are func_statics

i guess at least 90-95% of my brushes/patches are snapped to grid on gridsizes 8+

[demagogue]

If the only difference is the AI and time it takes the AAS to compile (AAS is the pathfinding data), then that's pointing to some error with the pathfinding. Maybe demapping doesn't compile some pathfinding if there are no AI that can get to it, and adding those three AI borked something that's been latent there for a while.

 

Anyway, common solutions to pathfinding problems are monsterclipping difficult areas for an AI to walk on or simplifying "ground" brushwork that you don't want to monsterclip (but not only floors, but could be non-monsterclipped roofs, etc, anything roughly horizontal to a certain steep angle that AI might conceivably walk on.)

[RPGista]

Well, that's the thing about the learning process - I have at least 5-6 alpha versions of my map sitting around, after I reached some dead end in one way or another. It is a good idea to build in a "clean" way so you can later scratch entire areas that might be problem-prone a bit easier.

 

PS: Yes, another common error you get is when you have an AI pathfinding "leak" - when you enclose a section of you map inside a big box for testing, if you dont also isolate the AI walking area of your section from the box void, you'll get an error.

Edited October 3, 2012 by RPGista

[Obsttorte]

the aas compile time difference wasn't there anyway, thats my fault

it took longer cause the game crashed and i had to reload it

i have this time difference also now

on first aasrun it takes about half a minute

the later ones take only four seconds

pathfinding seems to work fine

i have ai in the entire map and nothing seems to be broken

quite good i have snapshots made every two minutes, saves a lot of work, if somethings messed up

 

and just for protocol, the problem doesn't accur anymore, so pathfinding or brushing wont do the harm

i bet one something screwed up with the entities, so lets see if it happens again until the map is finished

Edited October 3, 2012 by Obsttorte

[grayman]

I tried to debug this crash, but it happens in the engine and I'm unable to build a debuggable engine.

 

You could try the brute force method of divide and conquer.

 

Split your map in half by embedding half in a single large caulk brush. Build and test. If it crashes, divide the "un-embedded" half of the map in half and repeat this process until the map runs. The problem causing the crash will be in the most recent section of the map that you embedded in caulk.

 

If this process causes errors related to AI or any other entities, you might try it with all entities removed. Just leave your player start.

[Obsttorte]

ok ive also added all the keys now

again, i think i messed something up as i copied a key that was attached to aguard and move it to another guard

maybe i just set som spawnarg wrong or i forgot to delete the bind spawnargs on the copy i made of the key, that was not supposed to be carried by a guard

[Obsttorte]

ok here is the next problem

i created a func static for an absence location

the problem is, if i set absence_location on the objects that should not be moved away, the terrain between the object and the func static becomes inaccessible

in detail it seems that the area where the object was seems to be unaccessible

if i delete the absence_location spawnarg, the problem dissapears

 

EDIT: OK, i solved it by moving the absence location func static

 

but i think its strange that you cannot cross the border between the absence location and the objects location

Edited October 4, 2012 by Obsttorte

[Obsttorte]

it seems the problem still occurs

if i move the absence location func static as mentioned above, the problem dissapears as long as i only rebuld the AAS

if i dmap again, the problem is there again

 

so maybe its a good idea if i explain what exactly ive done

i created a brush with clip texture on it and converted it to func_static

than i have some movable crates in front of an hole and give it the spawnarg that let AI get suspiciuos if the crates are moved away

i set absence_location to the name of the func_static and added the average distance between the crates and the func static as a spawnarg to the crates (forgot the exact name)

the func static is not within the reach of the player and is quite tiny (4x4x4 i think)

the sense is, that if the crates are moved away AI gets suspicious(as they could see the hole), but on the otherside the player don't has to put the crates back in the exact order they were before after he trespassed the hole

 

the whole thing works pretty nice, the only thing is this blocking problem i have no idea where it comes from

[grayman]

You're using the clip texture, which blocks AI?