Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: portej05 on May 21, 2009, 08:28:53 am
-
In tonights IRC, the issue of cross-platform FRED came up.
I've had a look through the code for FRED, and some of the code in 'code' that FRED depends on, and there seems to be a massive reliance on FRED being a windows application.
For example, one snippet of code I've seen is (note, only in a Win32 build and also that this seems to be peppered around a bit):
#ifdef WIN32
// FRED doesn't need this
if ( !Fred_running && !Is_standalone ) {
and the way FRED attaches the code rendering in the library is by using os_set_window((uint)this->GetSafeHwnd());
How much of a windows application is FRED really, what kind of reliance does FRED have with being on Windows, what is happening with wxFRED, and what is the future of FRED? (please don't take this the wrong way)
-
wxFRED is pretty much moribund. I don't think anyone has touched it in years. FRED is a Windows only application because it uses the Microsoft Foundation Classes (MFC) for its GUI. The idea of wxFRED was to move over to another GUI system in order to remove this unnecessary platform dependence.
The only reason it didn't work is that the SCP don't have enough coders with the willpower to actually do it. Once someone made a start on it the others would soon join in. Funnily enough (probably as a result of the same conversation) Wanderer was asking me earlier today if anyone would mind using QT instead of wxWidgets. Well I certainly don't mind. :)
-
It's not just that it uses MFC, but I was more interested in how much of an assumption that 'code' made on how FRED was put together in terms of the various bits and pieces.
-
QT would be a good choice of GUI handler package - it's quite nice to work with, and plays very well with Open GL.
However, porting any application to a different GUI handler is a pain in the proverbial, so it is not going to happen quickly.
On the other hand, once ported it would mean that a lot more people could work on the FRED code, as they wouldn't need MFC to compile it.
-
Personally I'd suggest migrating the standalone GUI first as a test. It's a lot smaller and thus would be a good thing to practice on.
-
Wanderer was asking me earlier today if anyone would mind using QT instead of wxWidgets. Well I certainly don't mind. :)
I would. :p I set things up so that wxWidgets is all set up and ready to go. Plus I got a whole bunch of tools to work with it. If I ever get a lot of free time available (like this past Christmas, except ST:R took priority) that's what I plan to work on.
Plus wxWidgets interfaces directly with the OS API, whereas I think QT is a wrapper API.
-
What tools are you using Goober?
Any cross-platform toolkit will have to wrap the OS API somehow - there's no way around it when they're so different.
-
What I meant was that wxWidgets is more of a "thin abstraction" to the OS GUI. (Check out the wikipedia pages or here (http://wiki.wxwidgets.org/WxWidgets_Compared_To_Other_Toolkits), for example.)
I have the DialogBlocks and ImageBlocks tools, as well as wxWidgets itself. There is also the wxFRED MSVC project all set up and ready to go within SVN. :D
Another major advantage of wxFRED vs. a hypothetical qtFRED is that wxFRED doesn't require the user to install any toolkits himself.
-
From the Qt page:
http://www.qtsoftware.com/products
Qt uses the native graphics APIs of each platform it supports, taking full advantage of system resources and ensuring that applications have native look and feel.
hmm, I dunno - my major GUI programming experience is with MFC, and a dabble in Qt, so I'm probably not the best to talk to about this! :P
-
Did you buy DialogBlocks?
-
Yes.
-
I don't care if you use QT, GTK or anything other.
Eveyrthing I want is just a finishend wxFRED or QTFRED.
If you feel confident enough, you should start work on making FRED usable on GNU/Linux then as Karajorma said:
The only reason it didn't work is that the SCP don't have enough coders with the willpower to actually do it. Once someone made a start on it the others would soon join in.
I'd love to use Linux FRED, because mostly the only reason that keeps me with Windows is FRED :(
-
shiv: The point is that FRED has to be completely rewritten in a different framework in order to work under linux/MacOSX.
We need to sort out which framework we're going to use before we commit any code.
Rewriting FRED is a big undertaking.
Goober: Is the current idea just to remake FRED, or could there be some input from the FREDder crowd into a new UI design?
Is the unlicenced/evaluation wxWidgets stuff enough to work with?
-
For now, the idea is to simply remake the existing FRED using the new toolkit -- a straight port. If people are interested in additional GUI features, there's nothing preventing anyone from making suggestions, but that's true even now in the MFC version. (Advanced features have been added in the past, such as subcategorization for sexps.)
The main thing to keep in mind for the new FRED is to double-check each feature as it's implemented. There are a lot of "horrifying lines of code" in FRED, and the more we can eliminate them, the easier FRED will be to work with in the future. One very important feature that needs adding, for example, is a proper Undo system.
WxWidgets, being open-source/freeware, already comes fully-featured; there is no evaluation version. There is an evaluation version of DialogBlocks, but it's more than sufficient for FRED until we get a large number of dialogs implemented.
If you have MSVC6, you can get started with wxWidgets right now using the instructions in this thread (http://www.hard-light.net/forums/index.php/topic,32815.0.html). They're a few years out of date, but should still work well enough to get started. There's also a large amount of groundwork already present in SVN. I'd be happy to have a chat with you via IRC or IM to get you up and running. :)
-
Does wxWidgets integrate with VC2008? Cause I seem to get mixed information on it depending on where I look.
-
shiv: The point is that FRED has to be completely rewritten in a different framework in order to work under linux/MacOSX.
We need to sort out which framework we're going to use before we commit any code.
Rewriting FRED is a big undertaking.
I'd love to help you, but I can't do much - I know only basics of C# language.
However you can count on me if you need suggestions or any Linux stuff help :)
May we talkon IM or IRC or something?
FRED for Linux is very important thing for me and many people would be thankfull to you if you help with making FRED work with Linux/MacOS.
And what about making FRED (even for Windows) rewritten? Installing QT libraries for Windows wouldn't be a big problem I suppose and we'd keep that way compability with every platform.
Anyway I don't know FRED2_Open source code so I don't want to say stupid things about it. So forgive me if I said something wrong.
-
The idea of going over to wxWidgets is that it would work for all three platforms. All that would be required would be a recompile on each platform, same as we do now for FS2_Open.
If QT does require an install of some sort in order to work (especially on Windows) then I'm against it. We already have enough PITA issues with OpenAL to go adding another one with QT if we don't need to.
-
There is an evaluation version of DialogBlocks, but it's more than sufficient for FRED until we get a large number of dialogs implemented.
This is the bit that worries me.
I don't know why you guys don't bundle the OpenAL dependency in the installer package.
-
It used to change quite often and we didn't want to overwrite newer versions with old ones.
-
I also reckon we've got a golden opportunity to redesign the UI, rather than just copy the UI
-
portej05, how can I contact with you?
-
Send me a PM or use the email address in my profile
-
Does wxWidgets integrate with VC2008? Cause I seem to get mixed information on it depending on where I look.
Dunno offhand, but then again I haven't had much time to research it.
I do know that DialogBlocks isn't necessary; it's just convenient. The whole thing is saved in text format anyway, using some XML format IIRC. It's not perfect, but it is usable. :)
If QT does require an install of some sort in order to work (especially on Windows) then I'm against it. We already have enough PITA issues with OpenAL to go adding another one with QT if we don't need to.
Strongly agree with this.
-
If QT does require an install of some sort in order to work (especially on Windows) then I'm against it. We already have enough PITA issues with OpenAL to go adding another one with QT if we don't need to.
Strongly agree with this.
QT doesn't need an 'install' as such, but it does need some external DLLs (or target OS equivalent). They are often simply copied into the application directory - no need for any registering etc that way.
Which ones depend on the feature set you need - under Windows QtCore4 is 1.5MB, QtGUI4 is 6MB, QtOpenGL4 is 372 KB and QtNetwork4 is 572 KB
I suppose the two core issues are really the OpenGL performance and ease-of-use.
-
Given that TBP final shipped with .dlls that haven't been needed by the engine for over 3-4 years you can see why I'm not keen on adding another layer for people to screw up with.
-
Given that TBP final shipped with .dlls that haven't been needed by the engine for over 3-4 years you can see why I'm not keen on adding another layer for people to screw up with.
That's poor dependency management, not a problem with using dependencies.
-
Yeah but the majority of time I've spent on solving problems for people has been on silly little issues like that or like the lack of OpenAL, etc. Just keep an eye on the SCP and support forums and you'll see how much time is spent on that sort of issue. I'm not keen to add another one to the mix.
The problem with FS2_Open is that not everyone upgrades at the same time. If we require QT for the launcher, FRED and stand alone GUI we've added three possible points of failure. Now take a look at the way advice is given on this forum and you'll start to see my problem with it.
Someone new comes onto the forum and reports having a problem with a mission they're FREDding. They get told that the latest FRED solves the problem. So they download it, and it crashes. They have to come back and explain that the solution didn't work. It could be a while before we notice that they had upgraded straight from FRED 3.6.11 to QtFRED. Especially if we point them at a nightly build (thereby skipping the official build with the QT .dlls in it).
And if anyone ever decides we need a feature from the newest QT version, the fun begins all over again. What I describe is not an isolated case either. You won't see it much around the time an official build comes out but as time wears on it will become more and more common. You'll see it the first time someone tries out the standalone too. And you'll probably still see it from time to time with the launcher in ways I can't predict but definitely anticipate seeing.
I know what I'm talking about here. I've done a LOT of support work on this board. It's the main reason I have such a large post count. And although I've largely passed the torch on to Lobo now I still know pretty well how easily something that seems as simple as including .dlls with the builds can spin out into a support nightmare.
-
My day job is support for software, hardware and custom systems, so I fully understand where you're coming from.
- Ever tried to troubleshoot a system where they can't even tell you what kind of hardware (PC/Mac/television/VCR/lightswitch) they've got? That's my daily nightmare.
I'm generally used to providing full-blown 'installers', that handle all the dependencies and updates for the end user - like adding MySQL ODBC links, Qt libraries, sound drivers etc.
Building it all into the executable certainly has appeal!
I suppose I just quite like Qt, and it's available under the LGPL - the licence for wxWidgets concerns me as parts of it are paid-for.
-
Parts of other application have often historically been paid for, then released as open source. IIRC, ogg got its start this way. WxWidgets is not exceptional in this regard. And the wxWidgets license qualifies as open source (it's based on the LGPL) as can be seen via a simple search.
-
Hmmm - so it is.
It's only some of the 'helper' apps that are paid for, not the libraries themselves. Doh!
-
Is anyone working on this yet?
-
I think the plan was to go stand alone GUI -> Launcher -> FRED so that we're solving problems in order of their size.
-
yeah, the plan is Launcher->FRED, and that won't start until after 3.6.10 has been released, the code analysis stuff has been fully processed and resolved, and mantis has been upgraded and checked through.
As far as the standalone GUI goes, we're still looking at whether that can be rewritten in wxWidgets given the structure of the code.
-
I'm not programmer, but once again: You can count on any other help with Linux stuff from me :)
-
Cheers Shiv, hugely appreciated.
-
Oh, it's just that I've got a few weeks to waste and it seemed like something interesting to try working on.
-
You can start already!
We do need UI concepts for the launcher and FRED
We do need UI mockups/interface design work done
We do need launcher backend design done
We do need library research done into WxWidgets to determine its suitability for this project (both launcher and FRED)
We do need some really good documentation on what FRED actually does :P (what it relies on, how it does things, etc) and also for the launcher (for example, I didn't know that FS actually reads its command line parameters from a file, or maybe that's just for debugging, or something!)
In short, we really need design work done atm.
In longer, anything you can contribute will be really appreciated.
Hope this helps!
-
Or if you wanted to do some actual coding, the following would be helpful:
1) Convert the standalone GUI from MFC to wxWidgets (it's a small enough task that it could be doable by one person in a few weeks)
or
2) Get DialogBlocks, and use it to create all the FRED dialogs.
-
The lack of a standalone GUI is the only thing preventing people from hosting standalones on Linux and Mac AFAIK so it's definitely worth getting done.
-
We do need UI concepts for the launcher and FRED
I know a bit of C# and I can design some concepts in Microsoft C# Express 2008 Studio that you can redo later in other programms. Is it fair enough for you?
-
I've had a bit of a look at the standalone stuff. It looks relatively straightforward to convert. Rather inconveniently wx by default uses the dll runtime but fs2_open does not.
-
Progress!
[attachment deleted by MSC
-
Yay!
-
Cool!
-
Wow! Sexy ;7
And I see you're using GNOME. Ubuntu? ;)
-
Ready to try testing:
Windows (http://www.cse.unsw.edu.au/~samm/fs2_open_3_6_11d.7z) Linux x64 (http://www.cse.unsw.edu.au/~samm/fs2_open_r.7z).
-
Worked fine for me. Only problem I had was that I could barely tell you'd done anything. :p
-
Posted (http://www.hard-light.net/forums/index.php/topic,64174.0.html) in multiplayer just in case multiplayer hosts aren't checking a thread on wxFRED.
For making GUI stuff it might be worth trying something like wxFormBuilder (http://wxformbuilder.org/) rather than using C#.
-
For making GUI stuff it might be worth trying something like wxFormBuilder (http://wxformbuilder.org/) rather than using C#.
Nice! This might be the solution versus using DialogBlocks.
-
Is the launcher code around somewhere?
-
It's in SVN.
-
I don't check in this thread for a while and there's progress :D
I've had a bit of a look at the standalone stuff. It looks relatively straightforward to convert. Rather inconveniently wx by default uses the dll runtime but fs2_open does not.
I'm going to have a look at linkage in the Antipodes branch at some point soon - statically linking everything is a recipe for disaster if components of the build are done on different machines (CRT incompatibilities, and mainly the memory allocation stuff).
This should help fix this problem.
-
launcher_settings.* and mod_settings.* appear to be missing.
-
I forgot to put them in SVN; they'll be added tonight.
But the Launcher code is a huge mess right now; it's not in any shape to be worked on. I'm in the middle of a massive rewrite.
-
:bump:
I was playing around a bit with UI concepts for a new FRED, and I came up with this:
(http://i659.photobucket.com/albums/uu320/FabianW/mockup.jpg)
Basically I would use an approach similar to VS2010 (where the base images were taken from), with dockable dialogs instead of the multitude of editor windows we have now.
-
Genius, man. I love the concept, and if FRED turns out that way, it'll enable more campaigns to finish more quickly--just because of the streamlined interface.
-
Well, there are other things that a new FRED should have built in. A script/tbl/tbm editor, for example. Way I envision it, you would start up FRED, and it would ask you what you want to do, a new mission, a new mission for a mod, or a new mod.
Doing a new mission would basically load the retail data (or whatever data is in the base directory) and continue as usual.
New mission for a mod would load that mod (using that mods mod.ini), and set the default load/save directories to that mods' missions directory.
New mod would Launch a Wizard that would allow you to basically define all the multimod stuff in the mod.ini.
TBL editing would only be enabled in the "New Mod" mode. Basically, you would click on the "TBL info" button in the ships editor (or weapons editor or whatever), you would then be able to make adjustments, and FRED would then automagically save the adjusted tbl as a tbm entry.
-
Sounds good indeed.
-
Although anyone that models FRED after a mickysoft interface should be bound, stuffed in a big lunch bag, and shoved in the vents.
-
Does anyone else feel compelled to shout "feature creep"?
I think a rework of the events editor would be helpful though.
I expect autohiding things could produce a rather trippy view.
On a tangentially related note, is anyone the least bit interested in a wx launcher?
-
As someone on IRC said (Hery, I believe), expanding FRED to give it more functionality would be a good idea from my POV. It would certainly make it easier for people to make mods.
Right now, FRED development consists of adding features to the existing dialogues, with the result that they become somewhat unwieldy. Not to mention that the main editor window becomes unresponsive when other editors are open, which can be a tad frustrating.
Redesigning FRED so that commonly used features and editors are easier to reach (Looking at you, events editor) without having to learn keyboard shortcuts is a good thing IMHO. Even if it means borrowing UI design concepts from Microsoft :P
-
Last time I tried any fredding, the main window worked without a problem with editors open.
The problem with the events editor isn't getting to it (<S-e> is a fairly obvious shortcut), but rather the time and effort required to manipulate events, which seems to be because of the necessity of using the mouse for it all.
-
Adding a text editor to FRED would be a great improvement. Edit the text, hit save, it gets error checked, and if passes loaded into the mission. Kind of like popping to notepad and editing stuff there but with a find to the specific item you are working on and without having to save the mission and reload the new one (although I'm pretty sure that is what would happen in the background)
Oh and while we're on features the ability to have more then one mission open and copy and paste between them would be another great feature.
-
Bear in mind that we're talking about more than simple UI changes if you want the events editor to work that way. Basically you're talking about completely redesigning how it works as you'd need some sort of undo option which the events editor currently doesn't have.
-
An undo option *would* be nice, even in the current event editor interface.
-
I'm not saying it wouldn't be nice. I'm saying it would require rewriting FRED almost completely.
-
...Assuming that it will consume the majority of the 3.6.11 dev cycle if this does go through, it'll be well worth it.
-
Assume that it will take all the SCP programmers the next couple of years and you'll be closer to the mark
-
Assume that it will take all the SCP programmers the next couple of years and you'll be closer to the mark
I'm not so sure about that long, but definately not an overnight thing.
-
Well the thing is that pretty much all the dialogues work modally even if they appear not to. If you update things in one dialog they won't be updated in any of the others until they are reopened (Due to the way FRED takes the actual data from the mission and stores it in temporary variables and arrays until someone closes the dialog again).
In order to make the system work in the way that is being suggested you would basically have to rewrite the code for almost every single dialog in FRED so that when you changed things the mission data held internally was updated instantly rather than when you press OK. Otherwise changes made in one dialog won't propagate to others. You'd also need to change the code so that when one dialog changes data all the others know to update themselves (They currently don't which causes problems when you do something in the Ship and Wing editors at the same time for instance). You'd probably also need to make a proper undo system that could handle reversing multiple changes.
Unless we drop everything else to rewrite FRED we're probably talking about a couple of years cause people will keep wandering off to add new features and fix other bugs.
-
I'm not sure we're talking about porting any more - it may be just as much effort to port as to totally rewrite.
Also, given that I've seen some folks who'd like some level of integration with other tools we're probably not able to keep all the current architecture (or lack thereof!)
-
Some thought about what Fred can be a bit frustrating with time is :
Having the backward move button act like the other one in Fred would be a good thing too because for now you have to push it several time to do that, maybe adding a movement system like in 3dsmax (alt+middle mouse and mouse move to rotate along a target, middle mouse button rotation for zooming too) should improve the Fred's experience a lot.
-
I'm not sure we're talking about porting any more - it may be just as much effort to port as to totally rewrite.
It's certainly feeling that way.
Is there a proper specification of the mission and campaign file formats anywhere?
If not, writing those up would be a very good place to start.
Having pulled one apart in a text editor, it looks like the formats are actually pretty simple.
Therefore the kinds of extra features this thread has been talking about will almost certainly be considerably easier in a ground-up rewrite than trying to re-jig the existing mess.
(Undo stacks in particular simply aren't feasible with the current architecture - in most cases, Undo has to be designed-in from the start.)
Thus the discussion should turn towards a new architecture, ensuring it is easily extensible and is based around a well-featured Undo stack.
-
I'm not sure we're talking about porting any more - it may be just as much effort to port as to totally rewrite.
When people say stuff like that it REALLY worries me. Either I'm hugely underestimating the effort involved in a GUI port (And I do think it's a major effort!) or everyone is massively underestimating the effort required to rewrite FRED from scratch.
But okay, let's take what I see as the biggest issue I have with a rewrite, the new Undo stack. If you can give me a plan that seems workable I'll be a lot more confident that this plan actually could succeed. So how would it work?
-
But okay, let's take what I see as the biggest issue I have with a rewrite, the new Undo stack. If you can give me a plan that seems workable I'll be a lot more confident that this plan actually could succeed. So how would it work?
Probably buggily.
-
When I say rewrite, I mean avoid using code from 'code' which fred was basically hacked around.
I mean a properly designed mission editor.
I can't see an undo stack working in any way with the current architecture of 'code' and FRED
-
How much of 'code' are you thinking of getting rid of?
-
At its simplest, Undo is a list of the 'old data' prior to each change.
- This essentially requires that every edit be routed through the 'undo' buffer handling function.
The list is cleared on Load, and is added to each time an edit is made.
It's usually a circular buffer to limit memory usage.
More advanced (allowing Redo) means storing both Old and New data for each change.
-
See the problem (which I brought up on IRC) is that FRED uses the same project as FS2 does. So when the editor wants to make a wing it simply runs through the code FS2 uses to make a wing.
Which means that either you run the FS2 code through the same function or write completely different code for the new version of FRED.
-
Thanks - that explains a lot.
I think that FRED actually needs completely different code for the vast majority of the functions.
FS2 takes the various files and transforms them into an efficient ingame representation. The inverse of that transformation is not required for the game to run.
FRED takes the various files and user input to produce new versions of the files.
There's not really very much overlap between the two - in fact, the only overlap is that both of them need to load the files.
Even that isn't as much of an overlap as one might think, as an efficient editing representation is different to an efficient in-game representation.
- For example, FS2 needs to process the 'meaning' of SEXPs, while FRED merely needs populate and edit a tree of them.
FRED doesn't actually care what they do, only that they meet defined rules for chaining and stacking. It's actually pretty trivial to build an Event editor if you ignore what they do - for the most part, it's just a nested list of stuff.
If FRED uses the same internal representation as FS2, it makes it much harder for FRED to do things like copy, paste, delete and move them, and it has to come up with some way of exporting the result - because FS2 never has to do any of that. Thus, bugs in FRED are likely to come as a result of fixes and improvements to FS2.
-
I don't think it does. The problem with cutting, pasting etc has never been due to the code FS2 and FRED share so much as the fact that FRED needs to be able to type check the entire tree on every single cut and paste to make sure that it is still valid.
If you start ignoring that you basically end up with an events editor that could be replaced by simply typing in notepad and that's pretty much pointless.
There's a lot more overlap than you think. Both FRED and FS2 need to be able to parse the code, check that the return type of the SEXP is correct, check that the return type of the arguments are correct, check that there are the right number of arguments, etc.
The actual code that the SEXP executes when it is run in game isn't needed by FRED but it doesn't affect FRED in the slightest either.
But if you divorce FRED and FS2 you then add the danger of them getting out of sync. And you introduce bugs that way.
-
I don't think it does. The problem with cutting, pasting etc has never been due to the code FS2 and FRED share so much as the fact that FRED needs to be able to type check the entire tree on every single cut and paste to make sure that it is still valid.
Something that the FS2 code doesn't support too well?
It's all about the meta data :P
-
If you don't check that stuff you end up with a mission where the SEXPs are gibberish so I don't see what the problem is.
-
I'd prefer a text input system with nice auto-completion, but I don't really do any fredding these days...
One thing that hasn't really been mentioned with regard to undo is what would be undoable. Would camera movements be included for example? How granular would it be?
-
I don't think it does. The problem with cutting, pasting etc has never been due to the code FS2 and FRED share so much as the fact that FRED needs to be able to type check the entire tree on every single cut and paste to make sure that it is still valid.
Which is basically my point - that kind of sanity check is best done with a rulebook and the tree, not by trying to run it (and dying).
Your last point is the crux of course - that rulebook has to be gleaned from the FS2 code because otherwise it's a pain in the proverbial to maintain.
At present I don't understand the interrelationship very well so I'm not sure how easy that is to do.
Regarding Undo:
As a point of architecture, we should assume that everything should be possible to undo, then make specific exceptions. Filtering stuff out within the Undo stack is much easier than filtering stuff in!
The granularity for all movements should obviously be that a 'step' is the time between mouse-down and mouse-up. (Same as for Photoshop et al)
However, to do that pretty much all of FRED-specific code has to be redone.
- For me, step one is Learn C++, as I'm currently a Delphi programmer.
I do need to learn C++ for work anyway, so I'm intending to try part of this (an Events editor) as a learning project.
To help with that, I'd greatly appreciate it if someone can point me to (or write) a spec for the Events section of an FS2 file.
-
To help with that, I'd greatly appreciate it if someone can point me to (or write) a spec for the Events section of an FS2 file.
Just open one up in Notepad (or whatever you use) and search for $Events:
I think that's what it's under anyway.
-
#Events not $Events.
Which is basically my point - that kind of sanity check is best done with a rulebook and the tree, not by trying to run it (and dying).
But that's pretty much what FRED actually does. It has a list of what types of argument the SEXP should accept as well as what it returns and it simply checks that everything matches. If it doesn't it simply decides the SEXP is invalid and resets it to whatever you had before.
-
#Events not $Events.
Which is basically my point - that kind of sanity check is best done with a rulebook and the tree, not by trying to run it (and dying).
But that's pretty much what FRED actually does. It has a list of what types of argument the SEXP should accept as well as what it returns and it simply checks that everything matches. If it doesn't it simply decides the SEXP is invalid and resets it to whatever you had before.
Ah, that means I'm being a muppet on that section then, and it should be much easier to reboot FRED than I thought.
(I obviously have much more to learn about C++ than I thought. Transferring from Delphi is more difficult than I'd initially believed.)
Just open one up in Notepad (or whatever you use) and search for $Events:
That gives me examples, not a specification. Reverse-engineering from examples maens that you never know what is actually permitted.
I'm not a good enough C++ programmer yet to be confident of being able to reverse-engineer from the existing parsing code, although I'll be giving it a go later.
-
Kara: As far as I can tell, the way it determines whether a sexp is valid or not is to run it through the same check that FSO applies to sexps.
I don't agree that it would be the maintenance nightmare you think it would be to maintain a 'rulebook'/meta data on the sexps that FSO has. It would also provide a framework for significantly better documentation than there currently is (I'm looking at you Operators or whatever it is that decided not to show my extension to show-subtitle because the text box is limited without scrollbars).
I'm sure that the code could actually be significantly simplified over what it is currently (sexp insertion in fred is a mess - I tried to work through the whole sexp_tree and events dialog recently and gave up).
FRED2 was designed constructed to provide the Volition crew with an easier way to develop missions than with notepad - it was never designed as a general purpose mission editor, hence the heavy use of FSO functions which make things slightly more difficult from the editing architecture view point, but which sped up the development.
I'm also guessing that FRED2 grew out of whatever tool they used on the original project.
My $0.02.
-
Kara: As far as I can tell, the way it determines whether a sexp is valid or not is to run it through the same check that FSO applies to sexps.
I don't agree that it would be the maintenance nightmare you think it would be to maintain a 'rulebook'/meta data on the sexps that FSO has.
I don't see how that would be any different to what we have now to be honest. The parsing code needs to be able to read a SEXP from a mission file in both cases so that really has to stay pretty much the same for both.
As for validity checks during mission editing, those are handled mostly by a set of rules which are also used during parsing. So the rulebook already exists. I don't see how it would help to cut out that rulebook, paste it somewhere separate from the one FS2 uses and say that it's an improvement.
It would also provide a framework for significantly better documentation than there currently is (I'm looking at you Operators or whatever it is that decided not to show my extension to show-subtitle because the text box is limited without scrollbars).
eh?
I'm sure that the code could actually be significantly simplified over what it is currently (sexp insertion in fred is a mess - I tried to work through the whole sexp_tree and events dialog recently and gave up).
At which point I've got to ask what the hell you were doing. I've added over 30 SEXPs and I've had to edit sexp_tree.cpp to do it about 3 times in total. I've certainly NEVER had to touch the events dialog in order to do it, nor should I have to.
-
I don't see how that would be any different to what we have now to be honest. The parsing code needs to be able to read a SEXP from a mission file in both cases so that really has to stay pretty much the same for both.
What if we didn't actually use a mission file here - what if it used a custom format that was more applicable to an editor, and then exported to a mission file format?
You separate the mission file format from the actual data that defines the mission, resulting in more flexibility in that path.
The rule set we currently use is not a pretty thing. query_operator_return_type and query_operator_argument_type are just inviting trouble.
At which point I've got to ask what the hell you were doing. I've added over 30 SEXPs and I've had to edit sexp_tree.cpp to do it about 3 times in total. I've certainly NEVER had to touch the events dialog in order to do it, nor should I have to.
Someone is going to have to look at it sometime soon for any cross platform issues that crop up in a cross platform FRED. Which means someone is going to have to sit down and understand it.
-
I don't think this is going to go anywhere until someone actually comes up with a detailed alternative.
-
There doesn't seem to be a huge drive for a detailed alternative other than a port of current FRED.
-
What if we didn't actually use a mission file here - what if it used a custom format that was more applicable to an editor, and then exported to a mission file format?
eh? How would you ever edit an existing mission without having FRED able to open a mission file?
-
eh? How would you ever edit an existing mission without having FRED able to open a mission file?
Import it (would not be a complex process, would be one click, just like opening a file of a different format).
-
Are we talking of a purely internal format, or one that is written to disk? The latter will probably cause issues, while the former might be a good idea.
-
Why would the latter cause issues - it would be a representation of a mission or a campaign, and could include significantly more data in it than we can within the .fc2 or .fs2 file formats. Simply exporting it to a mission should not present issues for users.
-
So every time the FREDder wants to test something he has to export the mission for FS2 to run it? That makes no sense.
-
eh? How would you ever edit an existing mission without having FRED able to open a mission file?
Import it (would not be a complex process, would be one click, just like opening a file of a different format).
Which gets us right back to needing the same parser FS2 has (at least currently) and introduces all kinds of problems caused by losing the FRED version of the file if we don't keep updating the parser.
-
This thread has gone from the practical to the esoteric to the downright bizarre. A new internal file format, for goodness sake? :confused:
Keep in mind that the last FRED overhaul stalled despite being attempted by the best coders in the SCP. And now we have a bunch of proposals from some members with a few dozen posts and no SCP badges. So I'm highly skeptical that anything planned here will work. I would love to be wrong, because every now and then a newbie comes along and surprises everybody (c.f. Blaise Russel) but that's the exception, not the rule.
Has anyone here actually done any wxWidgets doodling or code experimenting?
-
Has anyone here actually done any wxWidgets doodling or code experimenting?
To be honest, I'm looking at Qt much more closely now - it's the framework we use at work, so I can justify playing with it on company time.
The Qt Creator IDE looks to be pretty good, and is both cross platform and free.
- Yes there are dependencies, but there must be a good way to handle that.
I've done a bit of poking into building a straight events editor, and that looks to be reasonable including an undo stack.
I'm still missing the file format specification though - and that's something I can't do alone.
- I'm now making a start in FS2 Mission File Format (http://www.hard-light.net/wiki/index.php/FS2_Mission_File_Format) in the Wiki.
portej is absolutely right about using a different internal representation for editing.
- Being able to save that internal representation isn't necessary, but could be useful. For example, one could save the workspace layout, the undo stack etc.
Anyway, back on topic:
Undo pretty much requires that you build the editing program around the Undo stack - bolting one in afterwards is almost impossible. (You'll almost certainly break something)
I'm considering using the FS2 text files as the internal representation, with each individual editor in the new package pulling out the bits it needs, playing with them, and then putting them back.
I'm looking at using the built-in Qt Undo (http://doc.trolltech.com/4.5/qundocommand.html) framework.
- The only question is how many descendents of QtCommand are required.
I'm guessing that we probably only really need EventTree and Text.
- The EventTree change handles the essentially tree-structure of Event.
Text is obvious, it just neds to keep track of edits to the raw lines of text, properly grouped together into 'related' changes.
-
I'm still missing the file format specification though - and that's something I can't do alone.
- I'm now making a start in FS2 Mission File Format (http://www.hard-light.net/wiki/index.php/FS2_Mission_File_Format) in the Wiki.
Well, I expanded that page a bit. Still needs more documenting and there are probably a few things I've missed.
-
To be honest, I'm looking at Qt much more closely now - it's the framework we use at work, so I can justify playing with it on company time.
The Qt Creator IDE looks to be pretty good, and is both cross platform and free.
Well, doodling is good, but we're not planning on using Qt because a) there's already a decent start at wxFRED and a lot of SCP documentation on wxWidgets; b) wxWidgets is a transparent dependency.
- Yes there are dependencies, but there must be a good way to handle that.
Well, you anticipated one of my objections; that's a positive sign. :)
One very important reason we're using wxWidgets is because you can embed/link the wxWidgets library in the wxFRED executable. You can't do that with Qt; Qt requires that you install a framework or runtime environment. Given how much trouble we already have with one dependency, namely OpenAL, we are emphatically not going to add another one.
I've done a bit of poking into building a straight events editor, and that looks to be reasonable including an undo stack.
Ok.
I'm still missing the file format specification though - and that's something I can't do alone.
- I'm now making a start in FS2 Mission File Format (http://www.hard-light.net/wiki/index.php/FS2_Mission_File_Format) in the Wiki.
I don't think there was ever an official mission specification. It's one of those things that's its own standard.
Anyway, back on topic:
Undo pretty much requires that you build the editing program around the Undo stack - bolting one in afterwards is almost impossible. (You'll almost certainly break something)
I completely agree with this. In fact that would be one of my top two design priorities if FRED were to be rebuilt. (The other priority would be correct handling of embedded comments.)
I'm considering using the FS2 text files as the internal representation, with each individual editor in the new package pulling out the bits it needs, playing with them, and then putting them back.
Hmm, that's starting to make a bit of sense. That would help with the commenting system too.
I'm looking at using the built-in Qt Undo (http://doc.trolltech.com/4.5/qundocommand.html) framework.
WxWidgets has something similar (http://docs.wxwidgets.org/stable/wx_docviewoverview.html).
Anyway, what sort of code qualifications do you have?
-
One very important reason we're using wxWidgets is because you can embed/link the wxWidgets library in the wxFRED executable. You can't do that with Qt; Qt requires that you install a framework or runtime environment. Given how much trouble we already have with one dependency, namely OpenAL, we are emphatically not going to add another one.
It is in fact a damn good reason to develop an installer/updater, but it is not a good reason to statically link everything.
Statically linking things is not a good idea unless the system is never going to change (i.e. embedded systems).
EDIT: Additionally, the way your response reads suggests that there hasn't been an evaluation of framework alternatives, rather that it was a case of `this one statically links'.
(The other priority would be correct handling of embedded comments.)
That appears to have been a hack to start with.
-
It is in fact a damn good reason to develop an installer/updater, but it is not a good reason to statically link everything.
Statically linking things is not a good idea unless the system is never going to change (i.e. embedded systems).
I assume this references your thread in the internal. :p But isn't that taken care of if all releases are built from scratch, i.e. no release build is ever linked with a wxWidgets library made on another computer?
EDIT: Additionally, the way your response reads suggests that there hasn't been an evaluation of framework alternatives, rather that it was a case of `this one statically links'.
I haven't evaluated Qt personally, but you and karajorma had an extensive discussion on this recently.
-
An example rulebook for sexps (note: this is not complete by any stretch of the imagination, is not valid XML (reallyreallyreally dumb writer) and doesn't handle argument types just right yet), but it took 40minutes to produce, and could be done automatically now.
[attachment deleted by Tolwyn]
-
Anyway, what sort of code qualifications do you have?
In C++, sweet FA - just starting to learn it, transitioning from Delphi.
I've been building and maintaining (primarily) in-house applications in Delphi for a few years, but have now come to the decision that I need to change to C++ as Delphi is no longer widely supported.
So I'm partially looking for challenges to force me to learn, as the stuff I'm maintaining at work is in Delphi and there's no point in porting it.
portej - loving your (not!)XML. Entities? We don't *need* no stinkin' entities!
I fixed the > and < SEXP entries for you - attached - so it'll open in any parser.
More seriously, that looks easily usable as either a 'compiled in' or 'load at runtime' datafile.
- The latter would allow FRED to be updated to have new SEXPs without recompiling, the former removes the need to distribute the file.
[attachment deleted by Tolwyn]
-
I haven't evaluated Qt personally, but you and karajorma had an extensive discussion on this recently.
We didn't discuss it that much but as far as I'm concerned the decision has been made already an it was wxWidgets. Spicious has already ported the standalone GUI to wxWidgets. The new launcher is wxWidgets. It would be pretty odd to make the project dependant on two different GUI toolkits (thereby requiring coders to learn both) without a pretty damn good reason for it.
So far I haven't heard one of those and the fact that we'd have to require users to install a framework of some sort or add .dlls is a huge black mark against Qt.
-
It would be pretty odd to make the project dependant on two different GUI toolkits (thereby requiring coders to learn both) without a pretty damn good reason for it.
Hmm, another good reason. I danced around it but didn't quite realize it. :)
-
portej - loving your (not!)XML. Entities? We don't *need* no stinkin' entities!
I fixed the > and < SEXP entries for you - attached - so it'll open in any parser.
I did warn ya :P It was more proof of concept than anything else. If I was doing it seriously I would have used a proper writer, not just cout << "<sexp " :)
I set myself a challenge of 30mins to get to that result, it took only slightly longer, but getting an XML framework in there would have taken longer.
More seriously, that looks easily usable as either a 'compiled in' or 'load at runtime' datafile.
- The latter would allow FRED to be updated to have new SEXPs without recompiling, the former removes the need to distribute the file.
That is the entire point. It needs a fair bit lot more work before it gets to that point, but otherwise that's the aim.
-
What I'm not getting is why this system wouldn't work for both FS2 and FRED?
-
It's likely that this would not be anywhere near as efficient enough - it's still an idea in progress, it's nowhere near ready for thinking about getting into the engine.
The best example of this is that I haven't figured out how to handle the arguments yet - the OPF series vs the OPR series for nested sexps - if this was a totally clean approach there are some neat ways to do it, but this isn't a totally clean approach.
But can you see how much simpler the code would be - the amount of data stored in the code would be massively reduced with this kind of approach.
-
It would be pretty odd to make the project dependant on two different GUI toolkits (thereby requiring coders to learn both) without a pretty damn good reason for it.
Hmm, another good reason. I danced around it but didn't quite realize it. :)
YAL is Qt, and at present it looks like it's working fine under Windows and Linux, possibly with a few issues under Mac OSX still to be corrected.
(I lost track of the threads on the Mac support)
Right now, there's a standalone running in wx, and that's it. The standalone was ported multiplatform first as it's stated to be relatively easy. (As far as porting ever can be)
For me, there are two core reasons for going to Qt:
1) There's already a released free, LGPL licensed cross-platform RAD IDE that everyone in the community can use.
This means we only need to support a single project file for all platforms and all community members.
2) The IDE and Qt framework is widely used in commercial software.
Thus many community members can justify learning it on company time, and there are many commercial entities paying for the framework to be maintained and supported.
Oh, and Qt 4 can be statically linked if you want, with the '-static' flag. I think this is a relatively new option though.
-
For me, there are two core reasons for going to Qt:
1) There's already a released free, LGPL licensed cross-platform RAD IDE that everyone in the community can use.
This means we only need to support a single project file for all platforms and all community members.
There're even plugins for VS that make things a little easier.
There isn't a good, free IDE for wx.
The only odd thing to get used to is the MO Compiler (moc), but that's just a prebuild step.
2) The IDE and Qt framework is widely used in commercial software.
Thus many community members can justify learning it on company time, and there are many commercial entities paying for the framework to be maintained and supported.
It's also got Nokia behind it, and the commercial use aspect is certainly appealing.
Oh, and Qt 4 can be statically linked if you want, with the '-static' flag. I think this is a relatively new option though.
Please, NO!
I've outlined static linking and my objections to it before (mainly on the internal thread), and most of the issue revolves around linking with other libraries (think what happens when a prebuilt component is distributed built against a different CRT to the one you're building against and you allocate and free memory between them), which is VERY likely to occur.
-
What I'm not getting is why this system wouldn't work for both FS2 and FRED?
The real reason is that FS2 needs to know what the SEXP means - how to evaluate it, and how to handle the effects of a SEXP becoming true.
At present this has that massive CASE statement at its core - very efficient when comparing against constants, but quite slow if it compared against a runtime-generated SEXP array.
So FS2 should stay with the constants.
However, FRED does not care what a SEXP means - it's not a simulator.
In fact, the XML style portej just suggested would allow FRED to load a different "SEXP-FLAG" config file depending on the target.
- So you could use the same build of Fred for "Retail", "3.6.10" or "3.6.11alpha" depending on the target FreeSpace2.
This would mean that you could use a 'newer' build of FRED (with associated bug fixes) to create missions for older FS2 versions, without needing to know what is and isn't supported by that version.
Right now, we have to release new builds of FRED with every new build of FS2 Open, which feels very clumsy.
portej's suggestion removes that need, as only a small configuration file required to 'update' your FRED.
Thus new builds of FRED are only required when features/bugfixes specifically for FRED become available - the shared bit would be POF code.
The prerequisite for this is the ability to quickly and easily generate that config file - portej appears to have (almost) solved that problem now.
Oh, and Qt 4 can be statically linked if you want, with the '-static' flag. I think this is a relatively new option though.
Please, NO!
I've outlined static linking and my objections to it before (mainly on the internal thread), and most of the issue revolves around linking with other libraries (think what happens when a prebuilt component is distributed built against a different CRT to the one you're building against and you allocate and free memory between them), which is VERY likely to occur.
I don't like it either, just saying that it's possible!
Installation of the Qt libraries is simply a case of copying the required Qtxxx.dll files into the same folder as the executable.
It doesn't need to be registered like OpenAL did.
I've done a bit of testing with 'breaking' installations, and the error messages I got were excellent:
"The application failed to start because QtCore.dll was not found. Reinstalling the application may fix the problem."
So the support is pretty easy.
-
Installation of the Qt libraries is simply a case of copying the required Qtxxx.dll files into the same folder as the executable.
i.e. provide an installer/updater with FRED :P
It doesn't need to be registered like OpenAL did.
OpenAL needs to be registered?
I just copied the two dlls into the same directory as FSO (on my new windows installation).
-
In fact, the XML style portej just suggested would allow FRED to load a different "SEXP-FLAG" config file depending on the target.
- So you could use the same build of Fred for "Retail", "3.6.10" or "3.6.11alpha" depending on the target FreeSpace2.
This would mean that you could use a 'newer' build of FRED (with associated bug fixes) to create missions for older FS2 versions, without needing to know what is and isn't supported by that version.
Oh, This I really like. Would go a long way toward building a kind of "FreeSpace Studio" application.
-
Funny cause I absolutely despise it.
Having the same version of FRED support different SEXPs depending on an external file is a recipe for disaster.
-
Okay, this is going to come out as overly hostile. I apologize in advance for any hurt feelings.
The way I see it, there are currently two initiatives going on. One is to build a replacement for FRED that uses wxWidgets and is cross-platform. A good idea, and worth pursuing, but I and other people feel that there is a missed opportunity here, as well as some concerns about the choice of Framework. wxWidgets does not have a free IDE that allows WYSIWIG editing of the interface, which at least for me is a major drawback.
What I and a few others would like to do is to build a sort of FS IDE, which offers a unified interface to all aspects of FS modding. And frankly, you and Goober naysaying every idea and concept that is developed for this is not helping.
I'm fully aware of your history of working on this project, but why don't you let us work on it, and see what works and what doesn't.
-
Don't you find it telling that the two people doing the most naysaying are the two who know FRED the best?
I dislike this idea because it means more work for me to add SEXPs. I dislike it because it is a support nightmare (support via a text file for FRED can easily result in people having up to date FS2 builds which then crash out horribly as soon as you try to open the same mission in FRED). And I dislike it because it is a massive amount of work for what will end up as a pretty minor gain when all is said and done. Time that could have been spent on much more important things.
On top of which the whole "Shut up if you don't like it" thing doesn't work when you're talking about something that would have major implications on the entire project. Especially as the two people you're telling to shut up and let you divorce the code and FRED projects are the ones who would end up having to work on the newly split version once it was done.
-
kara: Remind me to add versioning to the list of requirements.
-
We're currently in the phase where we're tossing ideas and concepts around. And again, this is a new project, which is separate from FRED.
At this point, we're not saying that FRED needs to (or even should) be replaced completely by it, we just want to build something that does everything that FRED does, and a little more. Integrating this as seamlessly as possible into the FSO project is pretty high on the list of priorities.
-
I think you guys need to cool down a bit.
/me pours some cold water on the topic
While I'm no coder, I'll still say that portej05 and rest of his merry folk can start their new ambitious project if they so want. You can criticize the project all you want but please refrain from inflammatory posts. In fact, I encourage criticism as it often brings about real issues that needs to be dealt with. If they pull this off, we will have really awesome tool in our hands. If they fail, nothing except their personal time they used to work on the project is lost. Even then, they have learned much from it and can carry that knowledge on to other projects, such as the good 'olde fred2_open.
When it's all said and done, it's the community that chooses what tools they use. If this new project proves its worth, that's what the community will move over to. If not, the community sticks to fred2_open. Alternatives, diversity and different philosophies can be an asset in the long run.
And my 0.5C concerning wxwidgets vs. qt. Whichever has the better IDE(s) and costs less should be used and that seems to be qt. On that note, whatever you guys work on, please try to ensure it will compile on Visual Studio Express as it is yet another major cost factor. The less money required, the more potential coders we can get and less issues with outdated VS like VS6.
-
(In the following post, there may be statements of irrationality or so common sense that they are tacitly understood. Comment on the irrational bits, but don't point out the tacitly understood points just to say that they are already understood.)
FRED is _sort of_ possible in VS'08 Express.
Unfortunately, it's a bit complicated and requires adding more things into the SVN that would need to be maintained and is essentially static linking.
Granted, it's ATL/MFC support which _shouldn't_ be seeing too many updates, but even still, it would be a pain in the ass to implement and god help if it ever decides to barf all over itself because something in /code changes.
Myself, while I'm not the most rational of people, believe in the following:
Whatever version of "FRED" gets made should be supported within the existing compilers, including the free Express editions. I don't feel like adding yet another IDE, SDKs, etc to my system and I don't think it's fair that we make new and interested folk have to go through doing it either.
That being said, I realize fully well that said task as above may not be entirely feasible. Therefor, whatever alternative is selected should be as hassle free, self contained and as free for anybody to get and use as possible. If I have no choice _but_ to have to utilize another IDE, I want the impact to be as minimal as possible, not just because I'm lazy, but because being able to provide support and assistance to others will be easier to accomplish.
I like there being alternatives and different perceptions on approach. Sometimes, as Kara pointed out, these are not always optimal especially if you are in a position that it may force you to relearn a system you have already established and know better than anybody will ever know you.
And I definitely see the point in having anything externalized that requires constant maintenance. As already stated, a recipe for disaster there. So make sure the system has some way of being able to invisibly (and securely) update itself.
As far as I am gathering, the two ideas are thus:
1: Portability of the existing FRED as it stands to working on other platform OSes. Then maintain the cross compatibility while working in new features before addressing any feature UI changes or adjustments (eg: Undo). Preferably the goal is to also make it so that it can compile in other OSes as well. Contenders on the IDE are wxWidgets and QT, is there any VS possibility?
2: Starting with the UI and the underlying end-result concept, draft a new FRED-replacement that does what the current FRED does, but starts out already being cross platform (hopfully, otherwise what's the smegging point?) that can incoperate as well additional features not already present (again, such as Undo). wxWidgets and QT also present as alternatives here, again a question of VS support possibilities.
So, what terms do both of these have in common?
Final product to be Multi-platform/OS capable. Must offer the same features across the builds as well as optimally, the same UI presentation to make work migration betwixt them easier.
Compilation under one IDE. _Which_ IDE seems the current hot-collar topic, so it'll just be plainly stated here without digression.
Must support all current capabilities as existing FRED (or at the very least, Retail Fred to start with from a Proof/Beta Release) Porting FRED makes this one a lot easier to achieve in some respects, only because the features are already there, but it's still no walk in the park. A new project/code base has a lot of catching up to do.
Learning curve of the final release product. The Exe itself. Many people are already familiar with the existing FRED interface. Many folks use the keyboard shortcuts as naturally as breathing by now, probably. But there may also be just as many people (and the two camps are not exclusive of each other) that feel that things could be laid out better or be more visible/easier to access/etc. But a completely stark new interface may be completely over-whelming if it doesn't carry over any common elements.
I see, from where I'm sitting, a dead heat between the pro's and con's for both positions. And ultimately, what I'd like to NOT see, is either position becoming mutually exclusive of the other. We're not working cross-purposes here, even with the ideas being in (apparent or perceived) conflict of each other.
-
When it's all said and done, it's the community that chooses what tools they use. If this new project proves its worth, that's what the community will move over to. If not, the community sticks to fred2_open. Alternatives, diversity and different philosophies can be an asset in the long run.
Unfortunately it's not quite that simple. Suppose this new IDE gets built and it's just as big a PITA as I suspect it will be. Now suppose I want to add a new feature to FS2. I do that, then I added it to FRED. Now I have to go and add it to this program as well.
What I can quite easily see happening is one program lagging behind the other or worse, both having different compatibilities with different features. We've spent the last few years trying to get away from the 3.5.5 nonsense where we continually had to tell end users to use recent builds in order to get around basic problems. I'm certainly not keen on seeing a return to that kind of stupidity. Especially if we inflict it on ourselves.
Which is why I think an approach that results in only one tool is the sensible one.
-
wxWidgets does not have a free IDE that allows WYSIWIG editing of the interface, which at least for me is a major drawback.
http://lmgtfy.com/?q=wxwidgets+rad
What I and a few others would like to do is to build a sort of FS IDE, which offers a unified interface to all aspects of FS modding. And frankly, you and Goober naysaying every idea and concept that is developed for this is not helping.
They all seem to be horribly infeasible in ome way or another.
-
Spicious: Better would have been:
http://www.google.com/search?q=Free+wxWidgets+IDE
And even better is:
http://wiki.wxwidgets.org/List_of_Integrated_Development_Environments
Wherein I direct people to see: "wxVS2008Integration - Proprietary wxWidgets Project wizard and Plugin for Visual Studio.NET 2008. "
-
When did complete integration with visual studio become a requirement?
-
I really don't like the fact Qt requires user to install additionall framework. wxWidgets seems to be a better solution, but again, there are problems with convenient WYSIWYG editor. However, if the possibilities of wxWidgets are similar to the possibilities of Qt, I would rather opt for wxWidgets. (That's only my opinion based on what I've read about wxWidgets since I haven't used that framework).
There's no way we can make FRED and FS totally independent, that's what karajorma said. There are no advantages of such a solution, only disadvantages. On the other hand statically linking code.lib is a waste of space (especially when we are considering removing jpg support to save space). IMO we need here dll (or so for Linux and Mac OS X) file that will be shared by FS and FRED.
As The_E mentioned before I've proposed making FRED a big tool that will cover many aspects of modding (especially tables modifications) apart from creating missions. That's hard to achieve but I think we can do it.
If we base UI on dockable panels (http://www.hard-light.net/forums/index.php?topic=63215.msg1292866#msg1292866) then we can easily take advantage from plugins system. Each functionality (for example tables editor) will be just another plugin (dll or so file). Plugin manager will be in exe file (probably together with few additional, hardcoded functions). Then our first task will be to create plugin manager and first plugin: mission editor in order to restore original FRED functionality. Afterwards we will be able to add new tools. (New plugins will be able to create new dockable panels, so integration with UI will be quite easy).
Additionally, if we apply something similar to MVC pattern we can easily add Undo (we can put on a stack all user's actions and then revert them if possible).
We have to rewrite FRED anyways if we want to make it portable. We can't keep old UI, that modders get used to, for ever. That's great opportunity to make FRED much better than it is now. It will require a lot of work, but in a long term it will make many things easier.
-
As The_E mentioned before I've proposed making FRED a big tool that will cover many aspects of modding (especially tables modifications) apart from creating missions. That's hard to achieve but I think we can do it.
If we base UI on dockable panels (http://www.hard-light.net/forums/index.php?topic=63215.msg1292866#msg1292866) then we can easily take advantage from plugins system. Each functionality (for example tables editor) will be just another plugin (dll or so file). Plugin manager will be in exe file (probably together with few additional, hardcoded functions). Then our first task will be to create plugin manager and first plugin: mission editor in order to restore original FRED functionality. Afterwards we will be able to add new tools. (New plugins will be able to create new dockable panels, so integration with UI will be quite easy).
That's basically what I've had in mind for a while.
Additionally, if we apply something similar to MVC pattern we can easily add Undo (we can put on a stack all user's actions and then revert them if possible).
Eg QCommand for Qt.
We have to rewrite FRED anyways if we want to make it portable. We can't keep old UI, that modders get used to, for ever. That's great opportunity to make FRED much better than it is now. It will require a lot of work, but in a long term it will make many things easier.
Indeed.
The reason I started the other thread was to try to have a full discussion about such a FRED IDE base framework, and determine a suitable architecture.
- I think we should split over there.
-
Additionally, if we apply something similar to MVC pattern we can easily add Undo (we can put on a stack all user's actions and then revert them if possible).
Eg QCommand for Qt.
I should expect something like that in Qt since there are only few thing they don't already have ;P (what about QFRED? ;P ) It can be very useful but I don't think is a sufficient reason to choose Qt instead of wxWidgets.
-
ya know, I was having a chat with a respected member of the community earlier today, and realised something.
We're going about this all arse-backwards.
My mummy (well, my coding mummy) always told me to decide what you want to do before deciding on a framework.
To that end, I suggest we stop bickering about frameworks and linking and start developing a forward looking plan, including UI designs, data management designs, etc - basically, a full requirements spec. This project is going to go nowhere quickly if we don't start thinking about what we're actually trying to achieve.
Once we've accomplished that, we should then evaluate the frameworks based on what they have to offer us in terms of ease of coding (yes, you heard me, ease of coding) what we've designed, rather than focussing on users and their installation woes.
The final step should then be to have someone figure out the distribution issues.
So, to that end, I suggest starting to develop UI ideas and requirements in a framework agnostic manner, and keeping the discussion from here on constructive, productive and polite.
-
You're absolutely right.
So, some suggestions:
The basic view should be a 3-pane view with top toolbar and menu.
The left-hand pane contains a treeview of the Mod, (not a mission or campaign) and extends the full height of the window.
(It needs to be tall because there's going to be a lot of stuff there)
- The top-most Node states the Mod Folder. This makes it easy for a user to know exactly which Mod they are using.
- Subnodes show Campaigns, Missions, Ships and other assets (eg tables) available by virtue of the selected Mod.
The bottom "Editor Pane" contains the properties of the currently selected 'item', and can be used as an editor if appropriate.
- Note that not all items will be editable, but it should be possible for a later developer to add an editor for any item.
The final "3D Pane" of the shows the currently-chosen mission, very similar to how it's currently shown.
All of these panes should be resizeable.
The 'Editor' and '3D' panes and can be hidden or 'torn-off' and placed external to the main window, or redocked to a different edge.
- For example, a user might want to make the Events Editor fullscreen and put the 3D Pane onto their second monitor.
Usage Example:
- To add a Ship to the mission, a user drags and drops a Ship Asset from the treeview into the 3D Pane.
- This ship is then added as a subnode within the currently active Mission in the treeview and is selected
- The Subnode is labelled with the in-mission name of the ship
- With the in-mission Ship selected, the Editor Pane shows and can be used to edit its flags, orders, settings etc. Some of these may be considered 'subnodes' of the ship itself (TBD)
-
That node tree approach is how PCS2 works, and I'm not really a fan of it. I much prefer the dialog method. One dialog per area of design. Though the dialogs shouldn't be modal.
-
It might be worthwhile to notice that users of FRED will still want to use versions prior to 5606, due to a waypoint bug caused by fixing WMC's warp-code..
I'll be posting a private build soon that does not include the changes to waypoint system, while still allowing Sync "Lost" to proceed as intended. It will contain all the other latest updates as an interim solution until FRED get's fixed.
Incidentally, this post indicates the benefit that would be gained from (at least partially) separating the two projects.
- There's bits that evidently need to remain linked, such as the POF loading code.
At present, changes to FS2 (even changes that should be completely unrelated to the editor at all), sometimes break apparently unrelated parts of the editor.
The suggestion of an autogenerated configuration file handles the requirement to keep new features 'in sync'. (Be that XML, a table file or whatever)
- That file could of course be a compiled-in resource, as it is in a couple of programs I use at work.
-
But as I've said several times that is quickly balanced out by the fact that you now have two different routines to do the same job in two programs. :p
-
While I'm not intending to continue this discussion too much further - this really isn't a planning thread, think about the opportunities for autogenerated code by storing meta data - reduce three sets of maintenance to one.
-
Am I the only one reminded of Softcoding (http://thedailywtf.com/Articles/Soft_Coding.aspx)?
-
Am I the only one reminded of Softcoding (http://thedailywtf.com/Articles/Soft_Coding.aspx)?
:P
Done properly it actually saves a lot of time - I've used such a technique to generate masses of interface code between multiple compilers and languages (FORTRAN/C).