TFAR Needed refactor

[kavinsky]

Some weeks ago i have a conversation with @michail-nikolaev about the refactor of TFAR, doing some clean up and fix some issues and add new features to the project.

What do you think about this idea?
@michail-nikolaev @CorruptedHeart @dedmen

IMHO some parts of the API can be simplified, unify the radio features, and add a pluggable system for 3rd party, remove the Debug Mission and adopt the development environment the ACE Team has created.

Some part of the refactor needed are the split of the addon in separated PBOs by functionality so is easy to maintain.

[dedmen]

Yes i was just thinking about refactoring the teamspeak plugins project.
Just the structure of the files in visual studio as they are in no way
ordered. Also split some functions into different files and stuff. I think
its definetly a good idea.
We should also close all the old issues on github that are already solved
or were ignored for months/years.
Yesterday i also noticed all the textures are unavailable as they were
hosted on dropbox i think we could utilize git-lfs and finally do it right.

Am 16.09.2016 14:02 schrieb "Ignacio Muñoz Fernandez" <
notifications@github.com>:

Some weeks ago i have a conversation with @michail-nikolaev
https://github.com/michail-nikolaev about the refactor of TFAR, doing
some clean up and fix some issues and add new features to the project.

What do you think about this idea?
@michail-nikolaev https://github.com/michail-nikolaev @CorruptedHeart
https://github.com/CorruptedHeart @dedmen https://github.com/dedmen

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1111,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADl_ZVKWuw6k-yklAS0llqiIebMY_i-zks5qqoVqgaJpZM4J-3iR
.

[kavinsky]

updated the first comment.

@dedmen yeah reorganizing and refactoring the ts plugin and closing the most critical issues is needed.

i think @michail-nikolaev have the originals so he can sent it to the repo or post it when he has time when you can nkey :)

[kavinsky]

@dedmen if you are willing to do the refactor for the plugin, you are most than welcome as a collaborator.

@michail-nikolaev Maybe we should do a organization to manage it.

[dedmen]

Before we can think of refactoring we have to process all the open pull requests to not get conflicts. I was thinking about doing a bit of refactoring on the teamspeak plugin but even clicking the "format" button changed almost every line in the file. Where one problem is certainly that we also dont have a formatting standart ^^. And i held off doing a PR because Id need to change the project to VS 2015 which not everyone may be using yet and id break some other PRs with that probably.

[kavinsky]

@dedmen you're right, we should merge finished PRs before we start. But some of them are not worth to merge since most probably it will be removed or changed in near future. (i dont mean to delete it, just saving it for later)

[dedmen]

Yeah Id certainly take over all the C++ refactoring. Im good in scripting but not really confident enough to touch most of it.
Btw nice ID for this issue :D
What was holding @michail-nikolaev off on version 1.0 ? As i consider TFAR kinda featurecomplete right now. Was it just missing a major cleanup?

[kavinsky]

the ID is just perfect!

[kavinsky]

@dedmen Addme to Steam: Kavinsky Oss

[dedmen]

I added the 0.9.12 milestone which will probably be the last release before 1.0. That is because we need to push changes to master before we do the 1.0 release. Because the new Teamspeak version and CBA settings implementation are very important.
Also... why is there so much stuff in the 0.9.9 milestone although we are already on 0.9.12. I'd recommend not adding stuff to a milestone that is not really planned to be done then. There are issues in there that are inactive for 2 years.
Id like to add a testing branch so that master always stays stable. So we can easily merge pull requests into testing and do test builds from that branch. Right now if there is some error in a PR which we dont see beforehand. We may merge it and people may build and use master and expect it to be stable, which it wont be.
Sometimes by brain is just slow. We should add branches for new releases for testing and then merge them into master as that release goes stable. Instead of just pushing stuff into master and some day releasing it. And I'm feeling thats a very good idea because i just merged a 0.9.12 change into master. Has to be a good idea if i don't listen to myself right?

Also Id like to have a Slack team so we can organize this better instead of just writing everything into this issue.

Also i don't know where to leave testing feedback for new branches. Might be best to do that on Slack then.

[kavinsky]

put your email addresses here ill invite you to slack.

[dedmen]

testing list for 1.0

• Add keybinds for different speech volumes #887 #992

more work to do on.

• Add keybinds for different speech volumes #887 #992 auto activate PTT on holding down the modifier key. (Optional via CBA settings)