Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Nighthavoc on December 12, 2008, 01:07:28 am
-
ok so i've downloaded the new 3.6.10 vps did everything right now everything has gone haywire
i cant play any campaigns literally none including the main fs2 campaign and it comes up with errors like
Error: Training-2.fs2(line 265:
Error: Required token = [#Wings] or [$Name:], found [+Use Table Score:] .
File:J:\src\cvs\fs2_open_3_6_9.final\code\Parse\PARSELO.CPP
Line: 659
[This filename points to the location of a file on the computer that built this executable]
Call stack:
------------------------------------------------------------------
------------------------------------------------------------------
HELP!!!!!!!!!!!!!!!!!!!
EDIT: Nevermind i just realized my own stupidity and fixed it
-
I've run into this too. If you try to play a mission that is saved in a recent FRED build in an older build you will get this. You must run at least 3.6.10 revision 4985.
I'm actually in the process of figuring out if this is a bug or not. I don't know why that line doesn't have the ;;FS2_Open 3.6.10;; in front of it.
-
http://scp.indiegames.us/mantis/view.php?id=1724
It's a bug. But the problem it solves is an even bigger one.
-
The only mission affected by this is Training-2.
If you skip the training missions, you'll be fine.
-
Yeah but running the 3.6.10 V Ps on 3.6.9 is just asking for trouble anyway so it's probably better to just upgrade.
To be honest, the whole ;;FS2_Open version;; thing is stupid and needs to go.
-
I'd be happy as hell if it did karajorma, but then how can you tell what is a supported retail entry for a mission and what isn't?
(sexp's being a different kettle of fish. If some one can't reference the wiki on retail sexps and build a mission using them, then they shouldn't be releasing a retail mission but an scp one.)
-
If you want to save a mission for retail you can do so. The menu has an option to set a mission as FS2 Retail which if selected will prevent FRED saving out any features which retail can't use (Except SEXPs. You're really on your own there making sure you don't use any SEXPs FS2 can't understand).
The version system on the other hand appears to exist for another purpose. It seems to be used so that you can save a mission in FRED2_Open 3.6.10 or later and still have it open in 3.6.9. The idea is that all 3.6.10 features are tagged as such and won't be loaded. On paper this sounds like a great idea. In practice it's completely stupid.
1) By the time let's say 3.6.12 comes out there will be several new features in FS2_Open that 3.6.9 doesn't understand. Not having the load sounds great until you realise that a mission might be based on them. At which point 3.6.9 will load the mission perfectly only to completely fail to do anything sensible with it because it ignored
;;FS2_Open 3.6.12;; $Cloak Type : xxxxx
or whatever other wonderful feature we've added.
2) Unlike a crash which is almost instantly recognisable and even includes the name of the build in the report this error causes much more subtle bugs. If someone reports on the release thread for your campaign that ships are not cloaking for them you're probably going to waste hours in FRED before you realise that the error might be due to older builds ignoring the feature.
3) This feature will do bugger all to features like new mission or ship flags as they rely on the line being parsed in for all the older ones to work. That means that as soon as you use any of a large number of new features older builds will still crash out anyway.
4) There has been an almost 2 year gap between the release of the first 3.6.10 build and now but the code considers them all to be exactly the same even though the feature set most definitely isn't. Hopefully we won't have such a large gap in later releases but a system which is designed to allow new missions to open in older builds is definitely doing something wrong if it will allow a mission to open in a two year old build but crashes with a 3-4 month old one.
5) When designing missions if FRED 3.6.9 does manage to open a mission it will still save all the 3.6.10 data back out even though the FREDder never saw it. If the FREDder playtested on 3.6.9 the mission may even work perfectly only to develop all manner of weird and stupid bugs when someone plays i t on 3.6.10 and all the previously unparsable stuff suddenly starts working.
6) On top of everything else the code for the feature is so horribly convoluted that I can't make head nor tale of what it does. Which means when it breaks no one seems to be able to fix it. As far as I can tell it's been broken since it was changed to fout_version() instead of fout() and that was over half a year ago!
The result is that people assume that new features like +Use Table Score: are broken when in fact it's actually the underlying system that is borked and it simply manifests itself whenever someone adds a new feature.
In short the whole idea is broken and if I've got anything to say about it will be ripped out or heavily modified in 3.6.11
-
Yeah, that system makes zero sense when applied to .fs2 files. Letting them work with a reduced feature set is a recipe for disaster.
-
I should probably move this one to the SCP forum seeing as how the OP's question was answered anyway. :)
-
Just had one of those idea thingies.
The biggest problem I see here is when you go to make a quick change and use the wrong version resulting in the mission not being loadable in the version it was made for. How about a version in the FS2 file. If you go to edit the file in a newer version of FRED it will warn you that the file will no longer be usable in the previous version.
So in the latest case where I ran into this I was working on a 3.6.10 mission in 3.6.10 FRED. I needed to make a couple of changes to a mission that was for 3.6.9. I opened it up and not thinking edited a couple of arrival cues and saved it. If FRED would have said "This is a 3.6.9 mission if you proceed it will no longer be usable in 3.6.9. Are you sure you wish to continue?" I would have closed out FRED and used 3.6.9.
A similar feature in FS2 that would check the version and if it's newer say this mission is not compatible with this version of FS2_Open.
-
Saving for different compatibilities would be nice of course too, but these are both pretty in depth requests. I'd rather see Undo reworked first :)
-
Yeah, that system makes zero sense when applied to .fs2 files. Letting them work with a reduced feature set is a recipe for disaster.
It makes total sense if you use it properly, but the FSPort team seem to be the only people who are doing that. :p
However I agree that the parsing is badly screwed up and needs to be fixed. That's high on my priority list for after ST:R is released.
-
Let me rephrase (because you're right, there are cases where it makes sense, and I was overgeneralizing). It makes zero sense when applied to parts of the .fs2 file that can affect the flow and balance of a mission, because that should be consistent across all versions.
-
It makes total sense if you use it properly, but the FSPort team seem to be the only people who are doing that. :p
If by use it properly you mean go over to the user's house and beat them with a stick when they attempt to run a 3.6.10 mission in 3.6.9 I might concede the point. :p