Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Tools => Topic started by: The E on May 24, 2010, 08:21:26 am
-
As you may know, I agreed to redo the PCS2 UI. There are a few things that I know pissed me off whenever I used it, and I'm going to correct those. But what do YOU think it could do better? What are YOUR annoyances?
Note that I probably won't be able to accommodate everyone's wishes, but I will take it into consideration nonetheless.
-
what are you changing?
-
The main things I want to change are
1) The GLCanvas grabbing focus whenever the mouse is over it
2) The Splash screen being on top of everything
3) A few additions to the texture editor (such as incorporating a texture preview function)
4) Better handling for the path lists (right now, if the model paths are updated, the treeview and the path editor get out of sync to easily)
-
as for the textures, a UV editor is planned, though I suppose a texture preview wouldn't adversely effect that.
the canvas focus grabbing was to fix some other issues, though if you are going to tackle that you will run into them and have to fix them yourself.
-
Like....? You know, it would really help if you explained that. Haven't found comments in the code that would do that yet, so anything you'd like to share would be appreciated.
-
I believe it was to ensure that the display would stay up to date as the GUI controls are all designed to automatically update when ever they lose focus.
-
The main things I want to change are
1) The GLCanvas grabbing focus whenever the mouse is over it
This, a thousand times this.
One thing I would like to see is being able to select multiple subobjects (turrets) at once for easy editing. (Manually having to select the Movement type and Axis from a drop down menu for 20+ turrets gets old rather fast)
*edit: stupid typo
-
Here's a few of mine:
1. The model view doesn't work right with really big models: if I have for example a huge planet model which is just a simple sphere, I can't actually make it visible in the window.
2. You can't pan the view, so it's hard to get to see some parts of some models. Sure there's the hideous auto-centering panel, but it's a really bad way to do it (if it even works; I'm not sure).
3. The object tree hierarchy view thingy on the left collapses the trees on its own from time to time. For example: expand the subobjects tree so you see all the subobjects listed, then go to the textures panel and change some texture - bam, the subobjects tree collapsed, so I have to go manually expand it again. Very annoying when you need to jump back and forth between two places copying or checking something and have to constantly re-expand some trees.
4. The little drop-down menu next to the subobject properties box has a bunch of non-functional ones (at least $detail_sphere).
5. When saving a model without having the MOI calculated, please pop up a dialog asking whether you want it auto-generated. I can't count the number of times I've forgotten to do it and only found out when I actually run the game and try to use the ship.
6. Viewing turrets, thrusters, special points, paths etc doesn't work on at least some older graphics cards. (http://www.hard-light.net/forums/index.php?topic=61476.msg1288809#msg1288809) I'd guess due to some missing/unsupported OpenGL extension that's used in drawing the orbs.
I left out the lack of proper error messages (which is pretty much the biggest problem with PCS2) since I suppose those are not an UI issue as such.
-
most of those odd errors are related to some unexpected error, an error happened at somewhere I didn't think an error could happen. they usualy have as much information in them as I could get from the situation, like OGL returned some sort of error, or an array went out of bounds.
-
Oooh excitement! :D
General:
1) I'd love to see some checkboxes up on the main menu to define whether or not you want PCS2 to rebuild the BSP cache (but be sure to call it "Collision Data") upon saving, as I think that would be quicker and easier to remember than the Data->Purge option.
2) With the default colours, could the wireframe overlay colour for subobjects be set to bright red or something other than the same white that the wireframe view uses? That way you can tell what you've selected!
3) A 'recent files' list in the file menu
4) Some definable 'quick jump to folder' options in opening/saving, since currently it just remembers the folder you were last in
5) A default save name - currently even if you've opened an existing pof, when you go to save it you will have to type in the name of or select that same pof to give it a name, since that field is blank by default. The number of times I've overwritten the wrong model by mistake cos of that.... :\
6) Might be pretty tricky, but having a centre of rotation for the camera that moves only when the camera is panned. (Panning is Shift + Left Click + drag for anyone who was wondering) Currently if you zoom in and then pan to focus on a subobject, as soon as you rotate the view, you're left staring at empty space or some other random bit of your model, as the view is rotating around the ship's centre.
7) Slowing the panning speed down too would be good!
8) Clearer button icons - since it's always struck me as a bit pointless to try and differentiate movement constraint planes on a cube. :p It really needs to be a nice neat ship outline. A ship with a clear front and back, top and bottom so you can instantly tell if the plane you want to activate is the right one. Something even newbs will recognise would be great, like an X-wing or hercules.
9) Buttons to switch to the directional views (including reset) that are currently accessed from the view menu.
10) A "Do you want to save the changes you have made?" message box when you try and close the program.
11) A "Quicksave to PMF" button on the main bar, since PMF is a lot more stable than POF during the saving process. It would save a PMF to a tempoary directory in PCS2's installation folder.
Tree Menu thing on the left:
It's very cool and definitely a huge help, but a few tweaks I would love to see:
1) Better memory of its last state, as after any edit of a low level item such as a drag and drop will cause it to reset the area you're working on as well as the position of the vertical scrollbar if you're working on some area down the bottom. For deeper edits such as subobjects or paths this gets to be very frustrating.
2) It would also be cool if it could redraw faster or not completely redraw every time there's a change.
Subobjects:
Yeah selecting multiple subobjects to edit at once would be very handy, but if that's not possible:
1) Switching the 'Movement type' and 'Axis' options to be radio buttons would make them a lot faster to use
2) Not sure if it still does, but at some stage PCS2 imported subobject data and attributes based on their subobject number rather than name, so if you reconverted a model and that threw out the order, everything would get soooo mixed up.
3) A few auto-generate data buttons would be very handy such as:
"Turret" which would enter:
$special=subsystem
$fov=180
$name=Turret
and "Radar" which would enter:
$special=subsystem
$fov=360
$name=Radar Dish
$rotate=3
Turrets:
DEFINITELY change the "Parent" and "Physical" labels to "Turret Base" and "Turret Arm" respectively!!!
This might be better in the subobjects area or both, but an auto-gen feature to intelligently set up turrets. What I'd imagine it would do:
1) Clear all existing turrets in the turrets list
2) Look through the subobjects list, pick out 'turret' in the subobject names or subobjects that have been given turret subobject properties already.
3) Add the default turret data to those subobjects (not their arms) that need it.
4) In the turrets section, create a turret for each turret subobject it found, and set them up with their arms as well if necessary.
5) Have a guess as to what direction the turret is pointing in based on the parent subobjects position relative to the centre of the model and set that direction as the normal. (Just the basic 6 directions would be fine - I can write a series of rules to follow if needed)
6) Plonk a single firepoint at the origin of the turret or turret arm. If you wanted to be really snazzy you could place it at the extreme of the bounding box (ie, so a turret arm pointing up you'd pick the middle of the highest plane of the bounding box) but its usually safer to just use the origin.
Paths:
1) Could we possibly get little floating number labels for each path point of the selected path, and a note reminding users of which end to start at and go to. I keep forgetting! Point 1 is furthest away, point<last> is closest to the final destination/objective.
2) The ability to select a path point by clicking on it.
3) Maybe make a drag and drop control to change the radii of the currently selected path point. Ctrl + Middle Mouse + drag might work best. Towards the points origin would shrink, away would expand.
Eyepoints:
It would be good to change the default colour of the selected eyepoint to bright red so it's more easily spotted!
-
-make it possible to move the right side panel to the bottom. this would look better on non-wide screen monitors.
-add a density setting to moi/mass calculation
-allow editing of submodel bounding box and radius
-lock rotation when using left/right/top/bottom/front/back views, use non-shifted mouse downs to control camera translation instead while using these views
-flythrough camera mode, camera may be controlled with wasd + mouse (please add invert y and speed options!), useful for looking at tight places on large capitol ships
-add new subobject properties to quick insert menu
-separate save and save as
-autogen support for collision meshes (http://www.hard-light.net/forums/index.php?topic=69378.msg1371102#msg1371102)
thats all i can think about right now.
as for the textures, a UV editor is planned, though I suppose a texture preview wouldn't adversely effect that.
seems like the preview code could also be used with the uv editor, so you could overlay uv mapping on top of the texture to make editing a lot easier.
-
In another thread, there was a suggestion of allowing the program to access VPs for textures. First of all, it would be useful if, unlike MODview, it gives you the option to check for textures in the FS2 default VPs, or asks you to select which VPs (outside the FS2 directory) to look in, for example if you're working on a TBP model. On a similar but possibly less feasible level, if the model opened has been accessed directly out of a .zip, .7zip, or .rar file, the program should look there first for the textures. Now, that last one is probably more trouble than its worth, and possibly not possible due to licensing issues, but I thought I'd bring it up anyway, should someone come up with a brilliant solution.
-
In another thread, there was a suggestion of allowing the program to access VPs for textures. First of all, it would be useful if, unlike MODview, it gives you the option to check for textures in the FS2 default VPs, or asks you to select which VPs (outside the FS2 directory) to look in, for example if you're working on a TBP model. On a similar but possibly less feasible level, if the model opened has been accessed directly out of a .zip, .7zip, or .rar file, the program should look there first for the textures. Now, that last one is probably more trouble than its worth, and possibly not possible due to licensing issues, but I thought I'd bring it up anyway, should someone come up with a brilliant solution.
You can specify a full list of paths to check for textures in PCS2. You could specify FS2, TBP, whatever folders you want, and you can even put ../../ as the first path or ./ so it always checks in the model's mod folder first. The list even has customizable priority. I'm not sure what you're asking for that can't already be done.
Zip programs don't work that way. If you open a zip and doubleclick the model file, the zip program extracts it to a temp folder and opens that. PCS2 has no way of knowing that the textures are in a zip file or where that zip file is, and they're not extracted with the model. So that just can't happen I don't think. Opening a zip file containing a model with textures via PCS2 is a possibility but would require archive support to be added to PCS2. It's not a licensing issue, there's GPL'd archive handlers all over the place.
-
Yeah, I think editing/opening files straight from a non-VP archive is too much work to be worth it.
-
Kaz already has the code for opening files from a VP, it might be a lot easier than you might think it would be.
seems like the preview code could also be used with the uv editor, so you could overlay uv mapping on top of the texture to make editing a lot easier.
I'd need OGL to draw the polygons, so... maybe, depends, but it's not like that would be colossally difficult code to write if his implementation turns out to not be extensible for this application.
P.S. I'm not going to hold my breath on any of this until I see the code in GIT and a commit of any sort made.
-
PCS2 messes up the submobels when saving and then reloading POF->COB->POF (For rescaling)
(Try to export mjolnair (beamsaber.pof) to cob and then opening the cob,the grind02a submodel gets messed up)
-
Apart from the things listed, a feature to browse through VP files (like Modelview has) would be handy too.
-
Kaz already has the code for opening files from a VP, it might be a lot easier than you might think it would be.
which is being rewritten btw
..
and STICKY PLEASE :D
adding this to the important threads.
-
PCS2 messes up the submobels when saving and then reloading POF->COB->POF (For rescaling)
(Try to export mjolnair (beamsaber.pof) to cob and then opening the cob,the grind02a submodel gets messed up)
this is probably a relic from the way the cob format is a pain in the arse
-
Well, if DAE support becomes "official", people shouldn't need COB anymore...
-
PCS2 messes up the submobels when saving and then reloading POF->COB->POF (For rescaling)
(Try to export mjolnair (beamsaber.pof) to cob and then opening the cob,the grind02a submodel gets messed up)
i think a scaling tool would be good for this kinda thing. you could convert the model to pmf, scale, and recompile to pof internally without any additional saving or any new files. the point of pmf is to provide an easily editable format to work with. theres really no reason to go back through cob to edit stuff. thats just another unnecessary conversion process which could lead to errors. scaleing should be available at any level of heirarchy from global to individual subobjects to groups of subobjects. any data chunks such as docks and gunpoints connected to those should also be scaled where applicable. same should apply to rotation and translation. not really something i need as i like to do as little editing in pcs2 as possible, but just something that uses existing capabilities.
-
scaling in the tool is planned. Please check the first post of this thread: http://www.hard-light.net/forums/index.php?topic=41648.0
-
People like me would still need cob format for rescalling ships as it's easy(for the most part) unless there is a conversion scaling factor for dae too,or probably for internal pmf format.
It might be a good idea to add a feature to rescale the ships(or even better adjust length,breadth & height separately)
-
please check the thread i linked - that's the official roadmap. i've updated it in the last few days. Model rescaling in PCS2 (That would be in the PMF format) is supported.
-
And I'm hoping that handles _everything_? Rescaling all coordinates, including paths, glowpoints, subobjects, shield meshes, etc?
-
its not implemented yet, but that was the plan
-
-The long delays when many objects exist and double repaints. Try putting a couple hundred dock points on a ship and you will see what I mean.
-Global import imports MOI data if not already set.
-Global import imports rotation and axis
-Ability to auto generate a single path instead of all
-Ability to auto generate paths for subobjects with $special=subsystem
-it's already been said but resize
-again already said but that dang splash screen taking focus
-points shown at actual size/position. These seem to scale and/or drift with either ship size or distance from center. If your trying to place a special point on a large model where and how big it shows in PCS2 isn't what you get in game. Same with thrusters and glow points.
-Don't minimize trees when switching between branches. For instance between docking points and paths.
-This might be better then the above. Allow multiple tree views so you can list things like docking points and paths side by side for easy editing. For weapons you could have subobject, turret, and path trees for quick copy/pasting of coordinates.
I personally love the current layout it's just some functionality that has issues.
-
-points shown at actual size/position. These seem to scale and/or drift with either ship size or distance from center. If your trying to place a special point on a large model where and how big it shows in PCS2 isn't what you get in game. Same with thrusters and glow points.
I think I discussed the same bug earlier with Kaz on IRC.
-
Also,
The ability to rotate submodels by an angle,
like if you import some submodel from another model and it is not at the right angle which you would like!
-
Also,
The ability to rotate submodels by an angle,
like if you import some submodel from another model and it is not at the right angle which you would like!
rotation shouldnt be any more difficult than scale.
-
The main things I want to change are
1) The GLCanvas grabbing focus whenever the mouse is over it
This, a thousand times this.
One thing I would like to see is being able to select multiple subobjects (turrets) at once for easy editing. (Manually having to select the Movement type and Axis from a drop down menu for 20+ turrets gets old rather fast)
*edit: stupid typo
Two Million Times THIS
Having to change each thruster and weapon orientation one-by-one is easily one of the most tedious and time consuming part in model importation.
-
Use copy-paste?
That's what I do for turret/thruster orientation.
Still, the functionality would be nice.
-
I'd like to be able to edit shields in PCS2 (that's pretty much the only reason I still use Modelview).
Modelview also has another interesting feature, converting missile banks to guns and the other way around.
That would also come in handy from time to time, doing it "by hand" is boring and involves a lot of copypasting.
As for bugfixes, PCS2 sometimes takes cursor out of the text box I'd like to edit, it becomes a bit frustrating to have it suddenly do that in the middle of writing (if I move the mouse, cursor returns, but sometimes it happen a few times in a row).
-
Oh right, yeah also, if your mouse isn't over the right hand sidebar, trying to type in the textboxes there doesn't work, so you have to make sure your mouse is there. If you bump it off, then you have to retype what you just tried to type...
Minor thing, but hey, we're improving the UI right? :P
-
Actually, that was one of the very first things I fixed.... (If you look upthread, you'll see me talking about "the GLCanvas focus grabbing" issue, that's basically that. As soon as you move the mouse over the area where the ship is rendered, that control gets mouse focus (i.e. it gets treated as if you clicked in it), which of course means that all other controls lose focus.
-
Ah, nice to see that it's fixed :)
-
Here's a little idea I came up with...
Instead of:
(http://www.ciinet.org/kevin/myimages/Insteadofthis.PNG)
What about this? (mockup)
(http://www.ciinet.org/kevin/myimages/Whataboutthis.PNG)
-
:yes:
At least, unless/until we get support for generic-axis rotation, or stuff other than rotation.
-
It makes sense, even if we do get that, as it simplifies the default layout.
-
Ability to manually set rotation lines for any kind of an object. I hate when my turret rotates in other way than the one I desire.
-
Just a minor thing but TBH I'd personally prefer radio buttons instead. 1 click per turret instead of 2. Non rotation movement types are not at all likely any time soon, and I doubt that such a system would need anything specified in the POF anyway. That'd most likely be handled by the instructions in the ships table entry or something.
-
5) A default save name - currently even if you've opened an existing pof, when you go to save it you will have to type in the name of or select that same pof to give it a name, since that field is blank by default. The number of times I've overwritten the wrong model by mistake cos of that.... :\
This should be happening already in 2.1 at least.
3) A 'recent files' list in the file menu
Done.
-
I'm unsure if it has been mentioned, but would that be possible to reintroduce PCS1 insygnia editor to PCS2?
It could come in handy for setting up insygnia on user-made models which don't have them by default and a modeler is unavaiable, as well as for modelers who don't know how to set insygnia in the modelling program.
-
I don't know if this is possible, but one thing that would have helped me is when you are looking at the textures, it gives you the filename of the texture.
EIDT: Apparently it already does... my bad.
-
So... in relation to my previous texture post... how about the ability to 'open currently selected texture in default editor' option?
-
Have you tried the "Open Externaly" button?
-
Now that you mention it.. there is one isn't there... it doesn't work for me.. that's why I thought there wasn't one.
-
Another small request - could it be ensured that saving as POF is the default option despite any filename extensions? I just converted a DAE, added all the pof data and saved, but then found it had saved it as a dae because the default filename still had .dae on the end.
On this model it's lucky because it didn't have any of the kinds of data (rotation basically) that would have caused me to lose work, but it came close! I somehow also saved it as a COB. Don't know how that happened. :\
-
That's different from a lot of apps, although in the case of dealing with conversions there's usually some exceptions. I would argue that the default should actually be PMF, that way there's no conversion performed in case you forget to select one, and no data is lost. It's PCS2's native format so that makes the most sense to me at least. Every other save is more like an export.
-
Yeah PMF would be fine too. :)
Also one other thing but the right click seems to have been remapped to roll the model whereas it used to zoom in and out. Middle mouse still rolls. Can we get the right-click to be zoom in/out once more?
Or actually what might be nicest:
Left click & drag -> rotate view
Scroll wheel -> zoom in or out
Middle click & drag -> pan view
Right click & drag -> roll the ship
-
What about a "hide" function? Currently, trying to distiguish special points on a complex destroyed can be hectic. Being able to hide other special points would make this easy breezy.
-
What about a "hide" function? Currently, trying to distiguish special points on a complex destroyed can be hectic. Being able to hide other special points would make this easy breezy.
Wouldn't the more obvious solution be to make the current selection more clear?
-
Hmm no that's a pretty good suggestion actually - cos especially on retail ships you have giant split specials that can make anything below them hard to see. Also subsystems in close proximity to each other can tend to blend together into a bit of a white glob depending on the ship. I've changed my colours around so there's significant difference and I do still have trouble occasionally. Being able to hide some or maybe all but the active subsystem would be helpful.
A hide subobject function could also be useful when dealing with complex models with lots of subobjects and/or moving parts. Like if you have a launch bay tunnel and are trying to accurately define path points - turn off the detail0 subobject and deal only with the hangar subobject. :)
-
I guess this is relevant here... I haven't checked in a "recent" PCS2 (where can I get one?) but I'd hazard a guess nobody's done anything about this:
Consider the model debris01.pof -- 3d debris 'flakes' spawned when you shoot stuff... each species has its own texture which is applied to it. In PCS2, you can't see that it contains anything at all, without creating a subobject (IIRC)
I don't know how this would best be dealt with however
-
No problem at all seeing that in PCS2 but only the first species is actually used in game no matter what. I filed the mantis report on that one.
-
How about the ability to move a subobjects origin?
To illustrate what I mean, consider a turret arm. The origin of the turret arm sub object is rarely its actual center... its usually placed at the base so the arm rotates around that point. But lets say you screwed up and exported with the origin of the arm in the actual center instead of the point you wish it to rotate around. You would have to re-export to fix it. Would be nice to just adjust the value in PCS2 instead.
-
on point lists (weapon points, path points and any other kind of point (or any data in general) where you have more than one in a list), add sort up/down buttons to the interface that when clicked moves the selected point up/down to the previous/next index, so you can sort them out quickly if they are in the incorrect order. useful for when autogen screws up.
-
:bump:
i'd like to request the ability to add thrusters to a rotating subobject. So far you can only parent them to "detail0".
-
That sounds more like a game-engine limitation.
Does anyone feel like organising all these requests into some rough priority/demand buckets?
-
Oh, while we're at it, it would be great if turret firepoints were drawn with respect to the physical parent centre, like the game does. It can be tricky to set up multipart firepoints as-is.
-
Off topic but easy way to set up turret fire points: Make a copy of the working model and delete everything but the turrets and bases. Select all bases and center to 0,0,0. Select the center of each barrel and there you have your coordinates to enter into pcs2.
-
Firepoints are meant to be relative to the barrels? Why has this never been reported before?
-
No-one bothered enough, I guess. It only becomes really apparent when setting up non-orthogonal multiparts, where the firepoint will actually end up outside the barrel instead of just deeper/less deep in it.
-
It's an easy fix; sig build updated.
Fixing Collada import/export to work properly with multiparts is a bit more complicated though. I guess single-part and multipart firepoints are going to need different names.
Edit: Multipart firepoints should be under a helper named multifirepoints as a child of the barrel helper.
-
Kewl :)
-
1) Switching the 'Movement type' and 'Axis' options to be radio buttons would make them a lot faster to use
More or less done, but given that models aren't restricted to these combinations, which should take priority: no movement or a rotation axis?
DEFINITELY change the "Parent" and "Physical" labels to "Turret Base" and "Turret Arm" respectively!!!
Done.
[attachment deleted by admin]
-
Awesome! :)
What do you mean they're not restricted to those combinations though? Subobjects either rotate or don't right? I don't think I've missed subobject translations happening have I? <_<
I'd get it defaulting to no movement definitely as is.
-
With radio buttons there are 4 choices, but there are 4 other (inconsistent) possibilities in terms of rotation axis and rotation or no rotation. If it's set to rotation but no rotation axis, this is interpreted as no rotation, no axis. No rotation with an axis set is what I was asking about. I'm interpreting this as no rotation, no axis.
-
Very bad example as turrets should never have rotation.
Which brings up this idea. Can you filter things with turret in the name and auto set them to none and make it unchangeable?
-
Automatic defaulting to none: Yes. Locking it down to none: Bad idea.
-
Locking it will just result in angry and/or confused users.
-
Well then how about a message that you aren't supposed to have rotation defined for turrets and anything with turret anywhere in the name is considered one by the engine?
-
Huh? Since when has defining axes of rotation for multipart turrets been a nono??
Spicious: Ok yeah I get what you mean now - dealing with what are basically POF data errors. Good question, and I guess it would have to depend on how FSO interprets it. AFAIK if 'Rotation' is not set OR no axes for the rotation is defined, the object won't rotate, so based purely on that assumption defaulting both to the 'no rotation, no axis' case is best.
I can't think of any time I've seen anything other than that happen.
-
While technically not illegal there have been at least 2 problems caused by it.
First is rotation without axis. There must have been at least one version of PCS2 that auto-assigned rotation but no axis to turrets which is not allowed. I've also seen several cases of axis defined but no rotation.
Second if you do define it and give it $rotation or $stepped as well it is actually illegal.
So if you are going to do turrets you need to use uvec/fvec (unless it's on the top facing forward or bottom facing backward like in retail) and define the rotation speed on the $subsystem line.
-
Well yeah those cases of rotation but no axis or vice-versa and using the $rotation or $stepped flags on a turret are just ones of faulty POF data.
However to set up a basic rotating turret, you set the base to be rotating around Z, and the arms around X. So defaulting the settings (let alone locking them) to 'no rotation' and expecting the user to use u/fvecs would break almost every model with turrets done that way when opened in PCS2.
-
No you don't. Turrets need no rotation entries in the pof. In fact those axis entries would be incorrect to begin with. It anything it would be Y for base and z for barrels. This kind of information is part of the problem.
An example: B5 rotates around X axis. If a turrets barrels rotated that way they would turn sideways instead of elevating.
-
So retail FS2 models don't have rotation info set for their turrets? Because I had been under the same impression as VA, that standard turrets could set a rotation axis.
-
pm->submodel[n].movement_type = cfread_int(fp);
pm->submodel[n].movement_axis = cfread_int(fp);
// change turret movement type to MOVEMENT_TYPE_ROT_SPECIAL
if (pm->submodel[n].movement_type == MOVEMENT_TYPE_ROT) {
if ( strstr(pm->submodel[n].name, "turret") || strstr(pm->submodel[n].name, "gun") || strstr(pm->submodel[n].name, "cannon")) {
pm->submodel[n].movement_type = MOVEMENT_TYPE_ROT_SPECIAL;
} else if (strstr(pm->submodel[n].name, "thruster")) {
// Int3();
pm->submodel[n].movement_type = MOVEMENT_TYPE_NONE;
pm->submodel[n].movement_axis = MOVEMENT_AXIS_NONE;
}else if(strstr(props, "$triggered:")){
pm->submodel[n].movement_type = MOVEMENT_TYPE_TRIGGERED;
}
}
No matter what you set there the type gets changed from rotation to rotation special for turrets. This basically causes any rotation info to be skipped. Multi part turrets must either have the barrels facing up and the turret facing forward, the barrels facing down and the turret facing backward, or a uvec/fvec definition in which case the uvec is the axis of rotation for the base and the fvec determines elevation.
-
Just tested to confirm (before you posted to relevant code) and yeah you're right. (obviously now) Multipart turrets don't need any rotation details in the POF.
That's lame! We've been taught to do that since the modding cradle, and have been telling others to do the same the whole way! I have been propagating liez! :o
Well one final question then:
a uvec/fvec definition in which case the uvec is the axis of rotation for the base and the fvec determines elevation.
I've never actually used them, but my understanding of off-axis rotation is that fvec refers to the forward vector of a turret base rather than the current barrel elevation. The barrels should always be pointing along the Uvec line in the POF itself. Is that not correct?
-
That code snippet looks horribly brittle. And the correct rotation axes would have been Y for the base and X for the barrels.
That sounds about right on uvec/fvecs.
-
Exactly fvec is forward vector. Now think about it. Where do the barrels elevate from? Their forward facing positon. So no matter which way it turns the fvec determines which direction elevation happens. So if you had a multi-part turret with 0 base rotation and an elevation of 90 the barrels could only move between uvec and fvec.
-
That code snippet looks horribly brittle. And the correct rotation axes would have been Y for the base and X for the barrels.
That sounds about right on uvec/fvecs.
Can't be x for the barrels as they would rotate sideways instead of up/down like b5 does.
-
I forgot to set rotate/rotation axis for turrets once and they still worked so I just stopped doing it.
Saves soooooo much time.
As long as people know that they don't have to there's no need to force-disable it.
-
Having the X axis is its rotation axis means its relative x coordinates are unchanged by the rotation. Top/bottom mounted, forward/backward facing turrets require this.
-
Uh...no?
Unless it does it automatically (in which case I don't need to bother with it anyway), seeing as I haven't been setting it since, and all mah multiparts still work.
-
Not required to be set in the POF file, but the axis about which they actually rotate.
-
So its done automatically.
-
Something I've been wishing existed for quite some time but keep forgetting about. The ability to render just 1 debris piece instead of all. Also a toggle for -destroyed rendering. Both of these would be great in the ship lab as well. Right now the only way to see the -destroyed versions is to do a test mission. The only way to see individual debris pieces is to blow up ships and hope the piece you want to see survives and you can target it.
-
Some sort of ability to drag files from the windows explorer/or OS equivalent onto the info/hierarchy tree. For example drag a .dae onto lod3 section or over a lod0 turret?
-
Here's a big one: When double-clicking a numerical field, it will highlight select the whole value.
If the value is preceded by a '-' though, the '-' is not part of the selection, so when you copy to paste it somewhere else, it's dropped.
Being able to copy the '-' would be nice.
-
The biggest improvement I can think of would be the ability to rescale objects in PCS2, be they turrets, or even detail0. Saves a lot of trouble if you find out you got your scales wrong ingame and have to reimport from Max.
-
Ooh ooh! Yes that! Orientation adjustment too :3 ?
-
Uhh.
You guys HAVE tried the latest builds, haven't you?
Because that function was implemented already.
-
I'm aware of the import-scale settings. Is there a new scale button i've missed :) :confused:
-
Yes. In the right toolbar, top row, Button marked "Transform".
-
Alternatively hold down Alt and use the mouse.
Disclaimer: my current build may or may not be saving collision data correctly.
-
Spicious, your link is dead for me :nervous:
(the sig one)
-
It's working fine for me. Try this (http://mt.hard-light.net/spicious/pcs2.7z).
-
how about an lod distance calculator/debugger? it would take the model rotate it randomly and zoom in and out automatically. showing only the textured model and changing lods based on a set of detail distances input by the user in real time. the idea would be to make it very easy to come up with an optimal set of lod distances to use in the table.
-
That sounds like something more for the ship lab as you are going to get different rendering in PCS2 then in game.
-
I'd like to see a built in calculator either from a drop down window or in the subobject properties that will generate $uvec and $fvec values as some of them get reversed from what they should be. Perhaps entering the angle you want the turret to be at, and then it performs the sine/cosine functions or can take the information from a turret normal and build it off of that.
-
Not really a UI thing, but in the Preferences, I would love (since ".\" is valid) for "..\maps" to be a valid path as well.
This would help immensely with being able to test models stored in a mod folder without having to explicitly path the dir.
-
Try ..\..
The paths are meant to point at the root freespace2 (or mod) directory. So ..\.. should look for maps in ..\maps.
-
Try ..\..
The paths are meant to point at the root freespace2 (or mod) directory. So ..\.. should look for maps in ..\maps.
Worked like a charm. Now I feel slightly stupid.
Oh, for the Transform box (at least for the scale portion), the following:
Being able to lock axis when dynamically scaling would be awesome.
Assuming proper model alignment on export, labeling 'X' as 'W', 'Y' as 'H' and 'Z' as 'D' might be awesome.
The ability to checkbox 2 Axis at a time, instead of just one, all or Custom. Additionally, the "custom" box could ideally be broken down into 3 input boxes to put with the axis it is responsible for. And a toggle that can switch it from the current FLOAT value mechanic (or maybe 3 checkboxes) where you have "Absolute" = Changes the dimension to the exact specified number" and "Relative" where it adds/subtracts absolutely from the existing dimension.
Something (maybe kinda/sorta) like this:
(http://i1135.photobucket.com/albums/m634/Zacam/PCS2-Transform_Concept.png)
-
Could PCS2 save to POF instead of COB by default, like it used to?
Also, patch autogenerator got annoying to use in latest version, since it doesn't replace existing patches like it used to and completely ignores dockpoints.
-
Being able to lock axis when dynamically scaling would be awesome.
Suggestions for accomplishing this with the existing interface?
The ability to checkbox 2 Axis at a time, instead of just one, all or Custom. Additionally, the "custom" box could ideally be broken down into 3 input boxes to put with the axis it is responsible for. And a toggle that can switch it from the current FLOAT value mechanic (or maybe 3 checkboxes) where you have "Absolute" = Changes the dimension to the exact specified number" and "Relative" where it adds/subtracts absolutely from the existing dimension.
Doing multiple arbitrary axes isn't likely; the time saved would be fairly trivial.
Additive scaling and resizing to a fixed length are more plausible.
Could PCS2 save to POF instead of COB by default, like it used to?
It defaults to saving to whichever file was opened.
Also, patch autogenerator got annoying to use in latest version, since it doesn't replace existing patches like it used to and completely ignores dockpoints.
It doesn't replace paths because some people like to keep existing paths. Dockpoints only have paths generated for them if they don't already have paths assigned to them. Removing paths should behave correctly with dockpoints now.
-
OK, I'll try a new version (seems like it's been updated since my last download) and try it.
-
The ability to totally disable the render window. On really big models you have to wait 10-20 seconds between operations every time you make a field change.
The ability to type in the info instead of being required to use the pull downs. Right no it will let you type in the info but then changes it to detail0.
Oh and still really need the global import to parent turrets by name not object number. Redoing 100+ turrets every time because they parent to the wrong object is really a pain especially with that big delay between operations.
Adding a small bug to this. If you are doing turrets and you save the last barrel you did gets set back to detail0 unless you select another turret before the save.
Bug #2 if you hit the close button while the model is loading you get an unhanded exception.
-
New PCS2 still defaults to COB for me, every time I try saving something (it's set to "all supported formats" in the save window, but saves to COB).
It's really annoying.
-
Strange mine seems to do the same with .dae. Also it defaults to the wrong directory for saving now. Instead of saving to the previous save directory it defaults to the current directory. Pain in the butt when your converting and need to change drive and directory every time. The source directory changes with every model but the save directory rarely does. Same with global import. Defaults to where the .dae file was opened instead of the last pof save folder.
-
I thought we were going to default to PMF, so forgetting to set the format wouldn't lead to a loss of any data from conversion?
-
IMHO, it was good the way it once was. No need to change that, since the most common use for PCS2 is editing POFs, so defaulting to POF would mean you don't have to chose a format 90% of times you want to save something with PCS2 (the value may be different for some model converters, but for many people it'd be 99% of times).
-
The ability to totally disable the render window. On really big models you have to wait 10-20 seconds between operations every time you make a field change.
I believe that's actually the all the fields redrawing (flickering) or something.
Bug #2 if you hit the close button while the model is loading you get an unhanded exception.
Don't do that, or ignore it.
I thought we were going to default to PMF, so forgetting to set the format wouldn't lead to a loss of any data from conversion?
Discussions were inconclusive.
-
Discussions were inconclusive.
Default to the most usefull format, unless PMF is made usable by FSO (which I doubt), it's useless for anything but storing data, while POF is what most people will be using PCS2 to save to.
Right now, it seems to save either to COB or to a random format depending on user. Which is a bad thing.
-
POF has issues with dropping polygons.
-
I know, but that's during conversion.
Most people use PCS2 to edit POFs, there are far less converters than people who can do basic POF work.
Converters may want to change format they're saving the model in, but they can do it using menu (and sooner or later, the model will have to be converted to POF anyway).
-
PMF is not useless. It is the native format of PCS2, and anything saved in it loses no data. It's essentially a dump of what is in memory when you have a model open. It's the most reliable format for a model in progress in PCS2. It's like a .psd or a .xcf or a .doc. Most apps default to their native format for a save, don't see why PCS2 should be any different. Obviously Photoshop doesn't default to saving as a jpeg, because anything other than the native format is technically an export, not a save.
-
What about a checkbox in "preferences" window?
PMF is in most cases useless to me, since it doesn't allow testing anything in game. When I edit a POF, I adjust whatever I want and save to POF to test to see if it gave the desired effect. The only time I used it was when backing up glowpoints for an unrealiable model to prevent loss of my work in case of a crash during saving.
Since I see no reason to use PCS2 other than add data used in game by FS2 (it's meant to do just that, afterall), I don't know why to use it to save anything to a format which can't be opened neither by modelling programs, nor by FS2.
PCS2 is a special case, since it's a program used to put models into game. Photoshop is a program used for creating 2D images in general, so it's own format is the best one, since images can be viewed regardless of their format, and being viewed is their primary purpose. The primary purpose of the models created by PCS2 is for them to be used in FS, POF format is needed for them.
-
I think you're trying to make them seem more different than they really are. Many people use Photoshop primarily to edit camera images and put them on a website, etc. Many people may not actually need to make a POF in PCS2, rather perform some edits and send it back to someone else to work on. Ideally, we would have Save as only containing PMF, and Export would contain other non-native formats. As common as exporting to POF will be, it's still a format that is capable of losing information, and therefore work. The very notion of calling it a 'save' usually implies you're not going to lose anything, whereas people are more accustomed to an export having that possibility.
-
If a model can be gotten into PCS2, it should be ready to just add POF data and put it in game. What else can you do using PCS2 than adding POF data?
Photoshop is used for website pics by "many" of it's users, but not "almost all save a couple of modellers and converters". Also, Photoshop's functionality can be used for numerous other things, while PCS2 doesn't have functions that could be usefull for anything but putting models into game. What edits can you do in PCS2 that are not related to how the model works in game? If somebody wants to be sure he doesn't lose his work, then he can save to PMF. But default option should still be POF, because it's still the most commonly used one.
-
Converters may want to change format they're saving the model in, but they can do it using menu (and sooner or later, the model will have to be converted to POF anyway).
That seems like an argument for saving as whatever was opened.
-
As a converter 99% of the time I want to save as pof no matter what format I opened. The few exceptions are saving a model that was pof to a different format. So other then pof I never save in the format that was opened.
-
That's what I'm trying to say.
You, like most people, save to POF 99% of times they open anything using PCS2, regardless of what they convert from.
So, it would be most comfortable if PCS2 defaulted to POF on save, since that way, people won't have to change it every time they want to save a file.
Personally, I don't see any reason for using PMF besides making backups, which is needed only on the biggest, most labor intensive models (like largest Esarai's capships).
-
How about if "Save As" always defaulted to PMF, and there was a specific File menu item "Export to POF.."?
- Export to POF shouldn't affect the data in memory. I'm guessing that's actually the case already anyway?
Then you'd always have a quick option to create a POF.
-
I would think 'Save' would only mean PMF, and 'Export...' would have all the other options, defaulting to POF, or what was last used. But again, that's just me.
-
I would think 'Save' would only mean PMF, and 'Export...' would have all the other options, defaulting to POF, or what was last used. But again, that's just me.
+1 to this suggestion. Even if "Export" as a menu option doesn't tree out but just presents the existing "Save As" which then lists only POF, COB, SCN, DAE.
-
OK, maybe it's a good idea, but make sure that it's on the toolbar, like "save" is now.
-
+1000 for these, especially the Global Importation of turrets bit. I do not care so much about those two bugs listed, but my phone is unable to view the lower half of the message n the reply window...
The ability to type in the info instead of being required to use the pull downs. Right no it will let you type in the info but then changes it to detail0.
Oh and still really need the global import to parent turrets by name not object number. Redoing 100+ turrets every time because they parent to the wrong object is really a pain especially with that big delay between operations.
Adding a small bug to this. If you are doing turrets and you save the last barrel you did gets set back to detail0 unless you select another turret before the save.
Bug #2 if you hit the close button while the model is loading you get an unhanded exception.
-
Sorry for the bump, but I was wondering about the feasability of fixing the bugs in the post immediatly above, and if work has been started on them.
-
They sound plausible, but you'll have to find someone with time and motivation. Or send me an air-conditioner.
-
It needs a tool to change texture slots for importing objects. When I import turrets from other model, it don't fit with new model and looks awful.
-
They sound plausible, but you'll have to find someone with time and motivation. Or send me an air-conditioner.
... How much is a good AC running these days?
-
depends on where Spicious is located. I can get a decent 2500BTU unit for less than $60.
-
Not sure if I requested this one yet or no but not reading 7 pages to find out:
Ability to view -destroyed subobjects in PCS2. Maybe a checkbox that renders them instead of the live subsystems.
-
... How much is a good AC running these days?
It's too late now; the heat wave ended and I've implemented turret importing by subobject name. Now I just need to reinstall Visual Studio so I can build it for Windows.
If you want typed text in a dropdown box to stick, try pressing the down arrow so it'll find an option that matches.
-
You are so awesome.
-
Build updated.
-
Would that be possible to include radius editor in PCS2?
Currently, it's autocalculated each time on save, which messes up models which have radius modified by hand (mostly appearant with Steve-O's fighters that have sliding parts).
-
Or some way to modify the Radius so that it doesn't have to be hex-hacked afterwords.
-
I'm fairly sure this was an intentional design decision.
-
Can we get it un-intentioned? :nervous:
-
Yes, because its not stopping me from changing it anyway. :P
It's merely a minor inconvenience.
-
And for all the people who are happy with an auto-calculated radius?
-
And for all the people who are happy with an auto-calculated radius?
Leave them with the ability to generate an autocalculated radius but add the option to enter one manually so we can stop fixing it with a hex editor?
-
Have it do it's normal thing. But have an "unlock" button or something near it that you can click on to modify the values.
Have it pop up a "Are you f'ing kidding me?" window first if you like, so that it has to be a deliberate choice on the users behalf to do it, or something.
-
When you open up the same POF later, and resave it, how do you know what to use? An autogen or the existing value? You would probably have to override the setting every time you resave the POF to ensure nothing silly happens.
-
Uhm. It doesn't automagically recalc every single bloody time if there is a stored value, does it?
Because if there is no stored value, well, that's just crazy talk, because then what does the engine use? So it stores it. It should only ever calculate one in the absence of there ever being one (such as on an import from DAE). At which point, there is no conflict if there is already a stored value, and if manually enter a value in' that's the same thing because it's storing to the same location.
Or should be. Or something. Thanks, now my head hurts.
-
Yes but can't PCS2 make changes that would necessitate a radius update? I'm just not sure how that's currently handled even.
-
What the heck is this "radius"?
-
Radius is the radius of the model.
It controls stuff like the following distance of external view.
Just make it like MOI.
It'll always keep the value there, but you can tell PCS2 to recalculate it.
-
I'm not sure if that's a good idea... MMOI is something that's often forgotten; if the radius is forgotten, that will have even worse consequences.
On second thought... Maybe do make it like MMOI, but add a warning dialog on saving with a 0 value for either of them?
-
not do derail the talk of radius but:
this:
http://www.hard-light.net/forums/index.php?topic=74665.0
-
K. Radius. Have it still continue to do what it does. (Calculate one, that is) especially if it is importing a DAE. If it's already a POF, it should already have a stored value, yes? So it will load that.
But like MOI, you can either Recalculate it, or enter in your own values. Make sure it can not be accidentally done by having a lock/unlock button. See, even when you "Load" data from another model (like when you import from a Retail model) the Radius changes, but when you save it again, it goes back to the calculated one. But say you unlocked the Radius and then hit "Load", it should then replace that Radius with the imported or manually entered one when you hit "Save" (along with potentially a flag bit somewhere that registers it as a "Stored" rather than "Auto-Calculated" so that it won't attempt to auto-calculate it again if the bit is present). If you find you've made a mistake, re-open the POF (or PMF), unlock it, hit the recalculate button or even better, have a "Reset" button that clears the "Stored" bit and restores the "Auto Calculated" data by recalculating it.
Complicated? Perhaps. But not everybody knows where to go in the model with a Hex Editor to accomplish the same thing, and I'm pretty sure (Droid803 can confirm or not) that when set that way, it stays (as far as I know).
-
The radius (and bounding boxes) are recalculated every time on export to POF and when performing transformations.
The problem with an override is it wouldn't persist between PCS2 sessions.
-
If you go into the hex editor and set the radius, it stays that way, and you can see the set radius by opening it up in PCS2.
If you save it as POF again in PCS2, the hacked radius will be overwritten.
that's how it is right now.
-
Why wouldn't it persist? Is there a way to set a bit-field or something where it can?
-
There's nothing in the POF format currently to make it persist, as there's never been a need to override it manually. This is what I was afraid of. Still, even having a one time ability to override the saved radius could be useful, I think, even if it had to be redone every POF save.
-
On opening a POF, check if the radius in the file corresponds (+/- 0.001m or so, avoid floating-point round-off issues) to the actual radius of the model?
That way the program would know whether to use a custom radius or an auto-computed one.
-
The radius calculation has changed.
-
The radius calculation has changed.
Dōmo arigatō
-
Not in the way you asked for, but in the recent past it changed from containing the bounding box to just containing the model, which matches how it's done with most :v: models.
(And it's unlikely there'll be a new build until I get some feedback on the new bsp code (http://www.hard-light.net/forums/index.php?topic=73133.msg1479084#msg1479084).)
-
Radius override is in, but only in the new bsp build right now.
-
How easy would be it be to assign a keyboard shortcut to 'reload textures'? The more texture work I do.. the more I want to save on the mouse clicks when I load it back and forth to see what it looks like.
-
or just make texture reloads automatic.
-
So like, every time the window becomes active, check the filesystem for texture changes? That could work, like how Notepad++ or Eclipse or the like check for changes to text documents in the background.
-
Yeah.. that would pretty much make my day!
-
:bump:
Would it be possible to get the ability to alter a model's bounding box? (AKA, I want to make a model's bounding box larger than the model requires.)
-
manually setting bounding box ranges maybe? Just like radius editing?
I mean, you could always "cheat" by playing invisible polygons, but no one likes cheaters.
-
manually setting bounding box ranges maybe? Just like radius editing?
I mean, you could always "cheat" by playing invisible polygons, but no one likes cheaters.
Yeah, that's pretty much what I want. Basically the tech models for weapons don't yet have table flags to set the camera FOV like you can for ships. I just figured out that you can cheat this by offsetting the weapon tech model on the x(?) axis so it rotates around it's but and not its centerpoint. This pushes the radius out and forces the camera to zoom back.. but it is obviously and even bigger cheat than altering the radius directly.
Also, this method forces the select icon to be much smaller, which is not ideal. (That's why a table based FOV would be preferable)
-
i always hacked bounding boxes by inserting invisible geometry into the submodel.