ParseEntity: EOF without closing brace

blue60007 · Post by **blue60007** » Sat Mar 20, 2004 4:55 am

I Got this during the BSP stage, anyone know what the dog crap it means?? Doesn't seem to cause any problems, yet anyway....

blue60007 · Post by **blue60007** » Sat Mar 20, 2004 5:06 am

well what ever the heck it was it wiped out all my entites but luckily I had backups and even more thankfully a .bak that was saved just before it got screwed up. See my computer crashed during compiling and it might have been in a writing process so it got erased. I would still like to know what it means. Now I just have to add in a few more triggers.

tltrude · Post by **tltrude** » Sat Mar 20, 2004 6:03 am

Probably means an end quote (") was missing.

EOF = end of field?

this is what an entity looks like in a bsp.

{
"model" "*40"
"origin" "58 58 104"
"classname" "func_rotatingdoor"
"angle" "90"
"typedoor" "metal"
"spawnflags" "4"
}

So, it could also be a missing "}", I guess. I know it will kill your entities if it sees this:

"message" ""Door open!""

So, don't use quotes as a value for an entity!!!

Post by **jv_map** » Sat Mar 20, 2004 8:17 am

EOF = end of file

Most likely the last part of your .map file wasn't saved properly. Try compiling the .bak file instead.

blue60007 · Post by **blue60007** » Sat Mar 20, 2004 7:33 pm

jv_map wrote:EOF = end of file

Most likely the last part of your .map file wasn't saved properly. Try compiling the .bak file instead.

yeah that would be it. I opened up the .bak and then resaved it.

things are working dandy now

oh one quick question I'm doing a full vis compile now with -v on and if I have:

portal: xxxx mightsee: xxxx cansee: xxxx (xxxx chains)

how come they go in order by mightsee and not portal? also how does it figure the number of chains, some of then were 30,000,000

also can you tell by the mightsee number how many more there are to go?

Here's the data it gave me:

1374 portalclusters
4157 numportals
5481 numfaces

its not a problem I'm just curious.

2 hours ago it was on 78% say it had an hour to go, it would be done but now its doing rather large chains, I'd say the average is 1,000,000 before it was about 10,000 so does this mean it will take 100 times longer?

thanks

blue60007 · Post by **blue60007** » Sat Mar 20, 2004 8:19 pm

yikes!! my biggest chain yet, 117,000,000

Post by **jv_map** » Sat Mar 20, 2004 10:05 pm

A rough guess of mine is that your visdatasize is about 800000, which in my experience (though it's probably cpu depedent) results to a compile time of about 4 hours

blue60007 · Post by **blue60007** » Sun Mar 21, 2004 12:14 am

yeah its been going about 8 hours, I've put it's priority down for about 5 of those hours so my guestimate is 9 hours. Right now its on mightsee: 4419, but now its skipping 20 or so in between instead of having a dozen repeats. Is that number the portal number or the number of portals it might see?

UPDATE:: 452,069,953 chains is the number to beat!!
I hope the large number is not bad.

blue60007 · Post by **blue60007** » Sun Mar 21, 2004 4:55 am

YAY finally done, 16 hours in the making, just to find that my bank area's vis is messed up royally.

Post by **jv_map** » Sun Mar 21, 2004 8:05 am

blue60007 wrote:YAY finally done, 16 hours in the making, just to find that my bank area's vis is messed up royally.

Did you use vis_leafgroups? If so, make sure to check these out complete (simply do a -fast vis or skip vis at all) before you do a full vis compile

blue60007 · Post by **blue60007** » Sun Mar 21, 2004 5:59 pm

will the leafgroups still be calculated if I skip the vis all together? That would be great to check those out without doing a full compile!! Also those would override automatic vis right?? The compile im on now has the visdatasize chopped down to 300,000. Then I made my whole hotel detail since there are tons of windows and walls, I'll jsut do a little man vis in there.

blue60007 · Post by **blue60007** » Sun Mar 21, 2004 7:00 pm

ok vis data is down to 225,000. I think I'll do a -fast vis because before I even did vis and everything was drawn fps wasn't to shabby in most places. So I'll just do man vis wherever fps needs a bit of boosting. Also in one spot the auto vis made fps even worse for some reason...

Also are -fast and -vis_derived 1 the same thing? The both stop auto vis right? So the only vis data in the final result would be your man vis?

Post by **jv_map** » Sun Mar 21, 2004 10:24 pm

blue60007 wrote:Also are -fast and -vis_derived 1 the same thing? The both stop auto vis right? So the only vis data in the final result would be your man vis?

Nope they are completely different things I think... however I don't really feel like explaining that now (too late

) and I also don't fully understand these options either

blue60007 · Post by **blue60007** » Sun Mar 21, 2004 11:33 pm

jv_map wrote:
blue60007 wrote:Also are -fast and -vis_derived 1 the same thing? The both stop auto vis right? So the only vis data in the final result would be your man vis?
Nope they are completely different things I think... however I don't really feel like explaining that now (too late ) and I also don't fully understand these options either

Yep, I did some reading up and -fast skips vis all together. vis_derived " whether or not the vis compiler derives additional vis info from the manual vis. default is 0. 0 means vis compile will be slower since manual vis data is added after auto vis data. 1 means vis is faster and lower runtime poly count, but erroneous no draw could result from incorrect manual vis data."

Thats straight out of Radiant.

I think vis_derived 1 means it calculates man vis first then does auto vis around any targeting vis_leafgroups, rather then do auto vis first then sticks in any man vis afterwards, thus increasing compile time and then deleting the autovis in areas with manvis. I think I understand it now.

At any rate I removed a very problamatic building and cut portalclusters, numbportals, numfaces, and visdata by about 12 times!! My compile was 8 times faster at 2 hours. My visdata is about 25,000 which is a boatload more reasonable. I bet it was the odd angle of that building.

Post by **jv_map** » Mon Mar 22, 2004 8:24 am

I guess that's right about the vis_derived option, but -fast vis doesn't just skip all vising (I know I've said it did before

).

The compiler combines the vis leafnodes in your map in vis clusters, and using -fast vis the compiler only checks visibility between those clusters. I found that in some cases, this can still lead to considerable fps savings with a compile time of only a few minutes (and a visdatasize of 1.6 MB)