[ANN][MOTO] Motocoin

[HunterMinerCrafter]

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.

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.

[HunterMinerCrafter]

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!

[kuchitsu]

improving the game physics

pls make them like in elastomania:D

[HunterMinerCrafter]

improving the game physics

pls make them like in elastomania:D

Elastomania 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.

[WilliamLie2]

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:D

Elastomania 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.

There are several differences between Elma and Motogame physics:
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.

[WilliamLie2]

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.

[HunterMinerCrafter]

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:D

Elastomania 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.

There are several differences between Elma and Motogame physics:

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?

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?

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.

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?

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?

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!

[WilliamLie2]

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.

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?

Time period is the same as in Elma, I don't think we need to change that.

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'm talking about gameplay speed (that you can change with z and x), not fps.

[HunterMinerCrafter]

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.

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.

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.

[WilliamLie2]

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.

[HunterMinerCrafter]

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?

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?

Time period is the same as in Elma, I don't think we need to change that.

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.

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'm talking about gameplay speed (that you can change with z and x), not fps.

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.

[HunterMinerCrafter]

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.

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.

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?

[WilliamLie2]

I just use mingw and the normal make flow on windows.

Are you running mingw on windows and able to build motocoin-qt?

[HunterMinerCrafter]

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.

[HunterMinerCrafter]

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! :\

[e1ghtSpace]

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! :\

What was the url to your master branch again?

[HunterMinerCrafter]

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! :\

What was the url to your master branch again?

https://github.com/hunterminercrafter/motocoin

I just re-merged the secondary work function, without the openssl dependency in motogame.  (Someone please sanity check my compact representation logic?!?!)

This code has been running on a testnet in testmode with a ~200% warp set on all the mining bots.  It appears to be stable, however, it also took about 20 re-targets before the secondary work function settled on a difficulty.  Since we're currently using the same 2000 block interval for the second target check, this ends up allowing for quite a bit of the work deficit created in a warp to go unpaid over time!  As such, I'm redoubling my stance that we should quickly follow this up with another change to apply the secondary target calculation at a more frequent interval.  (Hopefully *none* of this crap will ever become relevant/necessary because hopefully nobody will ever attempt any warp attacks to begin with, but "better safe than sorry" ofc!  It would certainly be preferable to constrain warp "steps" to tens of blocks instead of thousands, for hopefully self-evident reasons.)

I've also re-merged the median correction, since we are forking anyway.  This should accelerate (downward) TT adjustment by a very small amount.

Those 10k blocks are going by a bit faster than I expected... I had originally estimated them at just over 48 hours but we are already halfway there!  Should we delay the fork point more blocks?  Personally I want to see the network secured as soon as possible, so I'm all for sticking with the 100k mark.  Thoughts?

EDIT: Woops, just realized that I also let one of my private/internal patches slip through as well.  Perhaps the content of it is a bit "telling" but I'm going to just leave it and call it a feature. It will become a relevant patch for users soon enough anyway, so it wouldn't have been long before I released it.  It was just originally intended to go out along with some other "still secret" stuff. 

[WilliamLie2]

Why your indentation looks like garbage?
Also, please, resolve merging conflicts.

[HunterMinerCrafter]

Why your indentation looks like garbage?

Probably because I jump between multiple editors/tools that each have their own notions of how to handle indentation.  I'll make a formatting cleanup pass later.

Also, please, resolve merging conflicts.

What in particular is conflicting?  I'm away from my pc for 1-2 hours or so but when I'm back I can pull from motocoin-dev/motocoin and try a merge across.

[HunterMinerCrafter]

What in particular is conflicting?  I'm away from my pc for 1-2 hours or so but when I'm back I can pull from motocoin-dev/motocoin and try a merge across.

Did a very quick merge on laptop with cellphone.  Can't build/test until later, but it is pushed.