Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Tools => Topic started by: DahBlount on July 30, 2020, 04:30:34 pm
-
In light of some recent discussion on the Discord, PCS2 and its current state needs to be discussed.
The PCS2 source code is, to put it lightly, in a pretty sorry state. Having not been actively developed in over 6 years, the libraries it uses are no longer maintained, so the likelihood of being able to continue development is fairly low.
Several ideas have been tossed around (a few being options in this poll) but with little action as it's not easy to come to an agreement. We would appreciate the input of as many people as possible.
-
Is there really overlap between PCS2 and QtFRED? I could see taking what was learned from QtFRED and moving PCS2 into the Qt ecosystem, but combining them all in one app seems a bit of a stretch to me. Perhaps even bringing the model editor directly into the FSO codebase, if there is enough overlap to warrant that making things easier or simplified.
-
PCS2 will exist no matter what we do, because it's easy to use, lots of modders edit their pofs using it and it's best tool for quick jobs like editing firepoints etc. It is not my workhorse for converting things, as I arrange lots of pof data in Blender, but I still use it frequently for small and quick editing. It's like Paint.NET to Photoshop for me. No need to roll destroyers to hunt a wing of Maras.
Still it makes me surpised, that mods like Aftermath: Reboot were made by using only PCS2 to edit assets o__O.
Ideally I would like to have a Blender addon, to make all pof data in Blender. I always forget some hardcoded object names and other stuff. I would like to have all the PCS2 options conviniently converted to Blender, so I can combine options of moving, rotating etc. with adding pof data.
But even considering the fact that Blender is "industry standard" of the HLP, not every asset creator use it and it will always remain quite complex for majority of community members, remaining effectively outside of their capabilities.
QtFRED seems to be too complex option too. I have no idea how many people use it instead of standard FRED and what options does it provide, but PCS2 and FRED are completely different things made for different purposes.
So to sum things up... I picked "Other" in the poll for Blender addon, but the most plausible option for the community will be fixed PCS2. Or... PCS3?
-
I think a dedicated app that moved into the FSO ecosystem and could borrow things like the F3 renderer and existing model code, and therefore be better kept up with updates to the model format, texture code, etc, would work well.
-
Honest question: Who is even using QTFRED? No one I know has mentioned using it.
I agree, PCS2 is it's own app, what it does has absolutely nothing to do with FREDing.
the most plausible option for the community will be fixed PCS2. Or... PCS3?
^^^^^^^
-
Honest question: Who is even using QTFRED? No one I know has mentioned using it.
*snip*
Nobody uses QtFRED because it's not finished yet. FRED2 will be going the way of the Dodo once QtFRED is at feature parity. The UIs are virtually identical, the main change is that FRED will be able to run on multiple platforms (ie. Linux, Mac, etc.).
We had a more indepth discussion on Discord and Chiefs ideas here:
I think a dedicated app that moved into the FSO ecosystem and could borrow things like the F3 renderer and existing model code, and therefore be better kept up with updates to the model format, texture code, etc, would work well.
seem acceptable to many people.
-
How much work would that take in terms of coding time actually?
-
Are you referring to Chief's idea or QtFRED?
-
Both actually. PCS2 won't stop to exist and works for many (if not pretty much all) things.
While everyone is free to suggest their opinion here, if one option would take much longer (like, hundreds of hours of free time) it might be something to consider.
-
I mean, we'd basically be gutting the existing PCS2 and integrating the model code from the FSO/FRED code into it, making a sub-directory in the repository (much like fred) where it will be compiled at the same time as FSO and FRED. I'd estimate that it'd probably be a few weeks to develop but that's any solution tbh. The only thing the FSO code doesnt have is functions to save to POF, which PCS2 already has. We'd also pull the DAE code from PCS2 and probably drop COB support because TrueSpace has been dead for over a decade.
-
I'm 100% behind that plan.
-
Sounds good to me. With the added advantage that since it's using the FS2 code, you should get less errors where something works in PCS but doesn't in FS2_Open.
-
Ideally, I'd like to see a plugin for rigging and exporting from Blender.
-
I vote qtfred integration, just less programs to keep track of from an end user point of view.
-
I vote for PCS3 that is independent from the FRED or Blender codebase. It's really important that beginners can modify texture references, weapon hard points, and other basic functions like the first FS modders did back in the '90s without having to learn Blender. And in terms of asset creation there is no overlap with what FRED is supposed to be doing.
What would be useful is integration with a text editor that could edit, audit, and/or generate .tbm entries in tandem with model editing. No more mismatched subsystem names! You create a new gun hardpoint in PCS, and the table entry is updated automatically. Every model already gets distributed with a table entry, let's see if we can edit the two in tandem.
Ideally it would use the FSO rendering engine so that texturing can be worked on and maps reloaded with a single click, without having to load FSO and the ship lab.
What's most important, in my opinion, is a robust error-checking system. The game has certain expectations for a multi-part turret, for example; PCS needs to have a template or macro to populate typical ship features, similar to the auto-pathing function, to get things working as the game expects with a minimum of trial and error required.
-
I vote for PCS3 that is independent from the FRED or Blender codebase. It's really important that beginners can modify texture references, weapon hard points, and other basic functions like the first FS modders did back in the '90s without having to learn Blender. And in terms of asset creation there is no overlap with what FRED is supposed to be doing.
QFT
-
I vote for PCS3 that is independent from the FRED ... codebase. And in terms of asset creation there is no overlap with what FRED is supposed to be doing.
You say this, yet you go on to mention a number reasons why it be far easier and better for everyone to integrate it into FRED. As you mentioned, having the FSO rendering engine would be excellent, so actually having it be a part of the FSO executable in some way would be ideal, since obviously you'd be a madman to try and and copy all that into a separate program. And if it's attached to something like FRED, or at least using the rendering and parsing your tables, then you have access to the table data and you can do all that error-checking and 'editing in tandem' you describe! So it seems like having it be attached to FRED is exactly what you're looking for. While on the surface it might not seem like they have much in common " in terms of asset creation" on the surface, we can see that under the surface the overlap is actually quite significant, and the fact that PCS2 lacks it is the cause of a lot of frustration.
-
Oh heck. Let's compromise and make blender a FRED extension!
Ok but seriously, using PCS2 requires the editing of table files, but FRED does not, so in terms of workflow, there is little benefit to linking them.
if it's attached to something like FRED, or at least using the rendering and parsing your tables, then you have access to the table data and you can do all that error-checking and 'editing in tandem' you describe!
What are you talking about? you can't edit tables via FRED. :wtf:
-
Of course not, we're talking about the future here, not the present. Don't get hung up on the current limitations, we're trying to enhance things here, remember? The basic idea is that, with integration, many of those things become possible. The alternative is a separate program which is basically the status quo, and while upgrades are definitely possible to PCS2, things like proper FSO rendering are basically out the window.
-
We already said we're not going to go all in and link it into FRED. The currently accepted suggestion only involves making a separate app that links with the FSO source code to reduce the total amount of code we have to maintain. FSO and FRED both link (in the compiler sense) a shared library as this reduces the total amount of code we have to maintain and provides cross-application consistency. Thinking of it as merely another program that resides within the project folder that happens to share code with FRED and FSO.
-
Looking forward to PCS..O?
:D
-
Betting on QtPCS :P
-
More like CutePCS
-
We already said we're not going to go all in and link it into FRED. The currently accepted suggestion only involves making a separate app that links with the FSO source code to reduce the total amount of code we have to maintain. FSO and FRED both link (in the compiler sense) a shared library as this reduces the total amount of code we have to maintain and provides cross-application consistency. Thinking of it as merely another program that resides within the project folder that happens to share code with FRED and FSO.
That does seem like a more sensible way to go about things to me too. It would have additional benefits too. If you're working on a variant Orion for instance, you'd have access to the original table file even if it's in a VP. I can see the ability to pull up stats from another ship being incredibly useful when you're deciding on hitpoints, etc.
-
Indeed. Obviously we'd go for parity with PCS2 first but stretch-goals would include things like turret and subsystem presets that would populate the fields you'd normally use with subobjects (FVec, UVec, and Dumb Rotate for example) or the ability to read/edit the table entry alongside the model.