[The E]

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 

[Spicious]

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.

[FUBAR-BDHR]

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.

[karajorma]

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.

[sigtau]

An undo option *would* be nice, even in the current event editor interface.

[karajorma]

I'm not saying it wouldn't be nice. I'm saying it would require rewriting FRED almost completely.

[sigtau]

...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.

[karajorma]

Assume that it will take all the SCP programmers the next couple of years and you'll be closer to the mark

[portej05]

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.

[karajorma]

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.

[portej05]

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!)

[Reprobator]

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.
 

[Tomo]

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.

[karajorma]

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?

[Spicious]

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.

[portej05]

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

[karajorma]

How much of 'code' are you thinking of getting rid of?

[Tomo]

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.

[karajorma]

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.

[Tomo]

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.