 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Hey there,
My next map is approaching completion. I'm working on the beta build and just recently encountered a few errors when compiling that seem to have been alleviated with the use of bsp2 format. The first time unfortunately I did not record entirely but it stated something such as: Error: "...to many vertices... try compiling with bsp2..." Now this was most certainly not a leak. The map is sealed, there are no warnings of entities exposed to the void, no pointfile, etc. and using bsp2 fixes the problem. When I compile now with bsp2, the map compiles with vis and all is good. However, I cannot replicate the original error message. If I remove -bsp2 the compiler reports error: "13:C:projectstyrutils-ericwqbspsurfaces.cc:316: Q_assert<v1 == edge->v[1] & & v2 == edge->v[0] failed." Using bsp2 gets rid of this error as well and all is good. Now, I'm not sure what this error is, but the first message was a lot more useful and allowed me to fix the problem on my own, which is great. Maybe this error message should say something similar. Thanks The error reads:
"13:C:\projects\tyrutils-ericw\qbsp\surfaces.cc:316: Q_assert<v1 == edge->v[1] & & v2 == edge->v[0] failed." The current code to detect if bsp2 is needed isn't very good.. I think those crashes just mean that the map needs the -bsp2 flag, but qbsp didn't detect it properly. Improving that is on the todo list.
Mostly a bug fix update:
https://github.com/ericwa/tyrutils-ericw/releases/tag/ericw-v0.15.11 - light: add "_sun" entity key to configure sunlight in an entity instead of worldspawn. More than one "_sun" entity is supported. - light: add "_falloff" light entity key to configure light falloff in map units. Only supported on linear (delay 0) lights. - light: add "_spotlightautofalloff". - light: fix light cutoff on curved surfaces - light: adjust -soft to fix regression in 0.15.10 - qbsp: add "_mirrorinside" key for mirroring the outside faces of bmodels so they are visible from inside. for func_water, or func_illusionary fences, etc. - qbsp: fix CSG issue with overlapping off grid brushes - qbsp: fix HOMs introduced in 0.15.10, which were caused by an attempt to fix leaks-through-solids in 0.15.10. To re-enable the buggy code that may fix leaks through solids but add HOMs, use "-contenthack" Thanks for everyone who reported bugs and m-x-d for the contributions to light :) Btw - I want to rename the project at some point, any suggestions? something that doesn't have my name in the title, haha. Just call it tyrutils-0.16 to confuse everyone and annoy tyrann (if they're still alive)
I'll have a look to see if the bugs are fixed for me yet, fingers crossed :) Also, what's the purpose of _sun on an entity? And the purpose of having more than one? Lame Name ideas:
Wizann (ericw the wizard + Tyrann) Compyre Luxpiler Luxspire Map2Bsp (lame i know) Quislitvis I had been using an older light it seems for the black faces bug. I'll let you know if I run into anymore bugs. Yeah - it's time to bump the version to 0.16 soon. I don't want to use "tyrutils" since that makes it sounds like tyrann endorses the tools, I think I have a good name idea though.
I'll have a look to see if the bugs are fixed for me yet Thanks! Also, what's the purpose of _sun on an entity? And the purpose of having more than one? Just convenience, really - figuring out _sun_mangle is a pain; this way lets you target an info_null to set the sunlight vector. It doesn't enable any new features that you can't do with the worldspawn keys, currently. However, there are some things that would be easier to do with sun settings on entities, one that comes to mind is having a targetname to make them toggle-able (you could totally fade the sunlight with QC if that was implemented.) Having more than one sun entity is for when your skybox has 2 suns on it. :D Has anyone done this name yet? I've used a lot of "Yet Another X" software over the years.
Other ideas: QTOOLS - already used for a few projects sadly, but not quake ones. func_compiler - ??? ericutils - because I know you mentioned not wanting to, but it's TRADITION, DAMMIT! W(X) - WQBSP, WLIGHT, WVIS etc. Another name reference but a subtle one. There have been a lot of different tool packages over the years. Most of them have been branded with their author's name, sadly. It's hard to be creative about something so clinical. I can't pretend I'm an engineer or anything, but the urge to come up with cute names for things was irresistable, so I spent a few minutes doing a little research.
Your toolset is aimed at letting people prepare their architectural designs for a Quake, so how about "Strand" or "Tendon"? I tried working in some reference to Tuned Mass Dampers at first, mainly because I like the phrase, but nothing catchy or meaningful was forthcoming. Maybe somebody else can run with that. ShadowLight
Believe, BeLieVe or Be_Lie_Ve (Bsp, Light Vis) Quandary (because you have so many options in LIGHT utils!) BrownBrush (bsp)
BrownEye (vis - eye, visibility, geddit?) BrownStar (light - starlight I guess) "func_compiler" does have a certain charm.
Or maybe "qompiler" although perhaps that's too vulnerable to typos? Trying to think of other terms besides "compile"... "quakebake"? One I thought of was "arcaneutils".
"ericw-tools" is nice and straightforward though. "func_compiler" is good, disadvantage is it's hard to say and it would be hard to read without the underscore (e.g. funccompiler).
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |