well I think you've done a pretty good job so fare and if you could remake the whole thing and fix the onos probs it would be great to have it back on servers
<!--QuoteBegin--Lazer+Nov 3 2003, 07:03 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Lazer @ Nov 3 2003, 07:03 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Ok, I'm going out now. Just leave it in my mailbox and I'll add the stuff and send it back to you tomorrow for a compile. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> I think I just crapped my pants...
<!--QuoteBegin--Umbraed Monkey+Nov 3 2003, 09:57 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Umbraed Monkey @ Nov 3 2003, 09:57 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I wonder why they used signed 16bit, we clearly cannot have negative views <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo--> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> They use signed integers because that's basically "default"... when programming, signed variables are assumed unless you specifically specify otherwise. A signed integer is just "int". whereas an unsigned one is "unsigned int"
To answer your question: programmer lazyness. Happens all the time.
Since this is hardly a 'secret' bit of the project... here's the player starts.
Sorry about crapping out and crashing... had to get to bed for various reasons. =-.-= Anyways, I'll be waiting for the RMF files and such. I just used NotePad actually to pull these out since it was oodles faster for me, then re-numbered the entities in the .map file. =^.^=
Well when I thought everything was going great, a new problem has appeared. All the starts are in and everything is ready for the finishing touches before beta 1. I did a compile without rad and as I walked around there were a few places that acted like they had a few random clip brushes inside of them. I couldn't pass certain places. It was really weird and I don't know why it was doing that. I'll send you a copy of the map in a little bit WolfWings. See what you can do. (btw it's ready for a beta compile so try and get one ready for Flayra tonight)
<!--QuoteBegin--Lazer+Nov 4 2003, 08:58 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Lazer @ Nov 4 2003, 08:58 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Well when I thought everything was going great, a new problem has appeared. All the starts are in and everything is ready for the finishing touches before beta 1. I did a compile without rad and as I walked around there were a few places that acted like they had a few random clip brushes inside of them. I couldn't pass certain places. It was really weird and I don't know why it was doing that. I'll send you a copy of the map in a little bit WolfWings. See what you can do. (btw it's ready for a beta compile so try and get one ready for Flayra tonight) <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> finally! w00t! <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html/emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif'><!--endemo-->
Let's hope we see a beta build in 2.1p <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I'm sorry to say that I don't think you'll be able to get that much map balancing done soon in the 2.1 betas, while you may be able to identify big problems from large-scale beta testing, 2.1 is just too unbalanced now to point out the finer details in map balancing. That and the fact that everybody is still getting used to the new lerk flight physics, which might change again soon, it's hard to tweak it for lerks.
Please let it be so <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html/emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif'><!--endemo-->
Lazer, for the random clip brush thing, check which setting you used in Cagey's compile tools. I've found the "smallest" setting to act odd like that. (I just did a quick compile on a room to double check that, and yes it does that.) I find it bad around angle'd geometry and detailed geometry. And if you use Nem's batch compiler make sure you've got the updated spec file because apparently there was a spelling mistake in that "precise" was spelled "percise" internally or something. I personally like "normalize" but I never really took the time to find which one works the best. Hope that helps!
The 'random invisible sticky stuff' and similair errors are probably from the zhlt_noclip-tagged func_walls and such I left in there grabbing the wrong clipping hull. Basically... it's a bug in the compile tools. I'll fix them shortly. =^.^= Cagey knows about it, it'll get addressed eventually.
Correction... those clipping errors are... um... I have no clue what's causing them. =O.o=
They seem to attack the vents mostly, sometimes making the ceilings of some vents non-existant, and other times making immaginary walls out of nowhere. =o.O=
I'm trying to narrow down the problem further to track it down.
where's cagey when you need him <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html/emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif'><!--endemo-->
<!--QuoteBegin--Lazer+Nov 5 2003, 11:39 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Lazer @ Nov 5 2003, 11:39 AM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Damn this isn't good. Maybe we should try Merl's Tools? I just want at least a beta testable map ready in the next day or so. <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Tried Merl's, tried all clipping-modes on Cagey's tools.
Trying a compile where I poured the .map file through Radiant first. Ugly, yeah, but if it solves it we know it's some kind of invalid brushwork somewhere.
Odd thing is, Alt-P in Hammer is reporting every single func_wall, func_seethrough, and pretty much EVERY SINGLE BRUSH-BASED ENTITY as being empty...
I counted. I'm getting exactly the number of problem reports for func_walls as there are func_walls in the level, and no, they're not empty. They're not invalid either.
Nancy seems to have run up against some kind of semi-magical limit of either Hammer or the Compile Tools codebase. This is some kind of Voodoo error I'm afraid that's gonna need Cagey's assistance. =-.-=
<!--QuoteBegin--WolfWings+Nov 5 2003, 05:26 PM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (WolfWings @ Nov 5 2003, 05:26 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> Same problem, same places.
Odd thing is, Alt-P in Hammer is reporting every single func_wall, func_seethrough, and pretty much EVERY SINGLE BRUSH-BASED ENTITY as being empty...
I counted. I'm getting exactly the number of problem reports for func_walls as there are func_walls in the level, and no, they're not empty. They're not invalid either.
Nancy seems to have run up against some kind of semi-magical limit of either Hammer or the Compile Tools codebase. This is some kind of Voodoo error I'm afraid that's gonna need Cagey's assistance. =-.-= <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd--> Mysterious errors suck.
At least we know that it's not compiler version or editor dependant; it implies something's goofy with either the rmf file or the export process. You might end up needing to erase those brush entities and readd them with the appropriate brushes.
Have you looked at the map file that VHE exports to see if there are actually any empty brush-based entities in the file?
More specifically... the error survives going through GtkRadiant, implying that the brushes being exported are all valid, as GtkRadiant physically can't process, load, or even interpret an invalid brush. It works with the same type of brush as the compile tools, only knowing about planes for each brush internally, and intersecting them on the fly.
Worse, the error survives every error-checking tool GtkRadiant has available, and not just those in Half-Life mode. I loaded it in in Q3A, RTCW:ET, RTCW, SoF2, and Jedi Acadamy mode, all of which have slight differences in what's available, and none of the error-checking tools found anything. I'm trying a Q3A compile, just to see if we really have found a mystical error in the file-format...
You could always try loading it into QuArK and use its error checking tools. Like Radiant it uses planes internally and it also contains a lot of different error checks.
Doing a -chart compile doesn't reveal anything fishy?
wudnt that be a bit dodgy, when i tried doing that, it screwed up my map <!--emo&:(--><img src='http://www.unknownworlds.com/forums/html/emoticons/sad.gif' border='0' style='vertical-align:middle' alt='sad.gif'><!--endemo-->
Anyway, I tried doing that and I was all excited when I found the clipping problems went away where I was having them before. They are now in other areas... For some reason I have a feeling it may relate to the poor job hammer does with the "carve" option when I make the vents. I'm gonna try removing the vent system for a bit and seeing what happens.
Comments
I think I just crapped my pants...
They use signed integers because that's basically "default"... when programming, signed variables are assumed unless you specifically specify otherwise. A signed integer is just "int". whereas an unsigned one is "unsigned int"
To answer your question: programmer lazyness. Happens all the time.
Sorry about crapping out and crashing... had to get to bed for various reasons. =-.-= Anyways, I'll be waiting for the RMF files and such. I just used NotePad actually to pull these out since it was oodles faster for me, then re-numbered the entities in the .map file. =^.^=
finally! w00t! <!--emo&:0--><img src='http://www.unknownworlds.com/forums/html/emoticons/wow.gif' border='0' style='vertical-align:middle' alt='wow.gif'><!--endemo-->
I'm sorry to say that I don't think you'll be able to get that much map balancing done soon in the 2.1 betas, while you may be able to identify big problems from large-scale beta testing, 2.1 is just too unbalanced now to point out the finer details in map balancing. That and the fact that everybody is still getting used to the new lerk flight physics, which might change again soon, it's hard to tweak it for lerks.
They seem to attack the vents mostly, sometimes making the ceilings of some vents non-existant, and other times making immaginary walls out of nowhere. =o.O=
I'm trying to narrow down the problem further to track it down.
Tried Merl's, tried all clipping-modes on Cagey's tools.
Trying a compile where I poured the .map file through Radiant first. Ugly, yeah, but if it solves it we know it's some kind of invalid brushwork somewhere.
Odd thing is, Alt-P in Hammer is reporting every single func_wall, func_seethrough, and pretty much EVERY SINGLE BRUSH-BASED ENTITY as being empty...
I counted. I'm getting exactly the number of problem reports for func_walls as there are func_walls in the level, and no, they're not empty. They're not invalid either.
Nancy seems to have run up against some kind of semi-magical limit of either Hammer or the Compile Tools codebase. This is some kind of Voodoo error I'm afraid that's gonna need Cagey's assistance. =-.-=
GJ guys good work. Hope this gets out for 2.1.
Or use plain Zoners?
See if that helps...
Odd thing is, Alt-P in Hammer is reporting every single func_wall, func_seethrough, and pretty much EVERY SINGLE BRUSH-BASED ENTITY as being empty...
I counted. I'm getting exactly the number of problem reports for func_walls as there are func_walls in the level, and no, they're not empty. They're not invalid either.
Nancy seems to have run up against some kind of semi-magical limit of either Hammer or the Compile Tools codebase. This is some kind of Voodoo error I'm afraid that's gonna need Cagey's assistance. =-.-= <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Mysterious errors suck.
At least we know that it's not compiler version or editor dependant; it implies something's goofy with either the rmf file or the export process. You might end up needing to erase those brush entities and readd them with the appropriate brushes.
Have you looked at the map file that VHE exports to see if there are actually any empty brush-based entities in the file?
The WORLD hull pretty much has no ceiling over 90% of the area though, and random 'phantom' ceilings mostly in vents.. =-.-=
Worse, the error survives every error-checking tool GtkRadiant has available, and not just those in Half-Life mode. I loaded it in in Q3A, RTCW:ET, RTCW, SoF2, and Jedi Acadamy mode, all of which have slight differences in what's available, and none of the error-checking tools found anything. I'm trying a Q3A compile, just to see if we really have found a mystical error in the file-format...
Doing a -chart compile doesn't reveal anything fishy?
p.s
I am spouting random debug advice. Ignore if you have done it.
Anyway, I tried doing that and I was all excited when I found the clipping problems went away where I was having them before. They are now in other areas... For some reason I have a feeling it may relate to the poor job hammer does with the "carve" option when I make the vents. I'm gonna try removing the vent system for a bit and seeing what happens.