Test Flight Code
Pavido Scalf
It's the same for me. Unfortunately I can't use one of my apps now unless I enter the redeem code. As its for an entertainment app I'm not too bothered but if it happens with any other app TestFlight will be deleted.
PS after installing testflight app, you have to accept TOS. If you don't get an "Accept" button on iOS, go to desktop and accept same TOS then go back to testflight app and you will be able to use it. Many users, including me, didn't get an "Accept" button on iPhone.
People can't just come on devForums and beg*...they need to build and grow a network than involves devs and testers that focuses on the apps they're interested in helping with, then be invited via TF, then work to prove they are a reliable resource.
When you open your app in App Store Connect, go to "My Apps" and select your app. Then go to the "TestFlight" section, complete the "Information" section, and then add external testers as needed and the build to test.
Presumably what is happening is some users who haven't previously installed TestFlight (or who opened the link in an app other than Safari, which won't automatically open TestFlight for them) are clicking on the public link, which if opened on an iOS device shows: "Step 1 Get TestFlight".
And then instead of returning to the webpage after installing TestFlight and scrolling down and clicking the "Start Testing" button under "Step 2 Join the Beta", some users are mistakenly staying in the TestFlight app and either tapping the "Redeem" button as it is the only interactable element on the mostly empty default TestFlight screen or reading the subtitle that says to "contact the developer for an invitation code."
Unfortunately this is a natural consequence of the way this workflow is designed, and I don't see a simple way around it besides educating your users. Certainly one workaround is to invite the user via email, so they will get a code they can enter into the "Redeem" alert text field, but this should not be necessary.
It may seem obvious to technically-savvy people, but one can clearly see some people not understanding that they need to switch back and forth like that. Until this design flaw is fixed, a certain percentage will make this mistake. I suggest sending Apple some feedback about this.
This issue is happening to me also. Some customers are saying they are asked to enter the redeem code while using the public link for downloading the app from TestFlight, so they are unable to download the app.
But I still do not understand why the public URL for downloading the app is asking for a redeem code? And what will be the redeem code for people using the public link? Another interesting thing is it's happening only to some users.
My rep is too low to comment, but something you can also do is ask your testers to do a "long press" on the link. This will allow them to open the link in either Safari or TestFlight. Opening in TestFlight will sometimes resolve this issue.
For public links, when you click the link, it'll open a page with two steps to follow. The first step is to download the TestFlight app. The second step is to install your app. After you install TestFlight, go back to the link and press the install button on the second step. There is no need to redeem codes for public links.
If you're trying to renew a previously added a user, go to the same version you initially issued the code on. If you don't see reissue as an option, try deleting / then add new external tester. If you try to reissue the redeem code on a different (newer?) TestFlight version that option is unavailable. First time-adds should also show the reissue button after you send the first invite.
It typically happens when the user is not registered to the App Store and/or iTunes with the given email address. In my case it turned out that my tester gave me his iCloud email which was why he experienced the same issue.
I am the lead on this project; I have full control over appstore connect, I can publish the app to the app store etc. How on earth do I get access to test flight? What is this mysterious code invite code? I have opened the email, no code; I have opened the email on the iPad, no code. I have scoured over app store connect looking to generate this code. Nothing. How on earth do I get this?
The answer is the same. Contact the game developer, and request access to their TestFlight beta. If the game developer is currently conducting a beta using TestFlight, and is interested in your assistance, they can provide a code.
Test Flight is asking me for a code to be redeemed in order to proceed with testing. Evidently, We need to be invited by the developer in order to test. There is a fix for the navigation that is posted in the beta release that is not on the Apple Store version.
I am testing the latest version of the IOS companion from testflight, and when I send a PostFile request with a digital sound file with a request header with Content-Type configured to audio/mp4 or any other digital data type, the API server shows the event.body: null,
isBase64Encoded: false.
Any insight from your end? Is this an issue that happens only from the IOS companion? Anyway to test this using IOS companion? Other than the error sent back by the API server indicating no file received, there are no local errors triggered.
I am testing the Texting component under the IOS companion using version 2.64.6, I get the error " undefined variable. Irritants: (yail/com.google.appinventor.components.common.ReceivingState)
Note: You will not see another error reported for 5 seconds." When I try to set the receiving state to always. In order to receive a texting response from the recipient.
That said, Apple doesn't really provide any insight into receiving messages. The Texting component can initiate sending a message (via the Messages app), but I don't believe we get any information about whether texts are received. Depending on what you are trying to do it may not be possible in App Inventor.
The mod was never updated again since 2020. So, I've decided to adopt the config pack to revive, update, modify and expand it. This will be known under the new name "TestFlight-Stock" although you can still call it "TestFlight-Configs Revived" if you like.
TestFlight is an add-on originally made for the RSS/RO/RP-1 massive mod-suite that gives engines failure rates and modes, just like OhScrap and Kerbalism, and records reliability and ignition chance seperately. However, it also includes two unique features of it's own: Rated burn time and throttle curve. The former refers to the ability of an engine to perform reliably for a certain amount of time: After it passed that threshold, the failure chance increases significantly. Some engines also have TESTED burn time, which provides another certain amount of time where you can keep burning the engine after the rated burn time safely, and culmulative burn time, which means that the engines' rated burn time will be reset again after being shut down for a while. Throttle curve is an entirely new feature of TestFlight that provides unique throttle response rate for some liquid fuel engines. Just like OhScrap, an engine will become more reliable the more you fly and test it out. An engine can acquire at most 10000 "du" points through launches/flights that can help increase the reliability of the part.
TestFlight Config Stock, the official non-RO pack for TestFlight, is no ModuleManager config add-on. It's actually a set of JSON files written in order to lazily attach configs to the stockalike parts, and does not make full use of TestFlight's true potential. With TestFlight-Stock, failure rates are much more balanced and individualized: They will depend on the complexity, propellant type and tech level of the engines, whether being written in the part description itself (whether the part is stated to be explode-y or not is also taken in mind) or from the actual real-life designs of those engines. It also allows tech transfers, which is when an engine shares some of it's "du" with another identical/similar part. Parts can only share technology to those in the same manufacturer, propellant types, design/engineering principles and part families.
Visit the GitHub page for more info. For a short summary, I have decided to retreat TestFlight support for heat shields, add even more mod supports, balance starting and ending failure rates, fixing the MM blocks originally written by Starstrider to be compatitable with TestFlight 2.0, and more.
As KSP2 Early Access is now released, you may see a significant drop of interest in development of this add-on. There may be further work in porting the mod to KSP2, but as of now, there's no telling which direction I will take on TestFlight-Stock.
However, I'm not sure I understand all your design decisions. In particular, can I ask why you added ignition failures to all the monopropellant, nuclear, and electric engines? It's a bit confusing, given that these engine types don't have igniters (and IRL one of the few advantages monopropellant rockets have over bipropellant is that they will burn so long as fuel is flowing). The change also has some significant gameplay consequences, since it's harder to perform precision maneuvers with an engine that has a flat chance of failure every time it's bumped up to nonzero throttle.
@Starstrider42It actually shouldn't be called "ignition failures" anymore, more like "engine start-up failures" for me. Many things can go wrong in the start-up sequence, even monopropellant engines can have a poorly assembled valve that cannot handle high enough pressures.
Though, different propulsion methods have their own chance of failures. Nuclear thermal engines are approximately the same as chemical ones, while electric and monoprop have something like 99.9% and higher.
bd95a233a5