[niffiwan]

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.

[Mastadon]

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:

Code: [Select]

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



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?

[Mastadon]

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.

[niffiwan]

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.

[Mastadon]

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.

[Mastadon]

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?

[MatthTheGeek]

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.

[Mastadon]

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.

[MatthTheGeek]

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.

[karajorma]

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?

[MatthTheGeek]

I had this, 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.

[Mastadon]

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.

[niffiwan]

Sounds like a good idea

[praseodym]

Hi folks,

here is my make.log from the compilation on Ubuntu 12.04 32bit and the following gcc version:

Code: [Select]

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]

[MatthTheGeek]

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.

[Phantom Hoover]

The WCS source is not, to my knowledge, Linux-compatible.

[niffiwan]

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.

[Spoon]

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.