I found my missing qmake-qt4, it seems in upgrading to Fedora 17 it didn't give me qt-devel package, which now is qt-4 development package.

So I was able to do the qmake-qt4 to create a Makefile for the -qt version, and I added to its include and library paths my local dependencies dir so it could find my modified openssl that I custom made to include elliptic curve crypto that Fedora still does not distributed, and I added the -fpermissive that C++ now needs to make it ignore that fact that various things are not defined in the order that it now strongly prefers. I also had to add -mt suffix to the boost threads lib name, and add -ldl to the libs.

So now I have managed to compile the -qt version on Fedora 17.

-MarkM-

No one has used the pool for months so at end of November I announced it is closed instead of bothering to go through all the math with only me as user.

Thus I did not record the totals of each coin at end of month, thus cannot tell how much has been mined this month, so wouldn't now be able to know at end of this month how much to share out. The way to tell if it was working should have been simply the bitcoins p2pool would have sent you automatically, or the stats graph it creates per user.

p2pool is intended that people run it themselves anyway so if eventually people do get interested they can easily run it themselves it is almost trivially easy since it has support for merged mining built right in so just follow the instructions and presto your own personal p2pool with merged mining of as many coin types as you choose to tell it about. Plus you'd get to keep all the various kinds of coins, instead of being paid for them in devcoins like I was doing.

-MarkM-

What kind of patch? Some day we need anyway to try to apply the merged mining patches to a very recent copy of bitcoin, pretty much all merged mined coins will need to do that so figuring it out would benefit all of them.

-MarkM-

GRC? Hmm. Usually we have been using GRP to represent GRouPcoin.

Would you use BBQ, BBC, or BQC for barbeque coin if you had to fit it into three letters?

-MarkM-

Pay to play would certainly help ensure bitcoins are present. If it is wildly popular there should be no problem getting paying players.

If you encourage the use of botting then people can maybe feel more sure that they won't be wasting any of the time they have paid for, that other players who set up teams to ensure all their characters are kept active 24/7 will not have too much advantage over working folk who have money to pay for lots of characters but not time to actively handhold all their characters all the time.

We are looking into the logistics of doing something text mode along these lines and so far it is looking like the best model might be to fill waiting lists until a list for a particular type of server has 250 bitcoins pledged before buying hardware to run the configuration the waiting list that actually got filled is lobbying for. Basically let the prospective users vote for the type of setup they want by pledging up front so it is known for sure the hardware for it can be obtained and bandwidth arranged and so on.

-MarkM-

A MUD is pretty much a straightforward and human-readable API so seems like a good place to start.

With a MUD you know that any three dimensional graphics anyone's client likes to use to make it more appealing to the user or even to make the user have to look more carefully at more pixels in order to try to interpret what is supposedly happening are totally secondary, artists renditions of what the text says rather than being the actual events with the text being n author's attempt to provide an interpretation of what is going on.

Thus any graphical illustrations providers will be working from the exact same textual descriptions as the scripts that characters use to respond to events, and the scripts can entirely do without the bandwidth overhead of ever even asking for the/a graphically illustrated version.
We get to work from the original novel instead of trying to work from a chronicle of what some visual recognition subsystem thinks the patterns of light its sensors are reporting might represent.

We get to know whether a hit was made and damage done as a direct fact instead of having to worry about whether some 3d model artist correctly modeled a hit as being visually distinguishable from a miss. With OpenSimulator for example it is very easy to have objects waved around by characters appear to go right through other characters or even the character wielding them, so we do really need to just know whether to tell the visuals system whether to try to draw a hit or to try to draw a miss rather than relying on looking at visuals to try to figure out which it was trying to draw.

The problem of bots generating goods faster than characters who in effect dont really do a whole lot of work is maybe not really all that bad of a problem, its just the same old "immigrants work too hard, they take jobs from we conquerors who already beat up the natives of this place" complaint that has been seen at various times in various places in meatspace. I wonder whether Austrians and Keynsins differ on whether it is even a problem at all rather than simply 'the market" doing its job?

-MarkM-

Unfortunately there are lots of places in the code that should be using a constant that can be set in some header file where you plug in all the stuff that names which coin you are compiling it to be.

We changed pretty much only what obviously needed to be changed, the word bitcoin appears in variable names as well as in data the user gets to see, and with no idea of how the GUI really works I had to basiclly just guess in some places whether changing the word would help the GUI to keep the user aware it was a different coin or prevent the GUI from identifying correctly or working hand in hand with some internal name it might use to tell the operating system which coin type's GUI details it meant or to match it up with some variable all the different coins all use and all still use a name for which still contains the word bitcoin.

I expect somewhere the GUI code is getting confused between different coins' icon sets or something like that, or more than one coin type is telling the system tray the same name for which indicator on that tray to activate or de-activate.

If you start into trying to change every occurence of the word bitcoin you end up with a much harder to patch codebase since each coin type would change similrly (and comparing to some other coins is part of how I tried to check I had changed what needed to change), such as I have even seen a bitcoinrpc.cpp instead of rpc.cpp in some incarnations of the codebase even though it did not seem to be necessary that each coin have its own distinct coinnamerpc.cpp file really if constants differentiating coins were moved to some central plqce where they could all conveniently be changed.

There are new images/icons in the recent upload on sourceforge, as mentioned in a previous post.

-MarkM-

Actually it turned out that Xnova is horribly broken, it does not even have working combat for example.

So it would be 2moons I'd be botting instead. But yes, libcurl seems to be the way to go with that.

Hopefully we can start financing development, so we can consider fixing Xnova's combat or, probably more useful, making a 'port routine to 'port Xnova data over to 2moons; and to have a minimal-reply mode made for 2moons intended for bots to use so they get the info they need without wasting bandwidth on all the extraneous crap that gets thrown at humans. An "API mode" kind of thing I guess maybe, or iof not start just with a be brief flag all the display routines will honour by trying to limit themselves to just giving the raw facts.

-MarkM-

I don't want to cheat existing games, the only cheting I had in mind was to save hacking the source code of an open source game to build in npcs by instead running NPCs remotely.

Really this thing with the MUD is like that too, the proper way for an A.I. player to play is using only information other players have, not doing like freeciv's built in A.i.'s do which is cheat by looking at stuff they ought not be able to see. (They do stuff like knowing what units you have in your cities without having to move a spy unit to the city to spy on it, and knowing what is happening out of sight beyond their units lines of site and radar and such. And despite all their cheating they are still crappy opponents.)

It is kind of silly to waste time doing crap your computer could and thus probably should be doing for you. Your computer should be making games eqsier tp play, helping you play them, not helping big game companies waste away your time on grinding. It is probably more sensible really just to say "that will take you two weeks of grinding, so play some other character for two weeks while this one is assumed to grind" than to even bother actually running through the grind, were it not that by being out there grinding your character is an NPC out there for others to grind-upon. No monsters needed, the players are the monsters!

-MarkM-

It is probably best for web games to have a mode that does not waste bandwidth on crap the bots have no use for; a mode that just answers some simple query from the bot with some direct answer without wasting bandwidth on images and ads and so on that the bot has no use for nd that no human is going to see due to no human is at the computer at the time.

My frien'ds T.K.C. game, http://trollkeep.com/ , takes that approach.

-MarkM-

I find it easier to not forbid bots in the first place. Presto, using your MUD client's built in scripting is legal, go for it!

Or, write even better scriptable clients.

I think it is stupid to have to rely on image recognition, for one thing that implies the game is likely to be hard for blind people to play, so it isn't even an accessible game in the first place even for humans. People should be able to play using braille.

I expect actual competition in the game will likely end up showing its not the engine so much as the scripts that are key, but maybe not, maybe some things you just cannot do with normal MUD clients will turn out to give a major edge to clans that use some other engine to run their characters.

-MarkM-

The new version has a DHT network and visible nodes? All we had/have was/is our neighbors, who are almost all almost always offline.

Maybe with the ability to see 750 people you don't need to rely on your offline neighbors now?

The thing has crappy anonymity anyway, if you connect to me, you can see who all my neighbors are, so for any of them to be able to post something without you knowing its a direct neighbor of mine posting they;d have to set up a cutout node between me and them, which most people are not likely to do, especially when there are better systems such as Tor and i2p that are better designed from the start.

-MarkM-

That java thing is a play-by-email client that is currently mostly useful as a test of an installer program system that claims to build on linux an installer for windows. you are about the second or third person to report that apparently it does not seem to actually work on windows afterall. I have no idea why it does not work, it is a pretty famous cross-system installer-builder system. I am not even sure why an installer is even needed, I thought the whole damn point about java is it runs on any system. Maybe though it is meant to help with cases where someone packages u p some special graphics stuff or something that needs direct access to hardware thus gets specific to whether its 32 bit or 64 bit and exactly what kind of graphics card it is or something.

Basically if the installer thing doesn't actually work maybe just run the jar, a play by email tool doesn't seem like it ought to be doing anything that would be hardware-specific.

But the play by email thing also isn't going to bring in any coins currently, because the email address it sends the orders to is only looked at once a month or few months since each time I do look on the offhand chance someone actually did try the thing I see no emails there.

Since the Moneychanger GUI for Open Transactions is java, and they want an installer for windows, I made a new build of the thing so they could try my build of it and also of course the source code is there too so they can build it themselves and maybe build it better than I did.

Its a pain not being able to compile, isn't it? I remember when the Mac first came out, it was unprogrammable too, they wanted like $800 extra for BASIC, that computers normally came with. It was basically just a glorified etch-a-sketch, I was disgusted.

-MarkM-

https://sourceforge.net/projects/galacticmilieu/files/GRouPcoin/groupcoin-22-Aug-2012.tgz

-MarkM-

Testing using CoffeeMUD has revealed a whole further take on this; no longer is it just lets throw a few bots into some games, it is now closer to hmm how much do we even need humans in the games at all.

Basically it is kind of an offshoot of the idea of CPU mining.

(The two DevTome links above link to more info about this idea and where playtesting of it has brought us to so far.)

-MarkM-

Someone made new images, and they are in the latest source code on my github and my sourceforge files download site https://sourceforge.net/projects/galacticmilieu/files/

-MarkM-

Merged mining is already extending the early adopter period massively in effect, since anyone interested  in picking up something dirt cheap that could go up in value by orders of magnitude over a few years can still pick up merged mined coins of various kinds dirt cheap due to most miners still not bothering to pick them up.

The early adopter period could have been extended even longer by not creating exchanges for new coins until a couple of years down the line, or maybe even not until they reached their first reward-halving, so that they would remain under the radar quiet little windfalls for more people longer before the masses finally realise just how much they all actually add up to.

Bitcoins themselves are shamefully undervalued, but you can get a whole lot more namecoins for the same investment and they are probably even more undervalued than bitcoins, which makes them still an amazing early adopter opportunity even after all this time. They do have exchanges though so the masses maybe do realise they are at least worth something; the best opportunities would be coins without exchanges, if you are mining those you will be hoping no exchange opens up for them until a few reward-halvings down the line so you can enjoy low difficulty mining as many years as you can...

-MarkM-

It is centralised to the point where bitcoin is more than 51% of all blockchain currency both in value and in hashing power, which is a massive compromise of the basic concept of decentralisation.

Original poster, are you contributing to that by failing to mine the alt coins that are so low in difficulty that even with a single not very recent generation CPU you can pick up blocks several times per day still?

-MarkM-

This pool is now closed, due to lack of demand/use.

-MarkM-

Both GRouPcoin and DeVCoin keep generating coins forever, and that makes people think of them when looking for something to borrow-to-spend when they don't want to spend their collateral (their collateral being, ideally, coins/stuff that tends to appreciate in value).

The "only so many units ever" feature is indeed very powerful though, which is why more and more community-currency startups have been deciding ahead of time exactly how many units of their community's currency there will ever be. There are people out there that like deflating currencies, so I guess communities are maybe looking to appeal to such people by setting up their currency in a way they hope will help make it a deflating currency. Maybe they just like the idea of being one of the currencies people use as collateral/reserves more than being one of the currencies people borrow-to-spend.

-MarkM-