Done with map changes. Shouldn't ever get stuck now, and should also still pick up new work as it comes in.
Also, I quickly bound the map filter options to a key so you can select between no map filtering, and the two map filters minim1ner released.
However, I just realized that the secondary work code in motogame got lost somewhere during the other patches. I'm going to have to work that back in very quickly. Noone build against master right now! :\
Topic: [ANN][MOTO] Motocoin - page 53. (Read 178256 times)
I just use mingw and the normal make flow on windows.
Are you running mingw on windows and able to build motocoin-qt?No, a cross build on a linux host. I've not really tested any of my windows builds, though, and mostly only ever build daemon and motogame, not qt, just for the sake of making sure they build at all.
I have not seriously tried to build anything directly on windows in quite a few years.
EDIT: Yah, right now windows motogame doesn't build with whatever gcc3.x my ming is using. I'll look into that more after I clean up the map search.
I just use mingw and the normal make flow on windows.
Are you running mingw on windows and able to build motocoin-qt? You don't need Ubuntu itself, gitian runs Ububtu in virtual machine.
Yes, I meant I explicitly make it a point not to run ubuntu anywhere if I can avoid it... VM or no.
Quote
Gitian is usefull not only for signing but also to produce statically linked builds for Windows, it is possible to do it in some other way but gitian works just fine for that.
I just use mingw and the normal make flow on windows.
Quote
I'm worring not about patches from ltc but about usage of C++11 things like system_clock that may be not available in earlier gcc version that comes with 12.04.
I see. system_clock is only used for srand() which we can easily change to a more traditional srand(time()) sort of thing. Are there other C++11isms that stand out? Sorry, these days I often don't even give a second thought to the fact that I'm using the new stuff, "c++0x style" is just becoming second nature now, heh.
Can you try a build and pastebin output so we can see roughly how many issues we are talking?
Are you a developer on Elastomania as well, or is there some existing reverse of the physics engine? If so, could you point me to it?
I reverse engineered it several years ago just for fun to change physics.Neat! Do you have anything like pseudo-code that you could share?
Quote
Quote
Quote
3. Rotation. Elma has some strange logic for rotation that is a little bit different from Moogame but I think this is almost unnoticeable.
I think the simple force addition that moto does is fine. Obviously the most noticeable thing is the rotation time limit being a little short. Do you anticipate any problems if we simply reduce this time constraint?
Are you sure? From my brief time playing "elma" it felt a bit less constrained, but perhaps this was just a perceptive psychological effect. In any case I think it should be loosened up a bit (even if it does match elastomania exactly right now) to make the game less frustrating. (In elastomania the levels appear to largely be designed with this rotational period explicitly accounted for. Much of completing levels seems to come down to "start your rotation at just the right moment to clear terrain" where in moto our terrain is entirely random, so *quite* often you find yourself griping things like "if i could only start that next turn a split second earlier I could clear through that gap." Maybe it is just me, but personally I find this the most "aggravating" thing I run into when trying to pretend-human-mine.
Quote
Quote
Quote
5. Time speed. Default time speed is probably different in Motogame.
I think at 250 fps resolution the motogame physics are likely much more finely calculated than in most games!Ah, ok. Sure, but the very existence of the ability to play at any arbitrary speed makes the "accuracy" of the default somewhat unimportant, IMO.
I do not usually run ubuntu anywhere so the gitian patches are not tested, I've only built with qmake. However they are directly carried over from ltc patches, so I'm assuming that if ltc will build correctly we will build correctly. I understand the need for gitian to do things like release signing, but so far I've not been concerned with release building. I figured that I'd leave that to you so long as you wish to continue being "point man" for the project. When I have some time I'll look into setting up gitian machines so that I can test this build flow in the future.
You don't need Ubuntu itself, gitian runs Ububtu in virtual machine. Gitian is usefull not only for signing but also to produce statically linked builds for Windows, it is possible to do it in some other way but gitian works just fine for that. I'm worring not about patches from ltc but about usage of C++11 things like system_clock that may be not available in earlier gcc version that comes with 12.04. I just pushed more updates to my master branch.
I compiled it for Windows. Sometimes game stucks in infinite loop in goToNextWorld.This happens when mining on live net? It is likely related to my removing the additional parse call in the NextWorld loop. I'll try and rework this again so that it will intermittently parse (but without the issues my previous naive attempt had) and this should keep it from ever getting "stuck" searching for a good world in a single work's nonce space that has none.
Quote
In for fun mode it usually generates just one or two maps and switches between them on F6.
This is normal, as there are only so many good "fall-through maps" for a given work item, and the forfun mode doesn't ever get new work so you just see the same maps getting found over and over. I have some patches which I've been using in testing that call getWorkForFun again before each map generation, I'll include these in my next push.
Quote
Have you tried to compile it on Ubuntu 12.04? That is what gitian uses and last time I checked it wasn't being able to work with newer distributions.
I do not usually run ubuntu anywhere so the gitian patches are not tested, I've only built with qmake. However they are directly carried over from ltc patches, so I'm assuming that if ltc will build correctly we will build correctly. I understand the need for gitian to do things like release signing, but so far I've not been concerned with release building. I figured that I'd leave that to you so long as you wish to continue being "point man" for the project. When I have some time I'll look into setting up gitian machines so that I can test this build flow in the future.
Are you a developer on Elastomania as well, or is there some existing reverse of the physics engine? If so, could you point me to it?
I reverse engineered it several years ago just for fun to change physics.Quote
Quote
3. Rotation. Elma has some strange logic for rotation that is a little bit different from Moogame but I think this is almost unnoticeable.
I think the simple force addition that moto does is fine. Obviously the most noticeable thing is the rotation time limit being a little short. Do you anticipate any problems if we simply reduce this time constraint?
Quote
Quote
5. Time speed. Default time speed is probably different in Motogame.
I think at 250 fps resolution the motogame physics are likely much more finely calculated than in most games!If anyone knows of any reason why these patches should not be deployed, speak now or forever hold your peace!
Yes, is there are anyone who is against these patches?improving the game physics
pls make them like in elastomania:DElastomania proper is closed source and uses a proprietary physics engine. This would make it difficult to replicate those physics. There is the open source XMoto clone which we could draw from.
I think the biggest "low hanging fruit" limiting factor in realism of the physics right now is probably the rotation time constraint. I don't think reducing this constraint would be problematic.
Are you a developer on Elastomania as well, or is there some existing reverse of the physics engine? If so, could you point me to it?
Quote
1. Head position calculation. In Motogame it is computed in almost the same way as wheel positions while in Elma it is more complicated.
I assume it is more similar to XMoto, where the body is segmented, and not just a set of spring forces, yes?
Quote
2. Brake. I think this is caused by the way collision between wheels and ground is computed. It uses linear approximation of perlin noise in wheel position and that causes some artifacts. Or maybe I just screwed up somewhere.
I've noticed that when breaking on ground the bike will often tend to "slide" much more than it seems that it should.
Quote
3. Rotation. Elma has some strange logic for rotation that is a little bit different from Moogame but I think this is almost unnoticeable.
I think the simple force addition that moto does is fine. Obviously the most noticeable thing is the rotation time limit being a little short. Do you anticipate any problems if we simply reduce this time constraint?
Quote
4. Wheel rotation doesn't affect whole bike rotation. There were some problems in converting it from floating point to fixed precisions so I just removed it.
In general, I think there is a bit of loss in the move to integer physics. There are various approaches to precise real precision arithmetic without floating point portability woes. Should we consider moving to that sort of a solution?
Quote
5. Time speed. Default time speed is probably different in Motogame.
I think at 250 fps resolution the motogame physics are likely much more finely calculated than in most games!
I just pushed more updates to my master branch.
I compiled it for Windows. Sometimes game stucks in infinite loop in goToNextWorld. In for fun mode it usually generates just one or two maps and switches between them on F6.Have you tried to compile it on Ubuntu 12.04? That is what gitian uses and last time I checked it wasn't being able to work with newer distributions.
If anyone knows of any reason why these patches should not be deployed, speak now or forever hold your peace!
Yes, is there are anyone who is against these patches?improving the game physics
pls make them like in elastomania:DElastomania proper is closed source and uses a proprietary physics engine. This would make it difficult to replicate those physics. There is the open source XMoto clone which we could draw from.
I think the biggest "low hanging fruit" limiting factor in realism of the physics right now is probably the rotation time constraint. I don't think reducing this constraint would be problematic.
1. Head position calculation. In Motogame it is computed in almost the same way as wheel positions while in Elma it is more complicated.
2. Brake. I think this is caused by the way collision between wheels and ground is computed. It uses linear approximation of perlin noise in wheel position and that causes some artifacts. Or maybe I just screwed up somewhere.
3. Rotation. Elma has some strange logic for rotation that is a little bit different from Moogame but I think this is almost unnoticeable.
4. Wheel rotation doesn't affect whole bike rotation. There were some problems in converting it from floating point to fixed precisions so I just removed it.
5. Time speed. Default time speed is probably different in Motogame.
improving the game physics
pls make them like in elastomania:DElastomania proper is closed source and uses a proprietary physics engine. This would make it difficult to replicate those physics. There is the open source XMoto clone which we could draw from.
I think the biggest "low hanging fruit" limiting factor in realism of the physics right now is probably the rotation time constraint. I don't think reducing this constraint would be problematic.
improving the game physics
pls make them like in elastomania:D
I just pushed more updates to my master branch.
This includes the "missing" patches from my last push (the testnetbox and ltc dep upgrades) as well as fixing the bad merge of the getchains patch and the missing debug.h file.
I've also reverted a small portion of the "MapSeeker" patch which was potentially problematic, and fixed the merge of it as well. (Map generation time should be fast again.) I'd still like to correct the secondary map filter, and put the whole thing behind some gui options, but this will have to wait. (Is anyone even still human mining at the moment, anyway?)
Finally, although I had previously thought that we could get away with executing the fix without formally forking, I think that I was basing this on some bad rationalization. After some experimentation I've decided that it will be best (probably even necessary) to play things safe and explicitly hard fork, with a protocol version increase.
As such, in my patches the fix is now enabled for live net with a fork coded for block 100,000, and with block header version bumped up to 3 to prompt user upgrades. An upgrade window of roughly 10k blocks should be enough time (2-3 days-ish?) for builds to be made and for people to upgrade.
If anyone knows of any reason why these patches should not be deployed, speak now or forever hold your peace!
This includes the "missing" patches from my last push (the testnetbox and ltc dep upgrades) as well as fixing the bad merge of the getchains patch and the missing debug.h file.
I've also reverted a small portion of the "MapSeeker" patch which was potentially problematic, and fixed the merge of it as well. (Map generation time should be fast again.) I'd still like to correct the secondary map filter, and put the whole thing behind some gui options, but this will have to wait. (Is anyone even still human mining at the moment, anyway?)
Finally, although I had previously thought that we could get away with executing the fix without formally forking, I think that I was basing this on some bad rationalization. After some experimentation I've decided that it will be best (probably even necessary) to play things safe and explicitly hard fork, with a protocol version increase.
As such, in my patches the fix is now enabled for live net with a fork coded for block 100,000, and with block header version bumped up to 3 to prompt user upgrades. An upgrade window of roughly 10k blocks should be enough time (2-3 days-ish?) for builds to be made and for people to upgrade.
If anyone knows of any reason why these patches should not be deployed, speak now or forever hold your peace!
just a question, once this game has been tweaked to work nicely, will you produce a second game that uses the currency?
I'm confused as to what you mean. The game doesn't use the currency, the currency uses the game. If you had a different game you'd have to have a different currency network for it to secure, as well.
Quote
Something a bit more enjoyable to play, and nicer to look at?
Wouldn't it be ideal to improve the enjoy-ability, play-ability, and appearance of the existing game? This is how I would approach things.
I would recommend you to think about more immediate issue - year 2106 problem. But this is probably irrelevant because all current cryptocurrencies will be destroyed by quantum computers much sooner.
Things like the 2106 problem are easily addressed with very trivial changes that don't even need to be changed at the protocol level, for example simply allowing the overflow. These things are also not specific to moto, so we can expect some solid patch will come along from upstream long before it is an issue, so we probably shouldn't even need to expend any effort on thinking about it.
Things that are specific to our coin, like "so just how does the network's subsidy behave in 200+ years, assuming things like crypto primitive changes to handle quantum etc..." are still valid questions regardless of anyone's opinion on if a total cap is best or not. When it comes down to issues like "this bug means X for this coin network specifically, on some future date" the existence of that bug factors into an assessment of the coin. As I've illustrated already, some very silly conclusions like "sell all at 1 SAT now!" can be erroneously drawn from some of this, but some valid conclusions can be drawn as well. Should moto happen to persist, I wouldn't want to be the guy sitting here a couple 1000s years from now cursing my ancestors for making some silly rule that to send 84million+ coins one has to also spend 84million+ coins. As an investor today, I might wonder how others would perceive the developer's "shrugging off" such oversights in the implementation (which are usually "standard bullet point items" for an alt. Most any ANN post on this board will have a bullet listing total subsidy details, and you really want what is announced and advertised there to be truth!) and might wonder what else they've overlooked in their fork from ltc.
What is most troublesome right now, though, is that both camps in the "should it be capped" debate would be dissatisfied with the current state. We have an infinite subsidy, but an effective cap at an 84million coin denomination, at which it becomes impractical to spend. Pragmatically, the network fails to meet either proposition. (EDIT: and my real concern is in what other still unknown ways it might fail to meet either. IMO it really needs to pick one or the other and implement it as such, completely and correctly, end to end.)
In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon. Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.
Can you be more specific, what are "these rpc calls"? I'm not an expert in all of the bitcoin rpc calls, which call depends on total supply? What "these things" except total supply are you talking about?My apologies, I was confused. I guess there aren't any of these work details exposed in the stock rpc set. From a quick skim over some things, it looks like the only thing directly affected in the reference wallet right now would be the block/tx handling.
(EDIT: But on a related note, we might want to look very closely at GetBlockWork before we do any check-pointing...)
Can you give me examples of what works wrong? I can't find any single issue.
Just try sending yourself 100million moto, for example.
(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)
Try to give yourself 100 million on Litecoin testnet and you will have the same issues, so what?On ltc there will never be 100million coins, because the subsidy stops.
Further, it introduces some funny questions in protocol. Our network might currently accept a block of larger than the max block size (which could create all kinds of ancillary problems) as long as you're willing to pay an 84million coin transaction fee. If you want to send someone more than 84million coins, it is allowed but you can only do so if you pay an 84million coin tx fee in addition. (I'm not making this stuff up! Look at the control flow of GetMinFee, I LOLed.) Sure, these are problems that no-one would/could hit for a very very long time, but they are bugs to be fixed none the less.
In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon. Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.
Can you be more specific, what are "these rpc calls"? I'm not an expert in all of the bitcoin rpc calls, which call depends on total supply? What "these things" except total supply are you talking about? Can you give me examples of what works wrong? I can't find any single issue.
Just try sending yourself 100million moto, for example.
(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)
Try to give yourself 100 million on Litecoin testnet and you will have the same issues, so what?On ltc there will never be 100million coins, because the subsidy stops.
Further, it introduces some funny questions in protocol. Our network might currently accept a block of larger than the max block size (which could create all kinds of ancillary problems) as long as you're willing to pay an 84million coin transaction fee. If you want to send someone more than 84million coins, it is allowed but you can only do so if you pay an 84million coin tx fee in addition. (I'm not making this stuff up! Look at the control flow of GetMinFee, I LOLed.) Sure, these are problems that no-one would/could hit for a very very long time, but they are bugs to be fixed none the less.
In terms of more immediate term needs, things like "work progress" are relative to this 84 mil cap number, so even today some tools which expect to see reasonable values for these rpc calls can't work with the reference daemon. Either some meaningful definitions for these things need to be established, or the "extra meaningless data" should be removed.
Right now there are a few issues with the total subsidy. There are quite a few "motocoin TODO" notes around the source related to it. Personally I think we should actually cap total supply, but this would need discussion.
It is well understood that scarcity is a necessity, but it is largely an open question as to what parameters this scarcity can/should have for a successful coin. Did Satoshi ever give strong criteria for a finite bound? Is 42 or the "one" coins inherently better because they are more finite? Personally, I'm not so sure. I think as long as the security parameters "fit together" to establish an appropriate security threshold on the consensus the actual numerical values chosen for this cap (and some (but not all) other factors) are not so relevant. If, as long as there is relative scarcity, we can accept that there is no pragmatic difference between having the one coin, the 42 coins, the 21million-ish coins, the 84million coins, the 969 quadrillion coins, why not extrapolate out to "the virtually infinite coins?" Of course it can also be said that nothing is ever really without some finite bound, even when we say the total supply is not capped it is of course a little white lie, there is and will always be some finite bit-width to balances which cannot be exceeded. There is only so much accessible energy in our universe.
Yeah, I have doubts. Why whould we cap the total supply?
MOTO does have a scarcity function and although it is relatively less scarce than, for example, btc it will at least attempt to meet some measure of scarcity criteria, as is. I think it is, however, a bit of a discomfort to many people (particularly cryptocurrency speculators) to not know ahead of time this measure or the very-long-term net effect of that scarcity. With a finite cap, it is very easy to point to a particular span of time and declare a relative scarcity. With a scarcity function as moto has currently it is left as something of an open question as to how effective the utility of that scarcity function will actually be, over time. To compound the psychological impact of this, the utility becomes even more questionable at ever increasing scales of time, so when people naturally extrapolate out to "at some point in the ridiculously distant future there will be more of this token than anyone could ever possibly want" they conclude that the token must ultimately be of virtually zero value, and as such they should not hold it. Even if they concede that it only asymptotically approaches zero, they will still devalue the coin simply because it will, eventually, overcome the utility of the scarcity function and approach that zero.
Never mind that they may be extrapolating well beyond any meaningful scale. By the time we are down to 10% of the relatively scarcity of btc, a few hundred years from now, everyone reading this thread today will likely be long gone. (From there down to less than 1% of relative scarcity is a mind boggling time-frame, in financial terms.) If you consider scarcity alone to be the primary source of value, and really do use a decades-per-candle chart to trade on, looking hundreds of years out (maybe you are investing to build a college fund for great great great grandchildren or something) you should still conclude that this puts moto at around $60 without any other factor. Anyone extrapolating all the way out to "this coin is not scarce enough on a long curve so I'm going to value it at one satoshi" (yes, some/many people really do think this way) is probably not considering just how long of a curve we are really talking about!
And yet they extrapolate. Because of this natural (and arguably even rational, maybe the investor really is considering his lineage generations out) risk-aversion behavior many coin developers feel it best to simply put the whole question to bed and enforce finite supply. The ones that don't tend to be the ones that also, for one reason or another, don't "take themselves seriously" which further leads speculators to feel that they shouldn't take seriously any coin that tries to go against the grain.
I entirely understand why moto chose to go the other direction, and leave the question open. It will not be trivial to cap the supply, and not create an eventual (though still likely decades-to-centuries away) alternative problem, where we hit a bit of a catch-22 where no-one is left with motivation to mine the coin until a large set of transactions reach mempool, but at the same time no-one would want to use the coin because tx processing will be slow because there are no active miners until tx records come in! This problem is solvable, but I'm personally not surprised that the implementation did not attempt to solve it. Any of the things that you can do to solve it will take a lot of work.
From a purely intellectual perspective, I find it entirely reasonable that a coin with a scarcity function like MOTO's could/should/would work just fine. From a "let us make moto a successful experiment" perspective I tend to agree that it is likely best to simply not leave the question open in the first place and declare a final, total block subsidy cap.
when we hit the ltc coin caps
What does that mean?
Although ltc could stand for something else.
I'm referring to this
Code:
/** No amount larger than this (in satoshi) is valid */
static const int64 MAX_MONEY = 84000000 * COIN; // Motocoin-FIXME: max amount
inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
This section of code (and some related control flow changes elsewhere, also) affects, in relatively small ways, things like fee calculation, transaction validity, network work statistics, and more. They are all minor problems, but a lot of the things that "just don't work quite right" in the wallet/daemon (and in particular the rpc commands) hit this particular group of changes relative to upstream Litecoin.
(EDIT: I should also point out that the set of things that don't quite work right increases quite a bit if you do something like give yourself 100million coins on a testnet!)
Try to give yourself 100 million on Litecoin testnet and you will have the same issues, so what?Jump to: