publishing an intermediate release 3.1.0?

The ch1/ch3 topic is also in the gui when displaying boxes / bars and it is annoying there...
How much shall we change automatically?
I thought about adding a new class of sources like "protocol-throttle" (silly name, I know) which can be replaced by the throttle channel of the protocol. This way we could define everything protocol-independent. But this will need many changes.

BTW, I updated the zips in my download area .

FDR wrote: The Ch3 could be used in a lot of places as source or switch. They should be all exchanged, if you want the same behaviour...

Actually I only change the first five channels of the mixers accordingly to the protocol. If one channel is used somewhere else (input, switch, box, timer, ...) it is not changed.

I just have seen that when you
(1) select a new model
(2) load template "6-ch-heli"
(3) change protocol (to DSM)
the resulting mixer is not what I expected to find... ch3 has the throttle curves...
You will get the correct result if you first change the protocol and load the template later.

It seems that my solution works fine only with empty model configs.

I see no option other than to abstract the Throttle (and other assignment names) one level higher and set the assignments to a channel based on the protocol selected. But that would break deviation's ChX principle for assigning channels.

Looks like a lot of work, but probably necessary if we want a seamless protocol change.

I am new to deviation but sucessfully flying some small planes and a quad with the DSM2/X on a Devo10 since a few weeks. In general the work done before was really great up to August this year. As far as I understood PB is not active (at the moment). So, I fully agree with you to continue this work.

Yesterday I took a look into the development section by chance and found out that some of you realised an update. Normally I do not care about development anymore . From my side which is meanwhile the user side only it was very difficult to retrieve the necessary information. I understood that FDR can edit the site and the forum. Please do so and place some sticky threads / pages with links in that manner that other users will be able to follow. Best would be one maintained page with all links to rbe's bitbuckets.

Today I rechecked and I was wondering that the executable version which I downloaded yesterday was replaced by a new one already. All still having 3.0.0 but another hash?! If every day a new nighly will come please mark them or use the version number (3.1.x) or whatever. Otherwise I expect new users will raise issues on 3.0.0 without knowing which version they do have.

In any case I will check the latest build this evening and try to give you some inputs if necessary. Thanks to all for the great work so far.

While playing around I have found some strage behavior when binding from the model page. Actually I think we make it worse if we try to fix this the channel mapping this easy way without thinking it to the end.

So I believe it will be better to revert the changes I made for #24 and take some time to think about the whole topic.

Personaly my vote is just to call them ch1 ch2 ch3 etc...

I have four? Ok, that's confusing. I easily can reduce it to the one we are talking about actually... just have to start to clean up...

But the tenor is correct. It will be harder and harder to find the most important work. To reduce confusion I have edited my first post to point to the actual repo.
The question of versioning: PB has only tagged very little commits with a new version number. We can break this because only the last is of any interest, but actually we have different versions circulating: 2.1.0, 3.0.0, some nightlies before the last, 3.0.0-c960b8e and now some of mine.
I try to tag my work with a number (and will try to increase it regularly) but 3.1.0 shall be the official inofficial intermediate release...

Ok, I found out how to tag versions.
My proposal: I call them betas: 3.1.0-beta-XX, start with XX=1 and count them up.

EDIT: looks like this:

Changed to "v3.1.0-beta-XX" with XX always 2 digits.

I have uploaded the first new-named zip-files. They all carry the version in their name.

If we need more than 99 betas I will better call them "alpha"

So what is the suggested development procedure? I always forked main repo and placed pull requests for it. I now have a minor issue in V202 protocol which I'd like to fix (transmitter id is calculated incorrectly, effectively limiting id space by 256). I can fork bitbucket.org/rbe2012/deviation-3.1 , but how we can make sure that all this development is propagated back to the original?

Is it possible to ask PhracturedBlue to add you, rbe2012, as a developer to his repo?

You can just clone or fork rbe2012/deviation-3.1 then make pull requests from your repo to his then it will all propagate back to his repo. His is a clone of PB's with all patches applied so far it would always be the most up to date. At the end if/when PB returns there is a single pull request from rbe2012 to the current phracturedblue/deviation repository and all our work will go with it to the top.

Sorry if I am repeating something you already knew.

I suspected so, but as I am a bit unsure of the difference between the clone and the fork it was useful. Thank you.