Simon

Offhand, sounds like you're following a link (or cached/saved page) for "next unread topic" -- that will return the above message when there are no unread topics (e.g. you've marked the site as read).

What error message?

I'm going to regret this....but that's not how this works. That's not how any of this works. If your phone autofilled your credit card information (and you then sent it to the server) there would be a record of that (even if the credit information that was autofilled was no longer valid). There isn't. If your phone autofilled your selection of PayPal for a payment option, then you would have had to click through to go to PayPal. As stated above, that is a possibility for where the problem lies - you submitted (multiple times) payment while on PayPal, but for whatever reason you were never redirected back to the site, so the transaction could be recorded. IF this is what happened, you need to contact Jason (open a Support Request) -- he can check HERO Games' PayPal account. If he finds matching credits in the account, he can refund one of them to you and apply the other to your pending invoice on the site.

Then you never entered your card information on this site. ANY submission of card information (via any medium) is recorded as a transaction by the site. Even if the card number is invalid -- the transaction is still recorded (failed, but recorded). There's no choice for debit card because it is entered and used exactly like a credit card -- it is one from a charge perspective. The only case in which I can see a charge occurring for you but not being recorded by the site is if you selected "PayPal" as the option for payment during checkout -- that would send you offsite (to PayPal) to take payment, so the site doesn't record any transaction until PayPal returns you to the site (with payment confirmation). Note: I've merged your two threads, which may cause the replies above to become somewhat jumbled...but will hopefully help avoid any further confusion.

HERO Games did not take any of your money. You're currently running two threads simultaneously on this issue -- I'd recommend sticking to one so that you don't get confused over the advice you're being given.

NetSpend is the card that you used, not the payment method. 1. Were you using this site when you attempted to make the purchase? I'm assuming that's a yes, but best to be sure. 2. When you went to checkout on the site, did you select "Credit Card" (where you enter your card information directly on that page) or "PayPal" (where you are redirected off to PayPal's servers to handle payment)?

Were you, perchance, using PayPal to pay? If so, that could explain the lack of any transaction information on the site's side -- PayPal never sent the information back to the server (for whatever reason), so no payment was ever received. When PayPal is used for payment, you go off to PayPal's servers...it's only when PayPal sends you back to the site (with information on the transaction) that the site can know that a transaction has occurred -- there are no asynchronous checks that are performed. If this is what you did, then you'll need to contact Jason -- create a Support Ticket. He can see if there are any matching transactions on HERO Games' PayPal account and manually update the site accordingly. Failing that, you'll need to work with PayPal to resolve the issue.

Our program did not do that. That purchase was not made on this site -- there is a single transaction for that amount that occurred on that date...for a different user, in a different state (it was a successful purchase).

No, they didn't. There are no attempts at transactions under your account (or for that invoice) on this site.

As noted in the other thread you started for this: you have not paid for the product. You created an invoice when you added it to your cart, but there are no transactions related to that invoice (and no transactions for your account or any account in your geographic area) in the timeframe involved.

That's because you never paid for it -- you added it to your cart, but never completed (or attempted) the checkout process. The system tracks all transactions, including those that fail (invalid card info, rejected by the credit processor, etc.) -- there are no transactions related to the invoice that you created when you added the item to your cart.

A few things: 1. It wasn't the version of Java, per se, but the outdated libraries that the PDF functionality was dependent upon. Updating those libraries would have required significant retooling of the code. 2. No idea what the last version of Java was that the libraries would have worked under. 3. Would STRONGLY recommend never intentionally running outdated software like that. Java interacts very closely with your host operating system - you really want to keep up with updates to it as they are released.

Go to your Purchases page.

Have you gone to your Purchases page to download it?

That depends on the rules version that you're using (first item in my list, above). I'm assuming OP is using 5th Edition rules (where IPE checks the current/default Visibility of the ability). The Visibility rules were rounded out a bit under 6th Edition, removing that check for the current Visibility state of the ability (i.e. allowing IPE to be applied to an ability that is not "fully Visible" by default). [edited for clarity]

What Greywind said. General rules for determining default Visibility (evaluated in order, start with Visible = false): Visible if it is explicitly stated as such in the rules (i.e. the rules template sets Visible to true) Visible if it has "Based on CON" Visible if it has Costs END Limitation Visible if it has the "Visible" Limitation Not Visible if it has the "Invisible" Advantage

You’ve changed things again. So, standard Reserve with no slow bleed over time. REC gets the Limitation for only recharging at the base. Keep it simple for the non-com abilities - give them OIHID and done. Hero ID is defined as the powered suit. Suit has no power? You’re not in Hero ID - you’re Tony Stark with suit powered down, visor open, etc.

To take this another way: Your initial question was "How Much of a Limitation would Needs END Be?" Answer: None, other than Costs END (where appropriate) -- that's just how END-using Powers work. If you're trying to model not just Powers that use END, but an END Reserve which gradually loses power when away from its charging station (ala Bob the Human Roomba), then that's the effect that you model. You place a Limitation on the Reserve to reflect the loss of END over time. The value of that Limitation is based on the rate of the drain in END (how long it takes to lose power) and the GM's thoughts on how often that's going to occur in the campaign (how limiting that's going to be).

This is where you're being inconsistent. You want various Powers like Enhanced Senses to put a slight drain on the suit's "battery" (END Reserve) -- that's accomplished by having them use the END Reserve. They use END. You don't need or want to create some new Limitation that reflects those Powers using/requiring the Reserve to function - that's simply how END and Reserves work. Saying that you want those Powers to rely on the suit's battery, but not use END is being inconsistent in your definition -- they either need the battery to function (they use END) or they don't. So...you have Powers that take the Costs END Limitation as needed and are set to draw from the Reserve. These Powers will be taking negligible amounts of END relative to the combat abilities...and that's fine. You size the Reserve to let you use the abilities you would typically have active in combat (including those minor ones) for the typical time that you want to be able to operate at full power. Saying that the non-com abilities will slowly drain the suit's battery over a long period of time is something that you would simply define as a facet of a Reserve that can only be charged up at the base. Unless you really want to get into LTE rules (most don't), then you just define what this is -- you don't track END outside of combat, otherwise. The suggestion to use separate Reserves was based on your earlier explanations of what you were after (or my reading of them). Your current explanation is a straightforward END Reserve, with a Limited REC (can only recharge at the base)

That's an END Reserve. Anything that requires the "battery" to function costs END and is set to pull from the Reserve. If you're talking about months outside of combat for the minor systems to drain the battery, then don't worry about any Limitation on the Reserve itself (since it's not limiting) -- just buy the Reserve with enough END to last you the amount of time you'd like in combat, Limit the REC to only occur at the base, and you're done. Again, outside of combat, you're not tracking END usage in the same way...and avoiding dealing with LTE is not a bad idea at all (the reason it's listed as an optional rule). Powers that use the Reserve don't get some additional Limitation to reflect that they need the Reserve to have END or they go down -- that's just how END-using Powers work.

See previous response - you're not looking at it right...and it sounds like you're still figuring out the concept (or explaining it differently now). What you're describing with just a few non-com systems bound to the suit's battery is simply a matter of tying them into the same END Reserve as everything else. So one END Reserve, sized based on the amount of time the character should be effective in combat. You're looking to have the effect of END usage over long periods of non-combat time...but then not wanting to deal with the hassle of figuring END usage over long periods of non-combat time. So figure out what the effect is that you're looking to model. If I'm reading your most recent explanation correctly, you're looking for some non-com abilities to be bound to the suit's power supply....and the suit's power supply should be slowly drained by those non-com systems over a period of time (days). Non-com abilities that you want to function in that manner need to Cost END and be bound to the suit's END Reserve. This will have a negligible effect in combat....and out of combat you can avoid having to deal with LTE rules or any fiddly things like that by Limiting the suit's END Reserve (not the Powers themselves) -- easiest would be to use Limited Power to represent the END Reserve draining slowly over time when away from base (base the value on however often you want to track it -- loses 200 END daily, 10 END hourly, etc.). The Limitation value would be based on the GM's input for how often the characters are going to be away from the suit's power source for extended periods.

You're basing that calculation on 6 hours of combat. That's not how END works over time.

That’s all in figuring the reserve…in play, it’s pre-figured - reserve 1 will last for 2 days (or whatever). as for cost - that’s the concept.

The concept that he’s after is fiddly by nature (and questionably conceived, as noted above). I dislike handwavium to get around bad/fiddly concepts.

You're still just borrowing trouble. Buy 2 Reserves, if you want. Reserve 1 powers the essentials. Has a REC slightly less than the burn rate of the essentials. Any non-com ability that you want to run off of the suit takes the Limitations mentioned above (Costs END, Always On), where appropriate. Reserve 2 powers the combat abilities. Has a REC that only applies when at the base. Done. If you want Reserve 1 to only function when Reserve 2 is active (has END available), that's a simple Linked on Reserve 1.