Please just create a thread here.

Win 8.1N x64
BitShares Light 2.15.286a

Forks can't have issues so you need to use the parent repos:

https://github.com/cryptonomex/graphene-ui
https://github.com/cryptonomex/graphene

Right, thanks for the info!

Tried again and it worked on the second try.

bump; same here + happened only with BTS claim. Others were ok on the first try.

Cool idea =)
bts: tora62

Understood, tnx 4 the info.
Will continue to spread the word 

Good luck with delegate positions & keep up the gr8 work!

In order to move up and onward as a pool, we need to find creative ways to keep the pool without a fee, and continue to be able to provide bonuses without continuing to rely on the delegate pay.
...
With this option, we will be able to capture the cost of spreads and transactions that we currently are losing to 3rd parties, and be able to bring it back to the pool.

For those that leave the MINING as a balance, we have the idea to use a portion of the balance to then rent additional hashing power to futher boost the pool and then have the gains return to the pool. It would be quite easy to have all the transactions of this respective process to show the cost of hash purchased and earnings on it's own and when it distributes the bonus to the pool. In other words, the longer you leave your balance in MINING, the further we can multiply it.
...
This will give the pool a number of sustainable sources for revenues, while being able to remain a no fee network with bonus.

 IMO, if you look from a point of view of a "small" miner (several GPUs or one or two mining rigs), taking into consideration an observation that a "sum" of small miners can produce a considerable amount of distributed hashing power, this is the way to go.*
 Why? - 'cause lowering or abolishing fees and adding bonuses is a great way to add to "small" miner profitability; when paired up with the multiplication of balance and an aspect that "small" miners are mostly in for the long haul, my conclusion would be that this kind of a pool would be the go to pool for such miners because it is the most profitable solution (myself included).**
 

I dunno.. are miners really going to want less significantly less profitability in trade of one or two more clicks? If I was given the choice to either keep getting my balance paid out to me daily in one asset or another, or have the option to have my balance contribute to more hashing power that can increase my overall return significantly at least until I choose to withdraw, I would just let it stay in the UIA and enjoy the stellar returns on my mining... When I need/want the balance to pay bills or whatever, I can just go to the market and take it out however I like in a few clicks.

In respect to the first sentence/question of the above qoute; no, they wouldn't. IMO, a lot of miners date to the age when everything was more complicated (setups, types of pools, exchanging currencies, etc.), so a few clicks more or less present a negligible level of added complexity in respect to possible profitability.
In respect to the rest of the above quote: exactly

* - Some would argue that summed up power of "small" miners could be disregarded in the grander scheme of things, and that may as well be true. But, look at it from a different perspective; every one of those miners is a crypto-enthusiast who could benefit the community as a whole in marketing ways (spreading word about something new (BitShares) or driving web traffic to related resources (for instance "X11 70% boost...", and such), etc.), market fluidity ways (miners are going to trade), and ways of increasing the divergence of the community in general (miners have other skills as well ).

** - "long haul"; small volume mining is a way to gain crypto in terms of simplicity if looked upon it from a stance that trading some of your resources (electrical power) is simpler than a fiat-crypto1-cryptoN trading which involves fees, 3rd parties and so on. Takes more time to "amount to something", but it is basically headless and you already heave the equipment for it (if you're a gamer, chances are that you already own a high end GPU which idles when you are not gaming).

So i voted for the UIA option, because improving the pool and increasing profitability in such terms is a win-win scenario.
Also, I think that hybrid option should be considered in the long term, if circumstances allow it, because it lowers the bar of complexity ("understanding the whole thing") for entry-level ("junior") miners.

voted for all six, good luck! =)

If I'm using two different models of cards; what happens?

If you use two instances of sgminer, each from its own directory*, and run them with switches --device or --profile-device (depends on your config) where argument of the switch points explicitly to a device, everything should be ok.

*-by default kernel file will be created (and then replaced with mod) in the directory from which the binary was called. For instance, if you use a script to call the sgminer binary with params in the same directory in which the binary is, that's the dir where kernel file will be created on the first run. But, if you call a script which points to the binary in a different dir, kernel file will be created in the script's dir.

For testing purposes, my suggestion is that you have two sgminer dirs, in which you create configs for each card respectively, and in them you use caller scripts with params. Each binary will create it's own kernel file in it's own dir, which you replace and rename.

Note; if your cards have the same kernel type, you could use them both with one sgminer instance and one modded kernel. But I don't have this kind of a setup, so I can't confirm.

Thanks for help.

No problem 

The client is extremely slow and needs too much cpu and ram, this is beyond any discussion.

It's gonna get better; already did, comparing last three updates - in my case, resource allocation halved since 0.8.2.
Remember, it's still actively developed, and ver. no. is less than 1, so give it a benefit of a doubt you would give to any other beta software.