[Asprin]

Okay, looks like it is working... Here is the source: http://oldforum.oss.nov.ru/ojj/fs2open36XOSE.7z. Remeber, there are too many experimental things....

[The E]

ogod.

Now, to anyone wanting features from this in trunk FSO, it's going to take a while, as the code this was based on was forked back before .10 went final (I believe, anyway). So many things in there (especially regarding the HUD) are incompatible with the current codebase.

[Asprin]

are incompatible with the current codebase

...or you can't adapt them...belive me!

damn it! I CAN! But i'm only one from the whole OSS who support it...

[General Battuta]

Don't get me wrong, I have no doubt that this is an impressive amount of work, and the fact that you did it solo is very impressive. It's just a shame it couldn't have been done on the main FSO trunk so that you guys could have all the recent rendering and graphical upgrades and FSO could work with the expanded physics.

Hopefully the two can be merged into one beautiful whole.

[Asprin]

it couldn't have been done on the main FSO

No. It can. But our team is now working on new engine, including me...they have already forgot abot FSO. So, the problem is...i'm only one on this FSOOSE, and i'm still working on the twin-physics FSO engine.

[The E]

And with that, I think I'm not going to work on this.

Not because I'm unable to do it in terms of skill, but because I'm unwilling to accept large blobs of code into the codebase without having a developer that supports it and takes care of issues that come up.

To be clear on this, we could do it, but it would take a lot of work getting into the codebase, then merging the forks, then squashing all the bugs that appear. If the original developer is not available to work on this due to other commitments, this becomes very hard. There was a similar situation with post processing; We finally got that resolved in antipodes 6, but even that took something like a year.

Good luck with your own engine.

[General Battuta]

it couldn't have been done on the main FSO

No. It can. But our team is now working on new engine, including me...they have already forgot abot FSO. So, the problem is...i'm only one on this FSOOSE, and i'm still working on the twin-physics FSO engine.

I don't think you understand what I said. I was saying it was a shame this code couldn't have been written as part of the main FSO trunk.

[chief1983]

Well due to all the changes we've made since the fork, a lot of the code wouldn't come over with massive editing at all.  Anything related to the HUD would likely be invalidated by Swifty's new HUD code, etc.  Nothing much we can do about it probably then.  We've got code in the old IA codebase we probably won't be able to do much with either, that's just what happens when there's a fork.  Projects become more distinct.

[Dragon]

I think that implementing TMP HUD gauge layout with Swifty's code would only require changing targeting brackets (they way they're done in TMP is rather interesting), adding axial speed gauges (they'd be usefull for many mods that use sliding), making the message list and hull integrity stay on permanently, adding fuel, oxygen and inertial mode gauges and introducing alternative layout for targeting monitor. I don't know how difficult would it be in code, but it may only require adding a few table fields to certain gauges and a few optional gauges. I'd like to see at least some of HUD stuff (axial speed, targeting brackets, fuel&oxygen) implemented into FSO.

[chief1983]

Your "only" list sounds like reimplementing everything they did.

[Dragon]

That's exactly a list of things that are needed to reimplement everything they did.
I think that the exact reimplementation is not needed, existing gauges may be tweaked to work like TMP ones.
The only thing that would require major changes is targeting monitor, the rest are either things that sound simple to do (like making hull integrity list show up even if everything is fine) or include creating a completely new gauge.

[The E]

So, when will you get started on this?

[Dragon]

Once I learn to code. 
Some of that stuff could most likely be done in LUA (like axial speed gauges, there's a graphical indicator, so maybe it's possible to output the values to gauge text), while others would require implementing new feautres (I'm sure that there's a few mods that could use fuel&oxygen system, for example).

[chief1983]

Even still, whether or not it's difficult or needed isn't what we're talking about.  We're just saying that because the code fork is so old, simply using their code at this point is probably impractical, and it will take more effort than that to implement all or most of the features they've added since the fork.  But this is a release thread, sorry for derailing it for so long.  I do hope to download this and give it a shot, but is there a Mac build?  Or will I have to make one myself? 

[Dragon]

There's no Mac build in the download I got, so I'm afraid you're on your own.

[Thaeris]

The coding portion of this discussion is very interesting indeed, and I'd like to continue on with it...

...As such, could we get a split?

[General Battuta]

done

[Thaeris]

Thank you, Battman.

 

That said, I've noted several other interesting divergences from FSO's codebase; this includes Komet's Japanese localization of vanilla FS, with a few graphical updates here and there. As I noted that several of those features would be really helpful to have in FSO, what are some of the issues that prevents the features of older forks from being re-integrated with the newest versions of FSO?

[General Battuta]

Komet's stuff was already, I believe, integrated by Wanderer as part of BP dev. This is why those graphical upgrades are for the most part present in the 3.6.12 MVPs and War in Heaven.

[chief1983]

I don't recall if the localization stuff got in though, I haven't heard anything about it at least.