Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on February 09, 2008, 10:23:10 am
-
or in a mouthfull of redundant words "2.0 Public Stable Final 2008-02-09 Release-build"
http://sourceforge.net/project/showfiles.php?group_id=26889&package_id=53033
It may takes some time for the SF.net download system to replicate it to all servers.
PS: if you don't want your .ini blasted make sure to pay attention and check the checkbox at the right stage!
[edit]
caveat: go into options and set your cob scaling factor
[edit Feb 11, 2008 7pm Central]
I just uploaded 2.0.1 to the SF.net servers
-
wohoo!
-
Its only been released for a couple of hours and I already got it to crash. :(
-
Its only been released for a couple of hours and I already got it to crash. :(
Then MANTIS how you did it...
-
Its only been released for a couple of hours and I already got it to crash. :(
:mad: :hopping:
-
Its only been released for a couple of hours and I already got it to crash. :(
Then MANTIS how you did it...
Its manticized, though to be honest, I have no idea what's going on, its just a specific file that causes it to crash.
-
Attach that file to your Mantis report.
-
Attach that file to your Mantis report.
I did.
-
no crash for me
give me your textures for that model
-
OK here it is.
clicky (http://pages.sbcglobal.net/joey.wong/textstuff.zip)
Maybe that computer I am using is just messed up.
EDIT: It must be the computer, because it causes the same thing to happen with other sections of other models.
-
no crash
make sure you don't have any 0-byte .vp's in your search path
-
You should really add
..\maps\
as a default to the ini file. (when used as a viewer for non vp mods)
And the fact that it refreshes the textures when adding a path is cool.
-
you don't need to explicitly add \data\maps\ to the end of your paths - it's implied for every path and is automatically checked for each path
-
you don't need to explicitly add \data\maps\ to the end of your paths - it's implied for every path and is automatically checked for each path
Not when you click on a pof in a mod's model directory.
EDIT: Sorry - it only fails if you don't add a path for each and every mod. Saves adding a whole bunch of paths.
-
EDIT: Sorry - it only fails if you don't add a path for each and every mod. Saves adding a whole bunch of paths.
which is what the nice interface in the installer that gives you a list of subdirs of your fs2 install dir was there for :D
-
which is what the nice interface in the installer that gives you a list of subdirs of your fs2 install dir was there for :D
Yeah - but thinking in terms of people who use PCS as a casual model viewer.
-
which is what the nice interface in the installer that gives you a list of subdirs of your fs2 install dir was there for :D
Yeah - but thinking in terms of people who use PCS as a casual model viewer.
nothing i can do if they dont configure their model editor correctly
-
I guess what I am trying to say is that the amount of people using it as a viewer will be way higher than the number of actual conversion people. Some of these people go on to use PCS2 properly. Adding ..\maps\ to the default makes the experience with PCS2 for a whole lot of people (who you may never hear from) much better.
Anyway it really only affects new PCS2 users.
-
they had to configure modelview as well
-
Is there anything that could have changed for cob export? RC2D was ok.
On import, Truespace has -1.#IO in the info boxes for x, y and z (Location and Size)
-
W00t! Now the FSU pof fixing can begin in earnest. :D
Well done to the both of you. :)
-
Is there anything that could have changed for cob export? RC2D was ok.
On import, Truespace has -1.#IO in the info boxes for x, y and z (Location and Size)
not that i know of.. did you make a new .ini? could be a different scaling factor causing it?
-
Is there anything that could have changed for cob export? RC2D was ok.
On import, Truespace has -1.#IO in the info boxes for x, y and z (Location and Size)
not that i know of.. did you make a new .ini? could be a different scaling factor causing it?
Scaling is set to 0. Also I'm starting with a pof. Try saving a pof-->cob and open in Truespace
EDIT: scaling is set to 0 not 1 on (a delete ini) install.
-
Is there anything that could have changed for cob export? RC2D was ok.
On import, Truespace has -1.#IO in the info boxes for x, y and z (Location and Size)
not that i know of.. did you make a new .ini? could be a different scaling factor causing it?
Scaling is set to 0. Also I'm starting with a pof. Try saving a pof-->cob and open in Truespace
EDIT: scaling is set to 0 not 1 on (a delete ini) install.
*facepalm*
i <3 typo? :P
[edit]
the installer is leaving that value blank so it should be coming out as 1.0 as that is what i have set as the default value on pConfig->read .. weird
-
So, "Unknown chunk <SLDC>, len = 5887"
What is SLDC, what does it do, and when is it going to be supported by the engine?
Having the game almost-but-not crash for every model touched by PCS2 is a trifle annoying.
-
Kazan, could you reopen this bug (http://ferrium.org/mantis/view.php?id=51) about smoothing? I can confirm it because I encountered it today while making new asteroids for the MVPs using TS6. It's not urgent - I got around it by applying an autofacet of 120, but should probably be fixed sometime. I can provide some test models if you want them.
-
So, "Unknown chunk <SLDC>, len = 5887"
What is SLDC, what does it do, and when is it going to be supported by the engine?
Having the game almost-but-not crash for every model touched by PCS2 is a trifle annoying.
ShieLD Collision tree
support will go into the engine when i get around to it :D
-
I hope it's before the final commit for 3.6.10 then. Debug builds go psychotic on it and while I haven't re-installed to confirm on a clean dir, none of my other exe's like it either.
Atleast an ability to supress break out warnings on it alone would suffice. Kinda hard to play test when half your screen is the desktop.
-
unknown chunk shouldn't be causing break out warnings... FS2 should just simply ignore the unknown chunk..
-
oh... INSGs weren't getting corrupted .. just writing out in a way that was breaking FS2's rules (i wasn't reducing duplicate points in the point list, causing INSG verts > 30)
PCS2.01 open+save should correct any broken model
oh.. i'm working on implementing SLDC support in the engine right now
-
just uploaded 2.0.1 to the SF.net distribution system
-
It's finished! Finally!
It can't seem to handle transparent (read: glass) textures very well, though.
-
It's finished! Finally!
It can't seem to handle transparent (read: glass) textures very well, though.
no.. it's transparent texture handling is less than i would have hoped
-
Kazan, please update your signature.
It still links to 2.0 instead of 2.0.1.
-
PCS2.0.1
This bug is very minor and may only affect people making non standard asymetric turrets.
In front view (Blender and Truespace) Triple fire points per turret. (left-01 middle-02 right-03)
When auto-gen by PCS2
Turrets on top of the ship have left swapped with right. Have not tested any other combination.
-
just the firepoints?
-
just the firepoints?
Yes just the firepoints. :P In PCS2 auto-gen they are opposite to Truespace/Blender. Only tested turrets on top, didn't try side or bottom turrets.
(http://i229.photobucket.com/albums/ee67/waternz/export-fp.jpg)
-
ok.. then i probably know the problem
-
Holy ****, it's the Yamato! :eek2:
-
Hmm, the most recent build I've been using won't let you edit the radius. And it has difficulty clearing the cache between models (I can load model A, go to the header page, load model B, save model B, and it has model A's header.)
Lemme try this new one.
-
Hmm, the most recent build I've been using won't let you edit the radius. And it has difficulty clearing the cache between models (I can load model A, go to the header page, load model B, save model B, and it has model A's header.)
Lemme try this new one.
we know that it won't let you edit the radius.. there is a reason for that and there is nothing wrong with the bsp cache, now the screen may not be updating instantly like it should be
-
Out of sheer curiosity, has anyone had any trouble trying to get rotating subsystems to work? I set up what I need in PCS, then make the necessary adjustments to the ships table, and much to my annoyance nothing actually happens.
-
Out of sheer curiosity, has anyone had any trouble trying to get rotating subsystems to work? I set up what I need in PCS, then make the necessary adjustments to the ships table, and much to my annoyance nothing actually happens.
I have had a similar problem. Does the game crash when you try to collide with one of the rotating subsystems? Because that happened to me.
-
No, I don't believe so, though I did experience a crash. Don't think it had anything to do with crashing. Can't really remember. I was too irritated trying to understand why the hell half of my inputs don't work in game when I'm following the tutorials. It IS getting a bit frustrating though. I'm pretty sure it's an error with PCS, but because of my own noobishness to importing ships into FS2, I could very well be mistaken.
It should be noted that I'm doing this for The Babylon Project, Inferno build, so I'm not sure if there's anything there that might be causing the problems.
-
Are you sure you've gotten them set up correctly? There are a fair number of components to them:
In the pof file for the rotating subobject, you need to add something like this to the properties:
$special=subsystem
$name=Solar Panel
$rotate=5.1
Then you need to define the "Movement type" as Rotate and then pick the axis around which it rotates (assuming you set that up correctly before conversion - if not you'll have to reconvert).
In the ships table you need to put a line designating the subsystem, like this:
$Subsystem: science01a-solar1, 8, 0.0
Note that it's labeling the name of the solar panel subobject and NOT the "Solar Panel" name defined in the subobject properties.
Do all that and it will work - there's nothing wrong with PCS2 there. :)
-
For some reason I cannot look at weapon points or turrets without crashing. :blah:
-
Are you sure you've gotten them set up correctly? There are a fair number of components to them:
In the pof file for the rotating subobject, you need to add something like this to the properties:
$special=subsystem
$name=Solar Panel
$rotate=5.1
Then you need to define the "Movement type" as Rotate and then pick the axis around which it rotates (assuming you set that up correctly before conversion - if not you'll have to reconvert).
In the ships table you need to put a line designating the subsystem, like this:
$Subsystem: science01a-solar1, 8, 0.0
Note that it's labeling the name of the solar panel subobject and NOT the "Solar Panel" name defined in the subobject properties.
Do all that and it will work - there's nothing wrong with PCS2 there. :)
But I did all that and it still didn't work.
For some reason I cannot look at weapon points or turrets without crashing. :blah:
I have the same problem. No one else can replicate it.
-
Vasudan Admiral, would you like to take a look at my pof file, because I had everything set correctly, and have checked multiple times for syntax errors.....
Wait, do you have to include the name of any child geometry by any chance? because I have not done that.
My tables look like this:
$subsystem: rotsec01a, 40.0, 32.0
and my pof info is this:
$special=subsystem
$name=manipulator
$rotate=20
It should be noted though that I do have child geometry as well, going by the name "barrel-0a".
-
I'll take a look, yeah.
-
Kazan just to make sure, are all of the dlls in the installer?
-
I'll PM you the link after I've uploaded the file. Also, a weapons file and effect (the weapon that the Brittlestar uses) are included as well as the pof and ship tbm. No textures have been included. If there is a problem where you need the textures, I'll send them to you as well. If by any chance it's a model error, I can send you the .max file.
-
How bad is the MOI calculator? Many TVWP models need MOI values; is it better that I try to find similar ships and copy the values, or is the MOI calculator adequate?
-
I so far have not had any practical issues telling PCS 2.0.1 to calc MOI for models missing it.
Wether or not the models actually respond well or appropriate based on collisions or explosions is still in testing. And I've noticed that cap ships tend to have quite a bit more "dance" than before, but I also just recently changed builds.
-
And I've noticed that cap ships tend to have quite a bit more "dance" than before, but I also just recently changed builds.
that seemed to be build related to me.. because it happens on models that have been around a while
-
PCS crashes with congruent faces and opposite normals. Although that was my fault, it would be nice if it said something more specific than "Oh my GOD it's so HORABLE!"
-
Lol. If you did get an error message like that, it's probably one you weren't supposed to see. Chances are Bob or Kaz would like to see what model caused it so they can make sure that error doesn't come up again and that it gets handled more gracefully in the future.
-
PCS crashes with congruent faces and opposite normals. Although that was my fault, it would be nice if it said something more specific than "Oh my GOD it's so HORABLE!"
it's a bob error msg
-
I dunno if this has to do anything with the program itself but posting here anyways (sorry)
When I try to open the program I get the error message : Not properly installed , please reinstall/doesn't reconzie the program" or someething (my windows is in norwegian).
:blah:
Useing the latest install.
Older versions gave the same problem.
edit:nevermind I was just retarded, found out the problem. :nervous:
-
What the heck is an MOI value? That is a completely new term to me :huh: is it an fs term or code/conversion. I don't like to think there's a gap in my modding knowledge even if there a a few holes in my ability ;7
-
Moment of Inertia (http://en.wikipedia.org/wiki/Moment_of_inertia). :)
-
But is PCS2's MOI calculator accurate enough to be used?
Are you sure you want PCS2 to calculate the MOI? Its not very good at it.
(Or something like that)
-
That was my question. I ended up just copying in values from similar V original ships.
-
Are you sure you want PCS2 to calculate the MOI? Its not very good at it.
O'RLY?
who said that?
-
PCS2 itself says that! :) When you click the recalculate button says:
Are you sure you want PCS2 to try to recalculate the MOI? it's probably not very good at it
Thus the query -- is it better to click the recalculate MOI button in PCS2, or should one find a similar V model and copy and paste the values from there. Both will evidently be inaccurate, but is the difference enough to take the time to manually copy n paste?
-
I thought Bob was happy with the latest version of it. I think it behaves differently than the retail values, but it might actually be better than them. I'm not sure if that was actually the case, but I seem to remember reading a report or two along those lines.
-
afaik the moi calculator is as close to [V]'s as he could figure... but theirs are somewhat... strange
-
Is the GUI framework the reason why the gui is so sluggish at times? Especially when trying to setup the turrets.
-
Is the GUI framework the reason why the gui is so sluggish at times? Especially when trying to setup the turrets.
no.. the renderer probably is.. it's not using VBOs right now
-
Can an model be made with flasing lights like a aircraft at night? If so how do I set up in PCS ? and will it need a listing in ships.tbl ?
-
Can an model be made with flasing lights like a aircraft at night? If so how do I set up in PCS ? and will it need a listing in ships.tbl ?
Yes, those are called glowpoints. I would recommend looking at other POFs to see how they are set up. That's how I learned it. And no, you don't need a listing in ships.tbl.
-
The MediaVP Orion might be a good example, it has running lights on the 'runway' leading out from the fighterbay.
-
You can also use animated textures, like omni's Trek Bussards (for example). And the before mentioned Orion Runway.
-
Ok, I just ran a slew of models through PCS2.0.1, reconverting them all, using the MOI calculator, and saving them. All but one are throwing inverted B-Box errors. Is there some step I'm missing that's supposed to prevent that?
-
I don't think so - I've just found and fixed a load of that same error with a lot of resaved models in the FSU. A second resave has so far fixed it for me, and I was then unable to get it to happen again so I have no idea how it happened in the first place. I think it might be happening during the initial BSP generation or something which would explain why it didn't repeat or alternate in subsequent saves. I've not found anything conclusive in any way yet though.
-
Ok, I just ran a slew of models through PCS2.0.1, reconverting them all, using the MOI calculator, and saving them. All but one are throwing inverted B-Box errors. Is there some step I'm missing that's supposed to prevent that?
load them
purge bsp cache
save them
and... make sure you're running 2.0.1
-
That's what I figured, after posting I read through Mantis to see where there was mention of this issue, and it said something about that. So, I'll go through that whole slightly extended version of the process again, when I get home tonight. Should I also delete the ibx's and the model comments just for good measure? :)
-
the system should detect that the models have changed i think.. i don't really know how the .ibx system works so delete them to be safe
-
and... make sure you're running 2.0.1
Well that's the thing - all the FSU stuff I've fixed or fiddled with has been done using 2.0.1, and those are the models where I found the errors. They seem to especially occur on any model that was converted from cob in it. I've not been able to replicate the error though, so I don't know when or where the bbx flip occured. :\
-
Should I save as PMF, then as POF? Because I've got all kinds of bounding box errors in my mesh. (yes, these were done with POF Exporter, NO, I'm not going to go nuts playing through 10 different programs to get some bastardized mess of various exports to maybe show up right in PCS only to find something else wrong with it).
Only thing I can think of might be a failure to reset X-Form in Max on some meshes.
-
These are all models that have been POF for some time, and which had most recently been resaved using one of the PCS2 RC builds. So I took all of them, opened them, hit the MOI button, and resaved them (after making backups of all of them of course). I wonder if it's inverted now, if I resave them all again, maybe it will invert them again, thereby making them not inverted?
Edit: Ok, it appears a manual purge is fixing it. Is this a bug then? I'll file a bug report if so. I thought that BSP was supposed to be automatically purged for any older versions of the exporter, and the program has even led me to believe that's the case, since the Show BSP Debug Info was not selectable for any of these models until I saved them again. So I assumed the BSP had already been purged. Now it seems it either wasn't, or wasn't done properly. I don't mind manual purging, but I didn't think it was necessary any longer.
-
One small question/problem... Did you alter the way it saves files between the alpha and the 2.0? besides fixing the inverse bound error? I've got a model that was converted with the alpha and has the inverse error, but if I try to save it in 2.0 it just gets stuck. :confused:
-
Kazan do you have the latest version without the installer? Because the installed PCS2 is the one thats trouble and the non-installed versions didn't.
-
Bug in Sub-object rotation.
Both X and Y axis rotation do nothing for subobjects. Z axis does work.
Confirmed with Truespace and two different models.
VA during testing also provided a model with x, y and z rotating subobjects. In the mission AXIS-ROTATION-Test the model on the left went through PCS1, the faulty one one the right by PCS2.
http://files.filefront.com/rotation1vp/;9833677;/fileinfo.html (http://files.filefront.com/rotation1vp/;9833677;/fileinfo.html)
-
Hey I got your program to crash consistently. See post in Mantis
Though problem is probably my model not your program . . but who knows.
-
I also got a crash problem with PCS2 2.0.1 . Already mantised it. Also, (I dont know if it was already posted or if it is a problem with PCS) I´m having collision detection errors with every model I convert with PCS2, and when I convert them with pcs1 I don´t have any. At first I thought I was doing something wrong with my modelling, (bumps, bad geometry, etc), but then I begun testing stable models and they had the same collision detection problems.
-
Just purge BSP cache and resave. Collision detection should be fine.
-
Just purge BSP cache and resave. Collision detection should be fine.
What is the BSP cache and where is it? Are you saying that by purging this, the collision detection will be fixed? or that it isn´t supposed to be havving problems at all?
-
Its under that data menu. By purging it, you force PCS2 to recompile collision detection data etc.
-
Mostly a feature request, somewhat a bug: may I request that Weapon Points be made more visible/obvious? Particularly in cases where multiple missile banks share the same points.
I know, the answer might be "don't make the missile banks share the same points" :p, but picture this. I have a model with secondary bank 1 that has 20 points, for example. I wish to split this into secondary banks 1 and 2 with 10 points each. After I push the copy button on secondary bank 1, bank 1's points look 'faded' when I reselect the bank, and it's a lot harder to tell which is selected, no matter which color I try in the options so far.