[karajorma]

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.

[portej05]

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

[karajorma]

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.

[Spicious]

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?

[Tomo]

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.

[Aardwolf]

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.

[karajorma]

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

[Tomo]

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

[portej05]

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.

[karajorma]

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.

[portej05]

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.

[Spicious]

I don't think this is going to go anywhere until someone actually comes up with a detailed alternative.

[portej05]

There doesn't seem to be a huge drive for a detailed alternative other than a port of current FRED.

[karajorma]

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?

[portej05]

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

[The E]

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.

[portej05]

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.

[FUBAR-BDHR]

So every time the FREDder wants to test something he has to export the mission for FS2 to run it?  That makes no sense.

[karajorma]

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.

[Goober5000]

This thread has gone from the practical to the esoteric to the downright bizarre.  A new internal file format, for goodness sake?

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?