Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on January 18, 2008, 10:03:37 am
-
This is RC2 - please attempt to make it crash - this with any luck will be the LAST RC BUILD BEFORE RELEASE!
RC2d 2008-1-31 Exec: http://ferrium.org/media/pcs2-rc2d.zip
DLL Pack: http://ferrium.org/media/pcs2dlls.zip
PS: if you PM either bob and I about a bug, but you don't put it in Mantis, your bug won't get fixed - same goes for posting it in a thread without putting it in mantis.
I'm starting to write the installer :D
Build Updated Jan 31, 2008
-
apparently the "inverted bounding boxes" thing was still around... and goober managed to help me replicate it.. so it's fixed now
also added a new feature to COB hierarchy
if you attach a light named "detail" to a child of the main lod that child becomes the base of a lod itself - I updated the COB exporter to use this as well. Now when you open a POF, save to COB you can immediately open the COB and have the same hierarchy :P
-
that sounds like a real time saver. would make model reverse engineering easier.
-
RC2a build uploaded - contains the bounding box inversion fix.. now if you open a model and see an inverted bbox in PCS2 then you can just fix it by hand and save and it should be fixed.
-
I am right now laying on my ass stir crazy because I want to work on this but there are no bug reports that I can act on.
come on people, surely there is something wrong somewhere.
-
um, what's the link to the mantis?
-
PCS2 Mantis: http://ferrium.org/mantis/
:)
-
thank you very much for your submissions, they are both COB related so it's Kaz's code and I'm still out of luck for stuff to do, but I'll try and gather as much information about them as possible to help him, which will give me SOMETHING to do for a little bit at least.
-
uploaded a new version, it should not crash for you anymore, but there seem to be a few other issues with the imported file.
-
i think theres a problem with moi import, but i might just be imagineing the whole thing. il mantis it when i confirm that its not a hallucination.
*edit*
no it seems i was hallucinating. is that a moi calculator, i thought that wasnt supposed to be implemented till after 1.0 :D
-
ok this is not so much an error as it is a question. Is the "POLY >20" deal a thing that PCS 1 just hated, or is that a strict requirment for the game engine itself that lines must have 20 or less verts per line?
if its the former will PCS 2 be more forgiving with this?
i've been trying to avoid this hideous beast... but more polies makes it pop up more, and hunting them down is tedious, it beats hitting the triangulate button though.
-
Interesting... The Battlecruiser mesh I posted still has no textures or data in PCS2 from COB, but when you open the pof made by PCS1 it's all there in PCS2, Data and textures...
-
is there a bug report on this issue?
ok this is not so much an error as it is a question. Is the "POLY >20" deal a thing that PCS 1 just hated, or is that a strict requirment for the game engine itself that lines must have 20 or less verts per line?
if its the former will PCS 2 be more forgiving with this?
i've been trying to avoid this hideous beast... but more polies makes it pop up more, and hunting them down is tedious, it beats hitting the triangulate button though.
it is a game engine requirement, but there should be code that hunts down and corrects V>20 polys for you. are current PCS2 builds giving you problems with polys that have more than 20 verts?
-
Could someone explain why this is happening?
(http://img.photobucket.com/albums/v356/Shodan_AI/Extras/bad.jpg)
edit: this doesn't occur if I build using PCS1
-
eh, is it setting a glass texture to the whole thing?
(is there a bug report?)
-
Hmmm now it works... :wtf: oh well..
-
Hmmm... Is PCS2 supposed to be able to read High-Poly models? :confused:
I've been trying to open a model with ~58000 polys and it seems to take forever to load. It doesn't exactly crash, however. It just freezes up.
-
yes, but our smoothing algorithm is n^2 complexity due in part to our geometry format, extremely high poly counts will likely cause unbelievably long loading times.
this is one of the things I intend to address after the release.
-
~58000 polys
is too high even once we've optimized the hell out of PCS2 - FS2 will kill you in your sleep
-
though technically it is supported.
-
That's odd actually - did something major change about that smoothing algorithm? I have an old screenie (http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/PCS2vsSB1.jpg) of a 63 000 poly model that opened up and rendered just fine in an earlier version of PCS2, but now just hangs forever at the 'loading textures' stage.
I'm not really concerned at this stage - that was just a test model, but it is odd how it's stopped working.
-
was it smoothed?
-
Originally, no not as far as I remember.
Would the newer versions be trying to calculate smoothing upon load or something?
I'll do another test with the same model in PCS2 and see if I can come up with anything more useful, but if not I'd say don't worry about it for now. :) That test was my first and last experiment with the pof exporter though rather than something I'd converted with those early versions of PCS2 so I doubt it would have been terribly stable anyway.
-
the newer versions would be trying to calculate smoothing upon load. :nod:
and that's where the n^2 complexity kicks in. for every vert in every polygon, you need to look at every other vert in every other polygon and compare it's position, if it is in the same position you check it's normal if the normal is less than the auto-faceting angle you add them together, after checking all verts of all polygons you divide the normal by the number of normals that were within the auto-facet angle. then you start on the second vertex of the first polygon :)
you can see how this gets slow fast.
I actually have a geometry class partially implemented that should hopefully allow this to be N complexity. though the class it'self is extremely complex it allows for a number of algorithmic possibilities that will hopefully allow a running tab of which polygons are neighbors to which other polygons, the only problem with it is it has a lot of interdependencies. but it should allow for a minimum of memory usage and quick development of index buffers. I am worried it might not prove to be fast enough though, in which case we will just use a simplified version of our current geometry structure, which uses indexed positional components, it won't remove the N^2 complexity, but it will make the scale of it a lot smaller.
-
What if I don't want it to recalculate smoothing data upon load (from POF) ?
-
it's only an issue with COBs.
-
Hmm, in that case it just takes a whole lot longer to load complex POFs than the RC1 version did. What sorts of geometry checks are performed on POF loading ?
-
Ok I might be missing something here, but that n² complexity would only apply on a per subobject basis wouldn't it? Maybe even just on a 'groups of linked verts' basis? (As obviously, you can't possibly smooth over disconnected verts so there'd be no point checking them)
I ask because it currently appears to apply to the whole polycount. I have a 40 292 poly version of the same model, split into 3 subobjects of 13 506, 11 626 and 15 160 polys. The Lucifer with 12304 polys loads in 20 seconds. Logically, if PCS2 were applying the n² complexity on a per subobject basis it should take approximately 1 minute to load right? (3 sets of approximately 20 seconds)
Currently it takes 3 and a half minutes just to load the POF, which is a painfully long time. I just saved the 40 292 poly model from PCS2 and reopened it - it took the same length of time even though it should have already calculated the smooth data and everything already.
Oh - you say this smoothing calculation is only supposed to happen on COB conversion? What's happening on POF load that's taking forever then? :confused:
-
I'm not sure off hand, POF loading should be fairly straight forward.
...:\
-
I just opened a 63k sphere, it took about 30 seconds. :wtf:
do you have any clue as to what it is doing? (i.e. it's not loading a texture that takes two minutes it's loading subobjects)
loading from POF should be roughly linear, as it isn't doing much other than loading (cobs it has to do all sorts of complex things as discussed earlier)
-
Oh! Heh, nevermind - apparently I'm an idiot. :D
I re-downloaded your latest sig build to be sure I was dealing with the latest one, and apparently I wasn't. The Jan 18th build loads even a 230k poly test model in seconds, so I guess whatever it was, it's sorted now. :)
-
HAZA! :)
BTW for those of you interested N^2 complexity basicly would put a limit on the number of polygons somewere in the range of 6000, it isn't a hard limit, but it means for every poly you add that is another N things you have to do so somewere around there it will probably start takeing time in the minutes to load.
in the example of 6000, it means that for each poly you'd need to do 6000 things, if you add one more it means you'd have to do 6001 things for each of the 6001 polys, for each thing you add it increases the work to be done, not by one but by the number of things you have. so it's N*N or N^2. for 6000 that would be 36 million steps. now this isn't a simple number of operations here it is only a rough aproximation of how big the problem is, in reality its 36 million * some_scalar, because each step as a (semi) fixed number of substeps.
so when ever you hear someone say it's order logN or its n^2 complexity or that would take K^N time this is what they are referring to.
-
Hmm - one thing though: the latest RC2 build Kaz posted is also dated the same as your sig build, (hence my confusion :p ) but your sig build loads POFs just fine while Kaz's RC2a takes ages.
-
odd
bob what haven't you commited? :P
PS: 230k model
(http://icanhascheezburger.files.wordpress.com/2007/01/1159434782588.jpg)
-
hmmm... that's not good...
there isn't very much difference between them, I wonder what the hell is going on there.
there are no files marked as modified. :nervous:
the 230k model is probably just for testing the limits.
-
PS: 230k model
(http://icanhascheezburger.files.wordpress.com/2007/01/1159434782588.jpg)
Obviously you forget old holy snowballs all to easily. :p
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/PCS2/HolySnowballsBatman.jpg)
-
RC2a build uploaded - contains the bounding box inversion fix.. now if you open a model and see an inverted bbox in PCS2 then you can just fix it by hand and save and it should be fixed.
:nervous: :nervous: :nervous:
Kill me if I'm wrong but I still get the bounding box issue with the Shivan Comm Node. Mantised as 0000049 (http://ferrium.org/mantis/view.php?id=49)
-
does the build you downloaded read RC2a or RC2 in the title? it's possible that i may not have uploaded the fix (built debug instead of release)
-
it is a game engine requirement, but there should be code that hunts down and corrects V>20 polys for you. are current PCS2 builds giving you problems with polys that have more than 20 verts?
just a message telling me about dark days brought about uncorectable geometry and its negative impact on children. it makes me feel guilty really and i have to reflect on this for a few miuntes. but then if i am persistant and hit the OK button enough, then the sun comes out and all is well. i tried something different in modelling technique to keep polies low, and payed for it dearly with a lot of >20 lines.
so i dont know if this is just how the >20 correction process goes or if its a glitch.
-
more likely you have concave and/or non-coplanar polygons somewhere, more than 20 points it should handle without blinking. silly error messages like that are put in places I don't ever expect them to be seen (it's sort of a joke about error messages that don't actually help you understand what is going on. they are put into places that I don't think you can do anything about the error (ie it's an algorithm error rather than a data error), I figured bizar messages would be more likely reported, and thus allow me to fix them). that one is getting seen a whole lot more than I was expecting, so I guess my filtering algorithm isn't as solid as I thought. I guess I should have it report model name and approximate location of the polygon.
keep in mind this is relatively low level error, it's actually more of a warning to be honest. you should be ok if you ignore it, just try not to let the children get to you.
-
:lol:
children = no worrys
gotcha!
-
does the build you downloaded read RC2a or RC2 in the title? it's possible that i may not have uploaded the fix (built debug instead of release)
Please check the mantis report. I have RC2a in the title...
-
I just uploaded a new build, it doesn't have the more informative error messeges, but it might have the bbox issue resolved. we made a bit of a design change about some header stuff, and the short story is radius and bbox values are now read only, because it will recalculate them on POF save, and the way I'm doing it involves useing the raw BSP data at the last possible second, so if the model looks right the bbox and radius should be right, but give it a shot, make sure colision detection still works and all that.
-
I know it probably has nothing to do with PCS2, but when the FSOpen debug build cried death and destruction whenever I tried to load a specific model I figured something must be wrong. So I opened up this model in PCS2 and tried to save again as pof. and PCS2 immediately crashed. I'm no modeler, could anybody take a look at it?
EDIT: Ugh, this thing is a giant fly-through-face. Collision detection seems to be totally garbled with this model.
[attachment deleted by ninja]
-
I just uploaded a new build, it doesn't have the more informative error messeges, but it might have the bbox issue resolved. we made a bit of a design change about some header stuff, and the short story is radius and bbox values are now read only, because it will recalculate them on POF save, and the way I'm doing it involves useing the raw BSP data at the last possible second, so if the model looks right the bbox and radius should be right, but give it a shot, make sure colision detection still works and all that.
Info updated in Mantis 49 (http://ferrium.org/mantis/view.php?id=49).
Basically your new build:
- Still changes the boundary box of the header.
- There are a lot of warnings about inverted boundary boxes in SUBMODELS
- BUT the model warning has dissapeared.
-
Yeah.. in the model the 'non complaining' BBox seems to be of type
BBox Min: x-min, y-min, z-min
BBox Max: x-max, y-max. z-max
While submodels do not seem to complain if they are of type
BBox Min: x-max, y-min, z-min
BBox Max: x-min, y-max. z-max
In the complaining comm node those were for some reason apparently swapped...
-
yeah.. that's just a coordinate space problem we have to track down
-
So, what causes the file size increase when a model is loaded and then immediately saved?
EX: Cargo03. When correcting the inertia issues on it, it practically doubled in size when save in PCS2. I used ModelView32 to correct it. I'm not complaining, per se, but I'd like to know (if you would, please) where and/or what is causing for additional data to the model.
-
So, what causes the file size increase when a model is loaded and then immediately saved?
pcs2's bsp compilers produces better collision meshes, as well as having SLDC (Shield collision data) - this makes bigger models.
you should NOT EVER use modelview's POF editing capabilities... EVER
-
you should NOT EVER use modelview's POF editing capabilities... EVER
O rly? :wtf:
It's served the community pretty well ever since it was first introduced ~8 years ago...
-
Hmm. Well, I haven't seen any benefits yet that encourages one over the other.
Suppose I'll just hex-edit Inerta values for models lacking them, now that I know where they are.
Can you support with a definitive statement or example why one should "NOT EVER" (which I almost read as NOT EV4R) use ModelView32?
-
it can give bad collision detection.
-
Never use modview to convert from COB to POF. With anything more complex than a primitive shape it will almost certainly screw up collision detection one way or the other. That said, the only reason not to use it for POF editing is if your model has glowpoints - because modview doesn't recognise them, it just strips the chunk off upon re-saving.
Other than that it does absolutely nothing to damage the stability of the model.
However, PCS2 now does almost everything modview did and a whole lot more besides, so you really should be using that instead and submitting bug reports if you find problems. ;)
-
modelview will also strip SLDC which is a new chunk that PCS2 introduces
his issue was that PCS2 makes models that are larger - that's not a bug
as for why one should NEVER use modelview for editing - already been stated:
Trashes collision data
Trashes GLOW
Trashes SLDC
Really once PCS2 is out nobody should even have modelview installed - it's flat out obsolete and Bob and I have been trying to make sure PCS2 does everything it does on top of everything else so we can finally put it in the grave.
The PCS2 NSIS installer register's PCS2 as the default program to open POFs
-
Don't forget the massive memory leak that can occasionally corrupt the open pof upon the eventual crash of the application.
-
Err, ok that one I've never seen or heard about. I knew about the memory leak that got much worse on complex models, but that only ever caused me to restart the app every once in a while. It never crashed for me and certainly never corrupted a POF.
In nearly everything it could do, modview was the preferred POF editing tool for years and it did it well.
-
the internals of modelview were always a lot more hackish than PCS1 - where as PCS1's interface was hackish because A) i suck at writing UIs B) i used Win32 API
PCS2 is good inside and out thanks to the help from Bob
-
Anytime I went into POF editor on Modelview, if the memory leak _had_ been somewhat slow before, it grew massive as soon as I started doing anything. Just open up taskman sometime and watch what happens. Rotate a model, highlight certain fields, just click around, and you can just see the memory going up and up and up. It usually crashed for me sometime after eclipsing 100MB of ram. On a larger model that happens rather quickly, especially while editing. I was using it one day just to line up various pof elements, and then copy the numbers into PCS1, and all of a sudden, it crashed, and the file had been corrupted and I couldn't reopen it with Modelview. I forget if having a copy opened in PCS helped me there or not.
-
This (http://pages.sbcglobal.net/joey.wong/test2b.zip) POF generated with PCS2 causes the game to crash as well as PCS2 when I try to reopen it. Could be something I did though.
-
It opened just fine in Bob's sig build from 1/21.
-
Good answers. I like them. Well, once the inverted boundary boxes issue get's resolved, I'll be more than happy to open and save every model I have with it.
-
didn't bob catch the part of that which i missed?
-
I don't know, but Bob's sig build from 1/21 has been seemingly working better than your RC2a build. It seems to be crashing opening a lot of models that his is still handling.
-
give me one of those models i've never been able to reproduce these crashes
-
http://www.hard-light.net/forums/index.php/topic,51708.0.html (http://www.hard-light.net/forums/index.php/topic,51708.0.html)
I think the basestar in Raptor's Original BSG pack was one that was crashing it. It opens and saves fine in Bob's build, but I think it crashed yours, or was taking so long to open I assumed it had crashed. On another note, the Protector and CylonAF models in that pack saved fine with Bob's build, but have some holes in the collision meshes, not sure if that's inverted BBox related or not. Specifically, large chunks of the pods and I think the nose of the Protector, and the rear section of the CylonAF. Probably just model errors though, but Bob's fixes had improved bad model handling so much that I thought he might be interested in seeing these two.
-
New RC2b build posted
as far as i can tell the bound box problem should be resolved
oh.. you should recompile from cob to make sure an model suffering from that is completely fixed
-
The new RC2b build seems to do weird things to collision detection. I was working on a model today, and when I compiled it with RC2b, it had gaping holes in its collision detection, even after purging the BSP cache several times and converting to PMF and back again. I tried it with the RC1 build and it worked fine on the first try.
-
bob has been playing with BBox'es .. so talk to him
-
~58000 polys
is too high even once we've optimized the hell out of PCS2 - FS2 will kill you in your sleep
I've had no problems with multiple >10000 poly models on screen.
But then again, I have a GeForce 8800 GTS.
-
Uhh ... 58000 is greater than 10000. Do you mean 100000?
-
Uhh ... 58000 is greater than 10000. Do you mean 100000?
Well, get a few of them together, some fighters, and a couple of installations, and boom, 60000 polies.
Edit: One of the ships was 25000, one was 21000, and one was 11000, and one was 9000. That's over 60,000 polies not counting the installations (>1000) and fighters (500-2000). Now just think of all the textures/texels being rendered with four caps, three installations, and four wings of fighters.
-
Just tested with RC2b and Comm2S-01.pof.
:( :( :(
No way, PCS2 still "corrupts" the original pof which is "Boundary-error" free.
See PCS Mantis 49 (http://ferrium.org/mantis/view.php?id=49) for the full info.
-
this is maddening.. was the file already suffering from inverted bboxes and you just opened the pof and resaved, or did you convert from cob over?
[edit]
i think i'm a ****ing moron, i think i have it figured out
[e2]
rc2c build posted
-
this is maddening.. was the file already suffering from inverted bboxes and you just opened the pof and resaved, or did you convert from cob over?
Kazan, I'm not a modeler at all so I only do VERY, VERY basic pof editing. ;) ;) I don't even know what a Bounding Box is ... :wtf: :wtf:
As posted in the mantis report:
- I open Comm2S-01.pof from DaBrain's MediaVPS 3.6.10. beta edition. (Model attached in PCS Mantis). This model doesn't make FS2 to complain about this "Inverted bounding box" issue.
- Then I just save it again. Then the saved model makes FS2 complain about it. And I also see that the Header >> bounding values have changed in PCS. BUT if I want to see these bounding box value changes, I have to reload the model, because just after saving, PCS2 still displays the original values.
(I know I can seem a bit lazy, but as I posted before, please test it yourself because with my little knowledge I really don't know what the hell I'm exactly doing. Maybe even the original Comm2S-01.pof is FUBAR because of some reason :confused: :confused:)
EDITED
I've just seen your edits. I'm going to download and test rc2c
Stay tuned...
-
(I know I can seem a bit lazy, but as I posted before, please test it yourself because with my little knowledge I really don't know what the hell I'm exactly doing. Maybe even the original Comm2S-01.pof is FUBAR because of some reason :confused: :confused:)
i ask people who know how to replicate the bug to test it because this bug has been eluding me like a mother****er
-
Just tested with RC2c.
And at least the main model warning has disappeared. But there's still a lot of warnings about submodels. (Full info in PCS Mantis)
-
Just tested with RC2c.
And at least the main model warning has disappeared. But there's still a lot of warnings about submodels. (Full info in PCS Mantis)
try again, this time purge the BSP cache
-
try again, this time purge the BSP cache
IT WORKS !!!! :yes: :yes:
Now there are no inverted bounding box warnings. Just two comments (see Mantis report for all the info):
- Bounding box values are still different in original and saved models. Is this supposed to happen?
- The new bounding box values are not shown just after saving. You have to reopen the model in order to see them. Another bug?
:wtf: :wtf:
And now a question. What's the BSP cache? Thanks.
-
:wtf: :wtf:
And now a question. What's the BSP cache? Thanks.
http://www.hard-light.net/wiki/index.php/POF_Constructor_Suite_2#FAQ
-
That wiki page actually references an RC2d being the first one to properly check for BSP caching. Are you holding out on us? :)
-
yes i am :D
the only diff between rc2c and rc2d at the moment is
A) RC2c caches BSP occasionally when it shouldn't, fixed in RC2d
B) RC2d has the version of the compiler implemented - which will force it to recompile all models from earlier versions of PCS2
C) RC2d has a minor cosmetic fix for SOBJ bbox display
once there are more significant fixes i'll pop it out..
whoever was having collision detection problems with rc2b pls try rc2c
-
It seems to have fixed the problems with the Protector and Cylon Assault Frigate from the BSG Alpha pack. I'll probably re-export all the models now just to make sure it's all fixed, or maybe just wait and hear what everyone else says about it.
-
WoooHooo.. :D
Collision detection fixored. :yes:
Big thanks, to all the people working on PCS2.
-
I wanted to reconvert this redone Colossus as its collision detection was nonexistant but the RC2c build always crashes upon converting. The funny thing is it crashes at a different subopbject nearly every time. I don't know what to do. Purging the BSP cache didn't help either. Does anybody have an idea how I might fix this one?
[attachment deleted by ninja]
-
I wanted to reconvert this redone Colossus as its collision detection was nonexistant but the RC2c build always crashes upon converting. The funny thing is it crashes at a different subopbject nearly every time. I don't know what to do. Purging the BSP cache didn't help either. Does anybody have an idea how I might fix this one?
I deleted Debris 6,7,8 and 10 - it converted fine.
One (or all of them) have some modeling errors
Edit: Deleting just Debris8 allows RC2c to save without crashing.
-
in my expirience i find most model bugs are due to bad modeling, and over conversion. i figure every format you pass through costs you between 5% and 50% of your model integrity.
-
I wanted to reconvert this redone Colossus as its collision detection was nonexistant but the RC2c build always crashes upon converting. The funny thing is it crashes at a different subopbject nearly every time. I don't know what to do. Purging the BSP cache didn't help either. Does anybody have an idea how I might fix this one?
I deleted Debris 6,7,8 and 10 - it converted fine.
One (or all of them) have some modeling errors
Edit: Deleting just Debris8 allows RC2c to save without crashing.
Thank you very much! :yes:
-
give me the version of that model that is causing crashing
-
Look at the attachment above.
-
lol didn't notice the attachment
i'ts crashing because PCS2 is for some reason miscalculating the tree size so it's writing off the end of the allocated bsp buffer
-
Could you fix that, please?
-
[sarcasm]no.. i'm just going to leave it that way![/sarcasm]
of course i'm going to try and ****ing fix it
-
Good, I already thought I would have to convert it again from the .cob file and that would be a pain for a model with so many turrets.
-
possible you will want to.. this problem could indicate some corrupt geometry
-
If it is only some debris I can just delete it and prevent unnecessery work.
-
Small feature request: Automatically purge the BSP cache upon startup, and possibly, whenever you load a new model.
-
Small feature request: Automatically purge the BSP cache upon startup, and possibly, whenever you load a new model.
*faceplam*
did you read the PCS2 wiki article entry on the BSP cache?
it's a memory cache on a per-model basis, so when you startup PCS2 there is no cache, when you unload a model it's cache (if it exists) is unloaded
[edit]
the geometry for debris8 is signficiantly corrupt, i can confirm this in truespace and the fact that every senitnel variable that i attached that should have caught this didn't.
-
Thanks, then I will just delete it. I don't think that anyone will notice a missing piece of debris as the Colossus isn't destroyed very often.
-
yeah.. what i don't get is how it's managing to crash PCS2 when i put in the following checks
if offset >= buffer size, terminate
added two flags to tree nodes: counted and used, counted = true after been counted by the size calculate, used=true after being written to buffer. during writing check if it's already been written, or not counted, skip if either
and it still managed to walk off the end of the buffer.
[edit]
added more thorough detection and it found the overflow
-
got it!
it's not corrupt geometry, it was an error in calculating the size of the required buffer.
fixed
[edit]
RC2d posted
Note: the buffer size calculation bug would give you an overly sized buffer normally, but occasionally as in the case of the big C could give an undersized buffer apparently.
Size of coli86.pof from july beta build: 950kb
size of coli86.pof from rc2d: 882kb
-
So based on that size difference, this might also imply that the size inflation of many other models might also be reduced significantly?
-
yes
the more polygons in the model the greater the size inflation
-
For the "Think about the CHILDREN damnit!!!!" error dialog box :lol:
Is it possible to have the name of the faulty mesh in it.
And how much trouble is a "cancel loading" button beside the OK button?
-
there is a "Think of about the children damnit" dialog box?
it's already going to cancel load/save when it encounters an error btw
-
Err whatever you just did to RC2d allows it to now make it to that dialog box.
And no it doesn't cancel (for all models) - :lol: Just got through 50 + clicks on the ok button
gotta run
-
what model is causing that, it's gotta be one of bob's error dialogs
-
Yeah it is his dialog, and I'm pretty sure he would like any model that causes it, as he mentions here:
http://www.hard-light.net/forums/index.php/topic,41648.msg1041970.html#msg1041970 (http://www.hard-light.net/forums/index.php/topic,41648.msg1041970.html#msg1041970)
-
Heh - Thought it was the new standard dialog box for borked meshes. Makes sense that it's for unusual geometry.
http://files.filefront.com/Faulty7z/;9550609;/fileinfo.html (http://files.filefront.com/Faulty7z/;9550609;/fileinfo.html)
-
there are currently only 5 bugs in mantis that apply to PCS2.0 - tweak, trivial and minor statuses
if you have any bugs that are not fixed in rc2d you need to create bug reports in mantis (whether you mentioned them in the thread or not)
-
:wtf: :eek2: I find it kinda strange that i'm the first person to find this bug:
Sometimes PCS2 fails to load textures it should have found...... because my VP handler's search function was case sensitive.
-
also found that resuming a VP search when you file a file that matches the pattern (such as a .eff) but isn't a supported type is found.
search resuming was... retarded busted
-
ok people... i need someone with a newer (not 3.2) version of truespace to make sure PCS2 is importing smoothing data properly.
if nobody reports a new bug in the next week and that bug i just mentioned is not-a-bug i'm going to release
and if you posted about a bug and didn't mantis it i'm going to strangelate you
-
Does text not fitting within a dialog box count as a bug? I don't want to get strangulated.
-
Does text not fitting within a dialog box count as a bug? I don't want to get strangulated.
a cosmetic one, but yes.. bug it
cosmetic bugs probably won't stop me from releasing at this point
-
Will do. Although I just found that I have a somewhat busted model that causes Bob's geometry filter to throw up the children error about 30 times. I'm going to mantis it and you guys can determine if it's worth modifying the filter for.
-
k.. that's a bob thing and he seems to have disapeared
[edit]
bah... just found a critical bug... prevents me from running PCS2 on my laptop...
[edit2]
aaaaaand fixed