Hard Light Productions Forums
Hosted Projects - Standalone => Wing Commander Saga => Topic started by: X3N0-Life-Form on November 08, 2013, 04:10:17 am
-
In other news, it looks like the game's source code has finally been released (http://www.wcsaga.com/forum/index.php?f=22&t=861&rb_v=viewtopic&start=10#p9092). Which means that we can start porting the game back up to standard FSO.
-
They added boost (or so it looks like), interesting :)
-
In other news, it looks like the game's source code has finally been released (http://www.wcsaga.com/forum/index.php?f=22&t=861&rb_v=viewtopic&start=10#p9092). Which means that we can start porting the game back up to standard FSO.
Assuming there's anything salvageable in there, which seems a massive stretch. Remember they broke multiplayer and cross-platform compatibility.
-
The flags and sexps should be reasonably easy to port.
And given that that's pretty much all that has changed (that has external consequences), well.....
-
I'll take a look at the SEXPs this weekend and see what's usable.
EDIT : I should say that I'm not going to automatically make anything I add compatible with the WCS codebase. I'll only add in their SEXPs if I really believe that is the best way to implement them. If a re-release of Matth's WCS_Open is needed to make their SEXPs work, so be it.
-
If a re-release of Matth's WCS_Open is needed to make their SEXPs work, so be it.
No disagreement here.
-
Yeah, I figured you'd understand that the SEXPs should be useful to everyone, not just WCS_Open.
-
Can't really go wrong with more SEXPs. Just make sure you're not duplicating existing functionality. There's a post of mine in WCS Open thread that details a bunch of WCS features already implemented in FSO under a different name and marginally different syntax.
-
Some questions:
- Who's leading the effort to port WCS to FSO?
- Have we stuffed the WCS codebase dump we received from the WCS team in a VCS repository? If so, what is the URL to this repository?
- Does anyone know at approximately what revision number (FSO's SVN repository) they decided to fork off from FSO and do their own thing? That sort of information would be very useful in starting a port.
- Can someone give me a short history on the nature of the division between WCS and FSO? Based on a WCS developer's comment (http://www.wcsaga.com/forum/index.php?f=22&t=861&sid=b69d7fea7fd1faf3ebbbaeba5597da01&rb_v=viewtopic&start=20#p9103), there appears to be some bad blood---perceived or actual---between the WCS community and the FSO community.
- Is anyone in the WCS development team interested in helping port their creation over to FSO?
-
Some questions:
- Who's leading the effort to port WCS to FSO?
- Have we stuffed the WCS codebase dump we received from the WCS team in a VCS repository? If so, what is the URL to this repository?
- Does anyone know at approximately what revision number (FSO's SVN repository) they decided to fork off from FSO and do their own thing? That sort of information would be very useful in starting a port.
- Can someone give me a short history on the nature of the division between WCS and FSO? Based on a WCS developer's comment (http://www.wcsaga.com/forum/index.php?f=22&t=861&sid=b69d7fea7fd1faf3ebbbaeba5597da01&rb_v=viewtopic&start=20#p9103), there appears to be some bad blood---perceived or actual---between the WCS community and the FSO community.
- Is anyone in the WCS development team interested in helping port their creation over to FSO?
1) my understanding is that there is no driven effort to bring WCS features to FSO but as time and interest is available then the useful bits will be implemented in SCP's style.
2) I will leave that to SCP
3) WCS are probably the only guys who can give a definitive answer on the when but I do believe it was in and around 3.6.9 for prologue, not sure if they used a newer build as the basis for DD
4) short version WCS needed certain features in the code that SCP were unwilling to commit at the time (I think retail comparability was involved there) as for the antagonism I think it just developed over time
5) possibly not as a "Team", as individuals, perhaps, though it must also be noted that several prominent HLP members were or are standing WCS team members
-
Thanks headdie. That's some useful information.
-
on point 2 - to the best of my knowledge the code hasn't been added to any VCS, it definitely hasn't been added to the official SCP repo.
As for point 4, the split occurred before I was a member here but I think headdie has pretty much nailed the issue that lead to the fork, i.e. the SCP was slow to commit WCS features, or was rejecting WCS coded features (with good reasons or unjustifiably?). Additionally after the release (which I was around for) there was some negative feedback provided (valid or otherwise?) here about WCS:DD which further soured the already poor relations. The reasonableness of all this is a point of debate, but it's one I don't want to get into as IMO it's past the point where anything constructive could come of it :(
If you want to port the WCS code over to FSO, I'd say go for it and don't worry about the history. From my point of view, it'd be great to have Linux/OSX officially supported, and maybe even multi-player restored. Those alone would be worth it :) (although lightshafts/shadows/etc would also be supercool ;7)
-
Agreed. Multiplayer WCS would be kick-arse. Doesn't Matth's WCS_Open already have that ability? Is it simply the missing interface art which prevents it from working?
Does anyone know at approximately what revision number (FSO's SVN repository) they decided to fork off from FSO and do their own thing? That sort of information would be very useful in starting a port.
It was definitely after the prologue release. I remember being mildly annoyed that I kept having to recompile builds for BtRL while they could use the official release.
Can someone give me a short history on the nature of the division between WCS and FSO? Based on a WCS developer's comment (http://www.wcsaga.com/forum/index.php?f=22&t=861&sid=b69d7fea7fd1faf3ebbbaeba5597da01&rb_v=viewtopic&start=20#p9103), there appears to be some bad blood---perceived or actual---between the WCS community and the FSO community.
Basically WCS wanted features implemented which the SCP was unwilling to implement. Also at least a couple of times features were reimplemented in a way which broke WCS. I'm not going to claim either side was completely in the wrong cause there were quite a few times I completely agreed with the WCS team and was pretty spitting mad about the issues the SCP were causing them. Other times I thought it was WCS who were being unreasonable. In the end the WCS team decided to fork the code in order to have the feature set they wanted added without having to deal with the SCP. I tend to agree with niffiwan that it's rather silly to actually argue over the causes though. It's better to simply move on.
-
If I'm not mistaken, the fork is based on version 3.6.12. But I don't know the exact revision.
-
Can someone give me a short history on the nature of the division between WCS and FSO? Based on a WCS developer's comment (http://www.wcsaga.com/forum/index.php?f=22&t=861&sid=b69d7fea7fd1faf3ebbbaeba5597da01&rb_v=viewtopic&start=20#p9103), there appears to be some bad blood---perceived or actual---between the WCS community and the FSO community.
Wow. I knew that the WCS guys had moved further and further away from HLP, but I didn't realize they were actively pissed at us (Doesn't take much searching to find more evidence either :doubt:). That attitude really doesn't seem warranted given that, let's be honest, fork or not, WCS wouldn't be a fraction of the game it is now if not for the work done by this community on FSO.
I guess the thing to do here is to take the best bits out of their codebase, then let MatthTheGeeks port and The_E's remix idea lead to a much better WC game that fixes all the problems with WCS, even without a "2 million budget". Good luck gents. :D
-
Based on a WCS developer's comment (http://www.wcsaga.com/forum/index.php?f=22&t=861&sid=b69d7fea7fd1faf3ebbbaeba5597da01&rb_v=viewtopic&start=20#p9103)
Hahahahaha :D
I didn't see this. He's out of arguments, he knows he's lost, but can't admit it, so he resorts to insults. Typical KK.
-
Wow. I knew that the WCS guys had moved further and further away from HLP, but I didn't realize they were actively pissed at us (Doesn't take much searching to find more evidence either :doubt:). That attitude really doesn't seem warranted given that, let's be honest, fork or not, WCS wouldn't be a fraction of the game it is now if not for the work done by this community on FSO.
I wouldn't take KK's comments as representative of the WCS team. I'd need to hear the same thing coming from someone like Tolywn before I believed it was the team rather than one member of the team.
I didn't see this. He's out of arguments, he knows he's lost, but can't admit it, so he resorts to insults. Typical KK.
Well it's possible he's taken my comments on this thread as an insult to his coding so I'm going to reserve judgement until he responds to my last post on that thread.
Also I should point out that just because there is some animosity from from WCS to HLP doesn't mean we should sink to that level too. Especially when that would further the rift.
-
Have at thee! :D
https://github.com/niffiwan/wcsaga
(let me know if anyone wants commit access)
FYI: this seems to indicate the fork was at 3.6.12 RC1
gcc -DPACKAGE_NAME=\"fs2_open\" -DPACKAGE_TARNAME=\"fs2_open\" -DPACKAGE_VERSION=\"3.6.12\ RC1\" -DPACKAGE_STRING=\"fs2_open\ 3.6.12\ RC1\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DNO_CD_CHECK=1 -DNDEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSCP_UNIX=1 -DNO_DIRECT3D=1 -DUSE_OPENAL=1 -I. -m64 -march=athlon64 -ansi -pedantic -DLUA_USE_LINUX -g -Os -Wall -funroll-loops -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -fsigned-char -Wno-unknown-pragmas -MT ltable.o -MD -MP -MF .deps/ltable.Tpo -c -o ltable.o ltable.c
And it doesn't compile in Linux yet (not that I've spent much time on this so far)
-
Well it's possible he's taken my comments on this thread as an insult to his coding
As he should. Rape is not acceptable.
-
Well it's possible he's taken my comments on this thread as an insult to his coding
As he should. Rape is not acceptable.
....
No, in this instance, your behaviour is not acceptable.
-
I regret nothing.
-
Matt, this trolling of the WCS team you are delighting in puts the other negative things you've said about WCS into doubt for me.
Also the fact that while I tried to find it and cannot, I'm sure it was you who told me when I enquired about the fork that basically you put it as if they split for no apparant reason because they're stupid, when what was said here shows otherwise.
-
For those too lazy to look it up, the split was r5919 (around 4100 commits ago), if it is really 3.6.12 RC1.
-
indeed i only see KK venting in that thread, nothing new for the interwebs, if more members or if like kara says a member like Tolywn (who I generally have fount in my limited interactions a cool guy) then I would belive there was a problem.
but at the same time, over the last couple of years when have we as a community proven to be the better people? I noticed several occasions around the time of DD's release where things were said here and I got the feeling it was because it was aimed at WCS that it was felt to be acceptable by some members that they were expressed in the way they were.
-
1) It's good to see the code getting reintegrated with FSO.
2) I really don't know the reasons behind the animosity; I've been semi-lurking for quite a while and it really threw me off to find out there was raw feelings on the matter. And it doesn't seem like there's a point to continuing the feud, or whatever it is, IMO... :sigh:
-
2) I really don't know the reasons behind the animosity; I've been semi-lurking for quite a while and it really threw me off to find out there was raw feelings on the matter. And it doesn't seem like there's a point to continuing the feud, or whatever it is, IMO... :sigh:
yer its built over a number of years, some of it pre-dates prologue even. hopefully the hatchet can be buried one day, but it would seem that today might not be that day :(
-
I've been doing a comparison between the wc_saga code versus r5919 (the release revision for FS2_open 3.6.12 R1, the probable fork point that the WC Saga team forked at) and from what I can tell, a lot of the "differences" between their code and FSO are code formatting:
FSO: anim/animplay.cpp:56
// -------------------------------------------------------------------------------------------------
// anim_render_all() will display the frames for the currently playing anims
//
void anim_render_all(int screen_id, float frametime)
{
anim_instance* A;
anim_instance* temp;
A = GET_FIRST(&anim_render_list);
while( A !=END_OF_LIST(&anim_render_list) ) {
temp = GET_NEXT(A);
if ( A->screen_id == screen_id ) {
if ( Anim_ignore_frametime ) {
frametime = 0.0f;
Anim_ignore_frametime=0;
}
if ( anim_show_next_frame(A, frametime) == -1 ) {
A->data = NULL;
anim_release_render_instance(A);
}
}
A = temp;
}
}
WCS:
// -------------------------------------------------------------------------------------------------
// anim_render_all() will display the frames for the currently playing anims
//
void anim_render_all(int screen_id, float frametime)
{
anim_instance* A;
anim_instance* temp;
A = GET_FIRST(&anim_render_list);
while (A != END_OF_LIST(&anim_render_list))
{
temp = GET_NEXT(A);
if (A->screen_id == screen_id)
{
if (Anim_ignore_frametime)
{
frametime = 0.0f;
Anim_ignore_frametime = 0;
}
if (anim_show_next_frame(A, frametime) == -1)
{
A->data = NULL;
anim_release_render_instance(A);
}
}
A = temp;
}
}
All I can say about that is :nono:. I really wish they didn't do silly things like that. It really makes it difficult to tell the real differences from the quasi-differences! It's too bad that we can't use a tool like Semantic Merge to weed out "differences" like this one! I'm curious how many of the 593 different files WinMerge found are either just formatting differences or mostly formatting differences.
In any event, I've attached a report in both html and csv containing all the different files between r5919 and WCS if anyone's curious.
[attachment deleted by an evil time traveler]
-
Indeed, I think I've seen tabs converted to spaces, pointers from int *foo to int* foo, conversion to only Allman braces, etc. As you say, hard to diff easily.
Some material differences that I have noted are:
1) multi-threaded OGG reader
2) keyboard detection
Both are strictly win32 only as they rely on the windows API.
There's a few other things as well, but they're lost in the sea of the other changes I made to get semi sane diffs for some of the files :)
-
I spotted a shader management system that is pretty different from ours (whether it's better, I do not know; It's certainly a cleaner, more explicitly object oriented design).
-
We should be able to reduce the signal-to-noise ratio by doing a regex transform on the whole WCS tree to at least delete the extra newline added between angle brackets. I probably won't be able to do that tonight, though. Does someone else feel up to doing something like that and pushing it into a git branch?
-
I'd like to point out that Luke is currently working on his own improvements for Wing Commander Saga. They are also for the German translation project he and his team are working on.
If you're curious on what he has done, I recommend going to this topic on wcnews and read his post below:
http://www.wcnews.com/chatzone/threads/wc-saga-source-code-released.27158/
-
I've started the tedious work of removing all the mere-formatting changes made to the codebase by the WCS team members so we can identify what substantive changes they've made to the codebase that we need to account for in some way or another. I'll get this posted to the github as soon as I have the time to jump through all the hoops involved in working with github via a Mercurial client (yes, you can do that without anyone knowing or, hopefully, caring). Until then, I'll post the patch here so SCP / WCS members can review progress.
A note to WCS coders: during this initial phase of the port, I / we (?) are focusing on identifying what functional changes have been made to the code base that are not part of SCP and thus need to be accounted for in some way. As such, my "reconciliation" efforts on formatting differences is simply to conform the formatting of WCS's codebase to that of SCP's code base as it looked like at r5919. Please bear in mind that this in no way is meant as a critical opinion of the cosmetic changes you made: it is simply a mechanism to filter out all the noise so we can all see what functional changes have been made to the SCP codebase so we can port them to SCP.
[attachment deleted by an evil time traveler]
-
As I said in the previous post, I have started work on ironing out the cosmetic and formatting differences between the WCS source code and the SCP code base at r5919. This is definitely tedious work and I could use some help in making this happen. While this work is by no means glamorous, doing this work will enable us to identify what changes the WCS team made to the SCP code base and allow us to either (1) fold the changes that don't break retail into SCP directly or (2) find a roundabout way of allowing the WCS "mod" to vary from SCP in a one-off manner w/o needing a special executable to do so.
So, would anyone be interested in signing up? ;7
-
Well you can ignore the SEXP changes and anything that stems from them as I'm handling those anyway.
EDIT :
Here's a patch to add in the Was-destroyed-by-delay SEXP. The allow-dynamic-goals, and set-scannable SEXPs are basically useless as this functionality can already be called from the alter-ship-flag SEXP without all the bollocks that resulted in me writing the alter-ship-flag SEXP in the first place. The hide-ship-name SEXP's functionality can and has been added to alter-ship-flag SEXP in the patch.
Index: code/parse/sexp.cpp
===================================================================
--- code/parse/sexp.cpp (revision 10205)
+++ code/parse/sexp.cpp (working copy)
@@ -180,6 +180,7 @@
//Objectives Category
{ "is-destroyed", OP_IS_DESTROYED, 1, INT_MAX, SEXP_BOOLEAN_OPERATOR, },
{ "is-destroyed-delay", OP_IS_DESTROYED_DELAY, 2, INT_MAX, SEXP_BOOLEAN_OPERATOR, },
+ { "was-destroyed-by-delay", OP_WAS_DESTROYED_BY_DELAY, 3, INT_MAX, SEXP_BOOLEAN_OPERATOR, },
{ "is-subsystem-destroyed", OP_IS_SUBSYSTEM_DESTROYED, 2, 2, SEXP_BOOLEAN_OPERATOR, },
{ "is-subsystem-destroyed-delay", OP_IS_SUBSYSTEM_DESTROYED_DELAY, 3, 3, SEXP_BOOLEAN_OPERATOR, },
{ "is-disabled", OP_IS_DISABLED, 1, INT_MAX, SEXP_BOOLEAN_OPERATOR, },
@@ -5117,6 +5118,77 @@
return SEXP_FALSE;
}
+
+// First ship is the destroyer, rest of the arguments are the destroyed ships.
+int sexp_was_destroyed_by(int n, fix* latest_time)
+{
+ char* destroyer_ship_name;
+ char* destroyed_ship_name;
+ int count = 0, num_destroyed;
+ fix time;
+
+ Assert(n != -1);
+
+ destroyer_ship_name = CTEXT(n);
+
+ num_destroyed = 0;
+
+ for (n = CDR(n); n != -1; n = CDR(n))
+ {
+ count++;
+ destroyed_ship_name = CTEXT(n);
+
+ if (sexp_query_has_yet_to_arrive(destroyed_ship_name))
+ return SEXP_CANT_EVAL;
+
+ // check to see if this ship/wing has departed. If so, then function is known false
+ if (mission_log_get_time(LOG_SHIP_DEPARTED, destroyed_ship_name, NULL, NULL))
+ return SEXP_KNOWN_FALSE;
+
+ // check the mission log. If ship/wing not destroyed, immediately return SEXP_FALSE.
+ if (mission_log_get_time(LOG_SHIP_DESTROYED, destroyed_ship_name, destroyer_ship_name, &time))
+ {
+ num_destroyed++;
+ if (latest_time && (time > *latest_time))
+ *latest_time = time;
+ }
+ }
+
+ if (count == num_destroyed)
+ return SEXP_KNOWN_TRUE;
+ else
+ return SEXP_FALSE;
+}
+
+int sexp_was_destroyed_by_delay(int n)
+{
+ fix delay, time;
+ int val;
+
+ Assert(n >= 0);
+
+ time = 0;
+
+ delay = i2f(eval_num(n));
+
+ // check value of is_destroyed function. KNOWN_FALSE should be returned immediately
+ val = sexp_was_destroyed_by(CDR(n), &time);
+ if (val == SEXP_KNOWN_FALSE)
+ return val;
+
+ if (val == SEXP_CANT_EVAL)
+ return SEXP_CANT_EVAL;
+
+ if (val)
+ {
+
+ if ((Missiontime - time) >= delay)
+ return SEXP_KNOWN_TRUE;
+ }
+
+ return SEXP_FALSE;
+}
+
int sexp_is_subsystem_destroyed_delay(int n)
{
char *ship_name, *subsys_name;
@@ -22027,6 +22099,10 @@
sexp_val = sexp_is_destroyed( node, NULL );
break;
+ case OP_WAS_DESTROYED_BY_DELAY:
+ sexp_val = sexp_was_destroyed_by_delay(node);
+ break;
+
case OP_IS_SUBSYSTEM_DESTROYED:
sexp_val = sexp_is_subsystem_destroyed(node);
break;
@@ -24452,6 +24528,7 @@
case OP_HAS_ARRIVED:
case OP_HAS_DEPARTED:
case OP_IS_DESTROYED_DELAY:
+ case OP_WAS_DESTROYED_BY_DELAY:
case OP_IS_SUBSYSTEM_DESTROYED_DELAY:
case OP_IS_DISABLED_DELAY:
case OP_IS_DISARMED_DELAY:
@@ -25318,6 +25395,12 @@
else
return OPF_SHIP_WING;
+ case OP_WAS_DESTROYED_BY_DELAY:
+ if (argnum == 0)
+ return OPF_POSITIVE;
+ else
+ return OPF_SHIP;
+
case OP_IS_DESTROYED_DELAY:
case OP_HAS_ARRIVED_DELAY:
case OP_HAS_DEPARTED_DELAY:
@@ -29288,6 +29371,13 @@
"\t1:\tTime delay in seconds (see above).\r\n"
"\tRest:\tName of ship (or wing) to check status of." },
+ { OP_WAS_DESTROYED_BY_DELAY, "Was destroyed by delay (Boolean operator)\r\n"
+ "\tBecomes true <delay> seconds after all specified ships have been destroyed by the specified first ship.\r\n\r\n"
+ "Returns a boolean value. Takes 3 or more arguments...\r\n"
+ "\t1:\tTime delay in seconds (see above).\r\n"
+ "\t2:\tShip that should have destroyed the other ships (see below).\r\n"
+ "\tRest:\tName of ships to check status of." },
+
{ OP_IS_SUBSYSTEM_DESTROYED_DELAY, "Is subsystem destroyed delay (Boolean operator)\r\n"
"\tBecomes true <delay> seconds after the specified subsystem of the specified "
"ship is destroyed.\r\n\r\n"
Index: code/parse/sexp.h
===================================================================
--- code/parse/sexp.h (revision 10205)
+++ code/parse/sexp.h (working copy)
@@ -286,6 +286,7 @@
#define OP_PERCENT_SHIPS_DISABLED (0x000f | OP_CATEGORY_OBJECTIVE | OP_NONCAMPAIGN_FLAG) // Goober5000
#define OP_PERCENT_SHIPS_ARRIVED (0x0010 | OP_CATEGORY_OBJECTIVE | OP_NONCAMPAIGN_FLAG) // FUBAR-BDHR
#define OP_NAV_IS_VISITED (0x0011 | OP_CATEGORY_OBJECTIVE | OP_NONCAMPAIGN_FLAG) // Kazan
+#define OP_WAS_DESTROYED_BY_DELAY (0x0012 | OP_CATEGORY_OBJECTIVE | OP_NONCAMPAIGN_FLAG) // WCS
#define OP_TIME_SHIP_DESTROYED (0x0000 | OP_CATEGORY_TIME | OP_NONCAMPAIGN_FLAG)
#define OP_TIME_SHIP_ARRIVED (0x0001 | OP_CATEGORY_TIME | OP_NONCAMPAIGN_FLAG)
@@ -382,7 +383,6 @@
#define OP_IS_IN_MISSION (0x004d | OP_CATEGORY_STATUS | OP_NONCAMPAIGN_FLAG) // Goober5000
-
// conditional sexpressions
#define OP_WHEN (0x0000 | OP_CATEGORY_CONDITIONAL)
#define OP_WHEN_ARGUMENT (0x0001 | OP_CATEGORY_CONDITIONAL) // Goober5000
Index: code/ship/ship.cpp
===================================================================
--- code/ship/ship.cpp (revision 10205)
+++ code/ship/ship.cpp (working copy)
@@ -361,6 +361,7 @@
};
// Constant for flag, Name of flag, In flags or flags2
+// When adding new flags remember to bump MAX_SHIP_FLAG_NAMES in ship.h
ship_flag_name Ship_flag_names[] = {
{SF_VAPORIZE, "vaporize", 1, },
{SF_WARP_BROKEN, "break-warp", 1, },
@@ -370,6 +371,7 @@
{SF_HIDDEN_FROM_SENSORS, "hidden-from-sensors", 1, },
{SF2_STEALTH, "stealth", 2, },
{SF2_FRIENDLY_STEALTH_INVIS, "friendly-stealth-invisible", 2, },
+ {SF2_HIDE_SHIP_NAME, "hide-ship-name", 2, },
{SF2_AFTERBURNER_LOCKED, "afterburners-locked", 2, },
{SF2_PRIMARIES_LOCKED, "primaries-locked", 2, },
{SF2_SECONDARIES_LOCKED, "secondaries-locked", 2, },
Index: code/ship/ship.h
===================================================================
--- code/ship/ship.h (revision 10205)
+++ code/ship/ship.h (working copy)
@@ -421,7 +421,7 @@
int flag_list; // is this flag in the 1st or 2nd ship flags list?
} ship_flag_name;
-#define MAX_SHIP_FLAG_NAMES 15
+#define MAX_SHIP_FLAG_NAMES 16
extern ship_flag_name Ship_flag_names[];
// states for the flags variable within the ship structure
What other SEXPs were added by the WCS team? Matth might be able to answer but from using X3N0-Life-Form re-engineered WCS code I've identified these SEXPs which I suspect we already have an alternative to
trigger-arrival-track
force-battle-music
set-forward-deceleration
About the only other SEXP which might be useful is their lock-controls SEXP. I remember in Diaspora we did the same thing using scripts and the ignore-key SEXP. So it's probably worth adding.
[attachment deleted by an evil time traveler]
-
Mastadon, I can help out with the sorting out the cosmetic and formatting differences (well, in between a few other things I've got in progress). You seem to have started at A (for ai), so I'll start at W (for wxfred2) and work backwards. I'll throw all my work into a branch on github.
-
About the only other SEXP which might be useful is their lock-controls SEXP. I remember in Diaspora we did the same thing using scripts and the ignore-key SEXP. So it's probably worth adding.
Yeah, that would be nice. I was really disappointed we don't have such a SEXP when trying to do a Diaspora-style catapult launch. That would simplify the launch sequence somewhat, which is probably a good thing. Otherwise, there isn't really much in there that we don't already have. In WCSOpen thread I've already pointed out some table fields that were implemented by SCP independently, with a slightly different syntax and minor differences in functionality.
In fact, I was really interested in was increased gun/missile bank limit and whatever under-the-hood stuff they might've done. Seeing that there's less of the latter than I thought was a bit disappointing, TBH.
-
The gun/missile bank limit change is the leading candidate for whatever broke multiplayer though. It probably also broke the loadout menu too but that code is a pile of **** and needs replacing anyway.
-
Yeah, I'm aware of that. It'd be nice to somehow go around this limitation, or preferably remove it altogether... Still, that would probably require a different approach than how WCS did it. Overall, this release was a bit of a disappointment. As it is now, it looks like the biggest influence of this code on FSO would be "lock-controls" SEXP for easy carrier launches. Perhaps the shader code will be good for something, but I don't know if this has any improvement potential over what we have now.
-
Mastadon,
After running through code/weapon/beam.cpp (mostly) by hand, I've come to the conclusion that we need to format both wcsaga & FSO @ r5919. I believe that the WCSaga guys used an automatic code formatter on the code, thus it's all consistent. However, the FSO code is _not_ which makes it very laborious to return the WCSaga to the same state as FSO. Therefore, I was going to propose running astyle (http://astyle.sourceforge.net/astyle.html) over the two branches of the code, using the following options file:
# format reconciliation for WCSaga
--style=allman
--indent=tab
--align-pointer=name
--keep-one-line-statements
--keep-one-line-blocks
--lineend=linux
--pad-oper
--pad-paren
--pad-header
--convert-tabs
--indent-col1-comments
--suffix=none
The comparison can then be done with "git diff --ignore-space-change" which ends up with a fairly sane amount of output to manually reformat.
I was going to use these two branches for this:
https://github.com/niffiwan/wcsaga/tree/format_reconciliation
https://github.com/niffiwan/fs2open.github.com/tree/format_reconciliation
What do you think?
-
I tried running astyle against both source code trees and it gets rid of a great deal of the stylistic differences between the two code bases. That was a really good idea you had niffiwan!
There are two major stylistic differences that still need to be accounted for, though: cases where multi-dimensional arrays are not reformatted and, much more significantly, function calls / definitions are not formatted to be on a consistent number of lines chopped at a specific number of spaces (if chopped at all).
I'll toy around with the formatting options and see what I can figure out after I push what I have to github (only the wc_saga stuff, since I'm not an SCP-er and can't push to either of the FSO repos).
-
Thanks :)
Regarding pushing to the FSO repos, I was thinking we could either move the FSO r5919 branch to the wcsaga repo, or you could fork the fs2open repo. The first probably makes more sense since this the branch exists only to compare the wcsaga changes, so I'll see what I can do in that regard.
Lastly, there is an option in astyle to limit the max size of a line but I haven't tried it out yet. In theory the only trick is working out what value of max-line-length the wcsaga guys used. I haven't seen anything to fix the multi-dimensional arrays yet though, maybe there's another tool that can do that.
-
Well, I was able to push my changes to the git repo, but I pushed to a different branch than yours and I can't for the life of me figure out how to merge my branch into yours. Every time I try, Git tells me that both our branches are up to date (they can't possibly be, since I ran astyle against the entire code base). Furthermore, whenever I try and do a "git push", I get this lovely error message:
! [rejected] format_reconciliation -> format_reconciliation (non-fast-forward)
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/niffiwan/wcsaga.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
:banghead:
I don't know what is causing this error at all, nor do I know what could be causing this error! All the branches are up to date. Everything has been fast-forwarded (maybe). I don't know where to go from here.
Any ideas?
-
Thanks :)
Regarding pushing to the FSO repos, I was thinking we could either move the FSO r5919 branch to the wcsaga repo, or you could fork the fs2open repo. The first probably makes more sense since this the branch exists only to compare the wcsaga changes, so I'll see what I can do in that regard.
Lastly, there is an option in astyle to limit the max size of a line but I haven't tried it out yet. In theory the only trick is working out what value of max-line-length the wcsaga guys used. I haven't seen anything to fix the multi-dimensional arrays yet though, maybe there's another tool that can do that.
If you're going to do option one, your best bet will be to restructure the history so that the r5919 commit happens before the first real commit (commit "1") so that when we do VCS operations, they won't appear like they're reversing the changes made wcsaga.
-
I'm not sure what went wrong on your end. It "seems" like it wants a git pull before you push, but I figure that you've done that already?
Anyway - since the changes I had were (for three files only) a small superset of what you'd done, I merged the format_reconciliation branch onto formatting_reconciliation, I needed to run a mergetool over this since I'd fixed some of the broken-at-max-length lines and multi-dimensional arrays by hand. Anyway, we can probably continue to use the formatting_reconciliation branch now anyway, if we really feel like it we can delete format_reconciliation and rename formatting_reconciliation.
I have some more by-hand changes to files in code/weapon/* which I'll add to this branch soon (I hope... and re-add the .gitignore changes of your that I clobbered)
And thanks for the suggestion about where to start the other branch, I'll do something like that.
-
I did do a "git pull" before the push, but apparently I need to do a pull against origin/<branchName> rather than just <branchName>.
Ugh, it looks like I need to sit down and do some book learning on git so that I can "git" on board with git.
-
I ran GNU Indent on the code base to make both wc_saga and fso_r5919 have line breaks at roughly the same places. We should probably try to see if we can make the formatting the same for array definitions if we can, but we are starting to approach a point where we can now start easily identifying the substantive changes between wc_saga and fso_r5919, and start determining what we will need to merge into / account for in the FSO code base to port WC saga into FSO.
Any advice on how we should proceed on doing that?
-
Don't assume we necessarily want to merge the WCS changes into FSO.
Remember they broke multi, cross-platform and removed a number of essential features.
This is more about what we can salvage or not from the derelict. Karaj's already worked on sexps.
-
Don't assume we necessarily want to merge the WCS changes into FSO.
Remember they broke multi, cross-platform and removed a number of essential features.
This is more about what we can salvage or not from the derelict. Karaj's already worked on sexps.
I definitely agree: the goal is not to merge every change WCS made to FSO, but rather to be able to get the WC Saga campaign to run on FSO vanilla by porting over the necessary changes they made to FSO in a manner that doesn't muck up things for everyone.
In events where they made changes that we don't want in FSO that are required for WCS to run correctly, we will want to account for the changes in a way that allows WCS to function in a vanilla FSO build. I'm thinking of maybe using tables and function pointers to achieve this.
-
I don't think we should try to have unchanged WCS data working as-is on FSO builds, especially when WCSOpen is just there.
Besides, I don't believe a bump of the secondary bank limit (the very one that most likely broke multi compatibility) is going to make it to FSO any time soon, which is a pretty big show-stopper for running unchanged WCS data on FSO builds.
-
WCS changed the code to suit them and only them. I don't have a problem with them doing that, it was the whole reason they wanted to fork the code. But when we port stuff over to SCP we should do it in a way that makes the feature available to everybody, not just WCS.
I agree with Matth, we'll never get WCS to run on SCP as is. They introduced SEXPs that have no business being in the SCP codebase and will never be added (SEXPs which set or unset ship flags come with a host of annoying problems, which is why I introduced the alter-ship-flag SEXP). We'll need to make a new release in order to deal with that issue anyway so why no simply do that for all their changes? What we need to do, is to work on a version of WCS_Open which has as many of the original features added back in as possible.
In addition we should start working on putting back in the features that WCS didn't have but should. For instance multiplayer, from what I understand all WCSOpen needs for multi to work is the interface art. It probably needs its own process on FS2NetD eventually but that's not an enormous problem for now.
Matth, do you have a file describing exactly what you had to take out?
-
I had this (http://pastebin.com/pZpaswYw), it should be roughly accurate.
I wonder is I should just start back from scratch and do a proper changelog as I fix things up. WCSOpen is pretty messy right now.
-
I tried various auto formatting tools to see if there was a way to standardize the format of array assignments, but there doesn't seem to be one. In any event, this shouldn't be too big of an issue in identifying what substantive changes WCS made to the FSO_r5919 code base. So having gotten the formatting differences roughly ironed out between the two code bases, I propose that the next step should be to go through the codebase and write down in summary form what changes WCS made to the FSO code base. After we complete that step, we should be in a position to start the more interesting part of this task: determining which of their changes would make a good addition to the FSO code base and which differences we will need to modify the WCS campaign to account for a given change not being added to the FSO codebase.
In the interest of KISS, I recommend that we put this analysis in an appropriately named table in the wc_saga repo's wiki. If everyone's on board with that approach, I've created such a page here (https://github.com/niffiwan/wcsaga/wiki/WC_Saga-Changes-to-FSO_r5919).
-
Sounds like a good idea :yes:
-
Hi folks,
here is my make.log from the compilation on Ubuntu 12.04 32bit and the following gcc version:
dpkg -l gcc* | grep ii
ii gcc 4:4.6.3-1ubuntu5 GNU C compiler
ii gcc-4.6 4.6.3-1ubuntu5 GNU C compiler
ii gcc-4.6-base 4.6.3-1ubuntu5 GCC, the GNU Compiler Collection (base package)
Any idea or solution about it?
Thanks in advance
[attachment deleted by an evil time traveler]
-
There's no reason to try to compile WCS code as-is. Either use WCSOpen in its current state or wait for it to be more polished.
-
The WCS source is not, to my knowledge, Linux-compatible.
-
It definitely isn't, the WCS team added a fair bit of windows only code (e.g. keyboard detection, threaded ogg player, and other minor stuff that I've forgotten). I tried hacking it to get it to compile but there's too many things that'd need to be rewritten. If you just want to play, run it under Wine or try WCSOpen as Matth suggested.
-
Has anyone taken a look what they've done with the shield code? Cause I recall its ingame effect being better than what we have ingame now.