Well, I don't want to force anyone to go live in a pond or on a mountain, but I can say that your patching and repatching for this quirk is not behaving 100% optimally. I updated to .071, but the options still say 1.04, and I re-won a game that I know should be scoring around 10K in 1.05, but I'm seeing 77K (or about 4K "fixed") with the 1.05.071, which is clearly the old 1.044 scoring rearing it's ugly head. I'll try a complete reinstall later because I can't play with 1.044 scoring, m
Code Monkey
Top right corner (immediately to the right of the 'Screenshots' button).
[quote]And I repeat, I would MUCH rather fall competely off the metaverse then remain at some vastly diminished level of my former glory.[/quote] It's not so vast, though. The longer you keep at it, the more of your peak value you retain after you quit. Your method guarantees you disappear, while the decay with a basment method (or even the decreased weight with a basment) means that you could conceivably stay on top forever, you'd just have to have no life and play the game fo
CRAP! Now I feel like Stardock ;) :lol: When I added the enhancement of using a more real world set of data, I introduced a typo bug into my function to decay to 0 (dang global replace while forgetting to select 'whole words only'). As a result, in the graph up there in post #19, old scores are being dropped much too quickly from the data set. The 10% decay rate is fine, see this graph with the bug fixed: First, real world data set: http://filebox.vt.edu/~channum/m
It's using the same relative decay as the current method -> 10 months to obsolescence, therefore 10% a month. I can play with the numbers, but the curve shapes will remain the same since when scores gets pulled down remains fixed. A weighted 'average' system like you want is going to need to have some basement to make it palatable to the mainstream player. I've played around with both 10 & 20 & find that in scenario where your scores are gradually increasing that there's not much differ
1.05.069 In the attempt to fix the refresh behavior of the F2 Planet list screen when changing spending sliders, it got broken in all the others. Now, unless you switch to another right hand screen and back to it, it never refreshes. I noticed this when I was getting messages for completed projects that were still clearly showing *turns* left in the F2 screen.
Well, look up at the stickies for the 'Metaverse submission problems' thread and post your problem there. It might take a while, but T-Man (Patrick Ford) will look into your problem specifically to see if he can help.
NOOOOOOOOO! :sniff!: If this is the case, I'm glad I've spent the evening watching Comedy Central and generating Excel graphs rather than playing on my current game. Dangit, I must learn my lesson: never update without archiving first, no governors is better than the godawful scoring method of 1.044. Oh well, if they don't get an update out tomorrow to fix this, I guess I'm going to have to find something else to do this weekend, that or try the stand alone of 1.04 in the mean
Funny thing is that in a more real life scenario, a pure version of your method blows chunks imo, my method of raising the basement holds up better, but the fixed weighted average method I tossed out as a modification to yours actually seems to work best, interesting.
OK, last simulation unless anyone besides me is enjoying this and has some sort of good request. This is a more "real life" set of curves. The player starts off submitting every 2 days at 500 points. The score increases quickly at first, then more gradually (peaking out at 7750 points. The player's interest gradually dwindles until only 1 game every 20 days is being submitted. After 1 year, the player stops submitting altogether: http://filebox.vt.edu/~channum/metaverse/reallife.gif
I'm planning on doing that (need to rewrite the function that generates scores) just to show a more typical curve (including decreasing frequency and quitting before 4 years are up, that period is an artifact of how long it took the current system to normalize). This is barely any effort, well, barely any effort for an anal retentive geek when it comes to analyzing game mechanics ;) I wrote a program to run this simulations and export the data in a comma delimited file which
Scores show up immediately, so there's a problem there and you'll need to resubmit. Make sure the alias field is filled in with your 'Drizzt_DoUrden' and the email is the same one you registered GalCiv under. If you're using 1.04062, there's going to be a big discrepancy between what is displayed in your game and what shows up on the metaverse due to a bug in the ingame display. (That 8K will actually show up as ~800 points!). What you should do is update to 1.05069, load up yo
For the final irony of ironies, if we were to fix Staffa's "true" weighted system versus that abominable decay method by not lowering the weight to 0 but rather let it level off at, say, 0.2, we get the following: http://filebox.vt.edu/~channum/metaverse/fixedstaffa.gif Yep, the difference between my "flawed and fixed for a specific data set" and a fixed version Staffa's methods are nigh undetectable. And the difference between Staffa's original proposed fix and the current method are n
Another graph which shows why Staffa's idea is no different than what we have now: http://filebox.vt.edu/~channum/metaverse/staffa.gif To keep it in context, I made the decrease in weight 10% per month for 10 months (this is the same period that the current method and implied fix decays over). The only differences between Staffa's proposed 'weight to 0' weighted system and the existing system is it peaks and levels off slightly higher, doesn't have the slow decline and slow ris
OK, since a graph is easier to understand, here are some metaverse progression curves for some hypothetical player with each of the potential decay basements illustrated (20% is the current amount, 50% is what Brad implied he might alter things to today). While I appreciate the power of the weighted average systems proposed by Staffa and Ethermage, the truth is you're going to get the 2 line change to the current algorithm if you get anything at all. I think these curves illustrate nicely that m
It's independent of the data set actually. All I did was assume a player who submitted games with a fixed frequency and a given average score, beyond that, the overall curves are identical no matter what frequency and what average score is used, all that changes is the peaks and the magnitude of the slope. If I get bored tonight, I'll generate a nice line graph of the curve(s).
Actually, that's the point of both mine and Staffa's approaches. Your score under either system will reach a point where the rate of increase is minimal, it will continue to increase but much more slowly than before. For instance, with a 40% basement, it increases rapidly for about a year, then hits a point where every new score is tempered by every out to pasture score -> after 2 years of playing at the same rate, you'll only see a 25% increase over where you were at 1 year. Staffa's s
[quote]I would say that the max decay should be around 50%.[/quote] (Falls off couch, hits head, comes to, and re-reads screen to make sure he read it right) :D
@Bearcave and your dwindling comment: I know, that's exactly my point. If you stop the decay at 40% original value, your score will never decrease and always increase so long as you continue to be active at the same pace in the metaverse. However, it's rate of increase levels off around 1 year of participation. Simple and works without trying to figure out how to make a sliding weight system like Staffa wants.
So, because you've chosen to insist that your version of weighting is somehow THE definition of weighting everyone else is wrong? Staffa, you've blown this one way out of proportion, all weighting means in any system is that more or less value is assigned to an element based on some assigned factor. In T-Man's system, less and less weight is given to older scores. It's pedantic semantic arguing to try and say that isn't a weighted system. And, having already run some numbers my
Although the button UI doesn't come up for assigning these states to some of the ships (constructors and terrors stars), the hotkey assignments have always worked since the game shipped at 1.0.
RE: degradation T-Man posted the following schedule for scores decaying in the Metaverse problem sticky thread: 00-30 days = 100% original value 31-60 days = 90% original value 61-90 days = 80% original value 91-120 days = 70% original value 121 - 150 days = 60% original value 151 - 220 days = 50% original value 221 - 290 days = 40% original value 291 - infinity days = 20% original value @Staffa, that's as official as I've seen, and that is
Staffa, there's really no difference between weight and value (i.e. it makes no difference if I say your game is weighted at 20% of its initial value for purposes of calculating your overall score or if I say that it degrades to 20% of its initial value). The only issue is what the metaverse will display. I'd prefer it if it showed the original score and only used the degraded score for calculation purposes. The problem with the 20% basement is that it makes the accumulation of older, d
Oh, you are talking about your GalCiv serial number, I assumed you were talking about the unique game ID assigned to each game at creation. Sorry for misunderstanding what you were asking. I wasn't even aware the game stored our actual GalCiv serial within its data (although that is interesting to find out).
I'll be damned, but you are right, the game does not handle the calculation for this at all correctly. It sees a deal for 1 month as worth 2X a deal for 0 months even though the deduction to your treasury is just a one time deal for either one. I'm not sure where the bug is. Is a 1 month supposed to be like I described: money up front and another payment next month? Is the game's code really not even supposed to be displaying or dealing with 0 month deals and they should all be 1 month?