You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason will be displayed to describe this comment to others. Learn more.
So this was the rename script. Interesting.
TODO: need to do some sort of git/merge magic to undo what this script did here in this commit, I think: 913f270
TODO: create a revert-merge-patch or whatever back to this this commit so we retroactively make the current FF codebase have SDKs that were renamed to FFs back to SDKs (or sdk, case to case): a4119e9
Then maybe a potential merge to 2013 will be a little easier at least, haha.
The reason will be displayed to describe this comment to others. Learn more.
Also, I think we can use merge magic (#Mergic) to take sdk 2006 to 2007 to 2013, and then apply those changes via some kind of patch or something. Am I right, is this possible? In my head movies it makes sense.
Are there patch files already for 2006-2007-2013? Who am I even talking to right now?
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure why that'd be a preferable route to take. You're basically saying we should take 2006 FF and try to patch it with the SDK updates? Why would that be easier than taking the updated SDK and patching it with FF? Way more has changed with the SDK between versions than FF has modified the SDK files, so that route seems like way more work.
We already have a list of everything FF changed with all the base SDK files (generated a while back but still should be fairly up-to-date, not including sdk_ files but there aren't many of those files): http://www.fortress-forever.com/diff/
We also have a start at porting to 2013 + improving the codebase while touching as few base files as possible here: https://github.com/fortressforever/fortressforever-2013 (IIRC FF movement is fully implemented, Luabind is updated and working, there's a start on a Lua-based HUD system, etc). This would be a fine place to start for any future port attempts.
Also worth noting that 2013 has problems of its own that don't really have trivial solutions (see, for example ValveSoftware/source-sdk-2013#213), and is in somewhat of a weird state as far as I'm aware.
I don't think there are any shortcuts to be had here. Either we do a quick-and-dirty port and get a somewhat functional and probably very messy/buggy result, or we expend a lot of effort on a well-done port and hope that we could eventually create something worthwhile. Personally, I'm skeptical of the benefits of both approaches.
The reason will be displayed to describe this comment to others. Learn more.
Yeah I know about all that stuff. I dunno, I'm just thinking about a way to get rid of the instances of "sdk" renamed to "ff" so it's easier to port any future engine changes. It's trivial, I know, but I've always hated this rename extravaganza (like the special FF skeletons instead of a source standard). There would still be FF-named things, but they'd be more specific to actual FF stuff as opposed to sdk instances renamed, aka avoid editing base files..
Plus direct porting from 2006 (to 2007) to 2013 is just super useful in general, that's all. In porting another mod from 2007 to 2013, I was thinking it'd be best to start at 2006 (_for more general usage). Then you'd have a way to convert any mod from 2006 to 2007 and/or to 2013 (_or at least a good reference).
The reason will be displayed to describe this comment to others. Learn more.
That's true, it could help with merging some of the sdk_ files, although I think that would always be something of a challenge with a mod that deviates so much from the base game.
a07dbc6There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this was the rename script. Interesting.
TODO: need to do some sort of git/merge magic to undo what this script did here in this commit, I think:
913f270
TODO: create a revert-merge-patch or whatever back to this this commit so we retroactively make the current FF codebase have SDKs that were renamed to FFs back to SDKs (or sdk, case to case):
a4119e9
Then maybe a potential merge to 2013 will be a little easier at least, haha.
a07dbc6There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, I think we can use merge magic (#Mergic) to take sdk 2006 to 2007 to 2013, and then apply those changes via some kind of patch or something. Am I right, is this possible? In my head movies it makes sense.
Are there patch files already for 2006-2007-2013? Who am I even talking to right now?
a07dbc6There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure why that'd be a preferable route to take. You're basically saying we should take 2006 FF and try to patch it with the SDK updates? Why would that be easier than taking the updated SDK and patching it with FF? Way more has changed with the SDK between versions than FF has modified the SDK files, so that route seems like way more work.
We already have a list of everything FF changed with all the base SDK files (generated a while back but still should be fairly up-to-date, not including sdk_ files but there aren't many of those files): http://www.fortress-forever.com/diff/
We also have a start at porting to 2013 + improving the codebase while touching as few base files as possible here: https://github.com/fortressforever/fortressforever-2013 (IIRC FF movement is fully implemented, Luabind is updated and working, there's a start on a Lua-based HUD system, etc). This would be a fine place to start for any future port attempts.
Also worth noting that 2013 has problems of its own that don't really have trivial solutions (see, for example ValveSoftware/source-sdk-2013#213), and is in somewhat of a weird state as far as I'm aware.
I don't think there are any shortcuts to be had here. Either we do a quick-and-dirty port and get a somewhat functional and probably very messy/buggy result, or we expend a lot of effort on a well-done port and hope that we could eventually create something worthwhile. Personally, I'm skeptical of the benefits of both approaches.
a07dbc6There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I know about all that stuff. I dunno, I'm just thinking about a way to get rid of the instances of "sdk" renamed to "ff" so it's easier to port any future engine changes. It's trivial, I know, but I've always hated this rename extravaganza (like the special FF skeletons instead of a source standard). There would still be FF-named things, but they'd be more specific to actual FF stuff as opposed to sdk instances renamed, aka avoid editing base files..
Plus direct porting from 2006 (to 2007) to 2013 is just super useful in general, that's all. In porting another mod from 2007 to 2013, I was thinking it'd be best to start at 2006 (_for more general usage). Then you'd have a way to convert any mod from 2006 to 2007 and/or to 2013 (_or at least a good reference).
a07dbc6There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, it could help with merging some of the sdk_ files, although I think that would always be something of a challenge with a mod that deviates so much from the base game.
a07dbc6There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
valve doesn't seem too concerned with source sdk anymore