Report message to a moderator

[Updated on: Thu, 04 November 2004 09:19]

Report message to a moderator

Well.. since I have a site, and all the freestars graphics, I might as well host it too Send it to me at user dot force at gmail dot com

Thanx
ForceUser

Report message to a moderator

Report message to a moderator

Hi,

icebird wrote on Thu, 04 November 2004 14:56

I'v got a spreadsheet that fairly closly replicates most of the race wizard, except for decreasing the hab ranges.

As some people may already know, there's been recent advances on this, in related fronts:

1) The planet hab calculation quirks have been uncovered and succesfully duplicated in at least 2 platforms: C/C++ and *gasp* JavaScript. Several tests have shown the accuracy of the new formulas. Code is available on request, but should ideally be hosted somewhere for public access.

2) The Racewizard has been shown to heavily rely on planet hab calculation, and its inner logic regarding PRTs, LRTs, econ & science has also been succesfully replicated. Preliminary tests show encouraging results, and working code should be available soon

Comments, suggestions welcome.

C U @ the Board!

Report message to a moderator

Report message to a moderator

Report message to a moderator

Hilton wrote on Tue, 15 March 2005 18:46

Feel free to email me anything Stars! related that needs hosting . I will put it online at http://www.freestars.org/.

Cool! I might send you something soon

Report message to a moderator

Report message to a moderator

Hi,

icebird wrote on Wed, 16 March 2005 17:44

The reliance on habability calculations makes a lot of sense,

Specially if the Jeffs coded it

Quote:

and explains why I can't make heads or tails of the way it works right now with simple algebra, as I would have expected.

No wonder. As far as I understand ConstB's code, a hundred planets are generated and tested for habitability, and the averaged results are (somehow) used in the final point calculation.

Quote:

I'll take a look and investigate next week to see if I can make it work with the hab formula next week (no access to Stars! for a while).

My tests with the published code show that it is already very nearly (or wholly) accurate. Might be worth it to seek a simpler/cleaner algorithm, though.

Note also that the "old" best-fit hab formula is no longer *the* formula. ConstB hit upon the real thing last week.

[Updated on: Wed, 16 March 2005 12:46]

Report message to a moderator

Report message to a moderator

[Updated on: Thu, 16 February 2006 17:45]

Report message to a moderator

LEit wrote on Thu, 16 February 2006 23:22

Looking at the code some more, that seems fine, there is another calculation later that works on the factories. I'm not sure what's wrong, but -f and AR races don't get the right points compared to the RW. Hmm, I found my problem with -f races, I'd written it down wrong, this code is correct for -f races, assuming you give it valid data...

Hi,

I was wondering if nobody else wanted to tinker with the code...

I'd be interested in your parser. I've already got a working JavaScript version of the RW code as published, which has shown accuracy at a variety of races tested.

Report message to a moderator

Report message to a moderator

LEit wrote on Fri, 17 February 2006 03:22

After double checking my races, I found that most of the errors were mine. However, no amount of checking fixed the problems with ARs. It may be that my assumption that ARs have factory settings of 10/10/10 are invalid, but I don't think that's it.

IIRC, the code ignores AR's factory and mine settings. It only takes the "AR eff" division factor into account, in place of the "colonist eff" of other races.

I shall check things a bit more with AR, and perhaps finish integrating the RW calculations into my html/javascript-based race econ calculator (which already has all the input interface conveniently in place) where they should fit in nicely.

Pls send me your AR settings (in the traditional format), just in case. Are the differences in results very significative?

Quote:

Still, getting all the rest of the things right is a big step in the right direction.

Glad to hear that. You might notice the RW code includes the *exact* Hab value calculation code, which I rewrote to simplify it (and published somewhere in The Academy), and also tested to 100% accuracy.

PS: I got your PM. It seems I'll have a busy weekend.
PPS: I see some of your AR testcases in your code. Good. We might want to standardize racedescription "DNA", though.
PPPS: You might notice the "GravClicksToGrav" array is no longer needed, as we also nailed down the accurate GravFromGravClicks calculation.

[Updated on: Fri, 17 February 2006 06:20]

Report message to a moderator

m.a@stars wrote on Fri, 17 February 2006 05:14

You might notice the RW code includes the *exact* Hab value calculation code, which I rewrote to simplify it (and published somewhere in The Academy), and also tested to 100% accuracy.

I'll look for it

m.a@stars wrote on Fri, 17 February 2006 05:14

PPS: I see some of your AR testcases in your code. Good. We might want to standardize racedescription "DNA", though.

Any standard would be fine, just as long as it's fairly easy to parse. The parser I've written is fairly rigid in some ways, and forgiving in others, but if there was a clear standard, it should be easy to parse it.

m.a@stars wrote on Fri, 17 February 2006 05:14

PPPS: You might notice the "GravClicksToGrav" array is no longer needed, as we also nailed down the accurate GravFromGravClicks calculation.

Where is this?

Report message to a moderator

LEit wrote on Fri, 17 February 2006 16:06

I'll look for it <snip> Any standard would be fine, just as long as it's fairly easy to parse. The parser I've written is fairly rigid in some ways, and forgiving in others, but if there was a clear standard, it should be easy to parse it. <snip> Where is this?

See this Academy thread:

http://starsautohost.org/sahforum/index.php?t=msg&th=229 9&start=0&rid=625&S=fdfca492d0e72c55f919e79b9d3f df95

Also, I still would need the "standard" description of your AR races to test the RW code, just in case your "DNA" is faulty.

[Updated on: Fri, 17 February 2006 15:07]

Report message to a moderator

Report message to a moderator

LEit wrote on Fri, 17 February 2006 22:02

AR;ARM,IS,NAS,RS;15;-1,-1;-96,16;18,84;10;N=W-P+C-E+B+;0 doesn't work, returns -93 A bit longer version of the race is: AR; ARM ISB NAS RS; 15% growth, gIMM, -96C to 16C, 18mR to 84mR; divisor 10; w&c cheap, energy normal, rest expensive; 0 points left over AR; ARM ISB NAS RS IFE NRSE; 16% -1g -1g, -40C 96C, 54mR 84mR; 10; n-w-p+c-l+b+; 8 doesn't work, returns 41 AR; ARM ISB NAS IFE NRSE; 16% -1g -1g, -40C 96C, 53mR 85mR; 10; n-w-p+c-l+b+; 0 doesn't work, returns 32

All of those are OK in my Javascript version. It must be some trick of integer math or something I fixed when playing with constB's code.

{It seems it was simpler than that, as tech costs are coded somewhat counter-intuitively in the RW code. Once that's been taken into account, all races tested are giving correct results. }

By the way, my version has a bit more comments and clearer variable names and such though it still would benefit from a thorough polishing/simplifying/cleanup.

[Updated on: Mon, 20 February 2006 11:41]

Report message to a moderator

Report message to a moderator

mazda wrote on Fri, 17 August 2007 17:07

ConstB wrote on Tue, 15 March 2005 15:04 race algo in c++ can be downloaded from http://constb.5u.com Has anybody else looked at this yet ? In essence the habpoints are calculated as follows :-

AFAIK, that particular section of code has been more or less "taken for granted" with other functions getting all the attention. Seems your neat summary is the 1st.

Quote:

Also, for some reason, it multiples the total values for each terra scenario by some random constants (7, 5 and 6) before giving a grand total.

That could be some modifiers for "feasibility" (or even for the overall econ impact) of each terra level. Though it's hard to be sure with the Jeffs.

Quote:

Nor can I see anything that would makes a difference from moving a narrow centered band to the left or right a click or two, not until the edges are hit with +/-15.

Now this is an interesting one. I've always assumed the effect owed to the way planet habs are generated, with centered ones being more abundant than shifted, and thus gathering more habpoints. But perhaps we must look for some other cause?

Quote:

Not sure I've seen anything that explains the difference between shifting left and right yet either. You could put it down to rounding, but as the bands are split into 10 chunks there ought not to be any rounding with widths that are multiples of 10 :-s Am I missing something ?

Well, shift left vs shift right always seemed a minor effect to me, but indeed I would like to know *why* is there any difference, as the probabilities of each side are the same.

Report message to a moderator

Report message to a moderator

Report message to a moderator

[Updated on: Fri, 07 September 2007 05:56]

Report message to a moderator

mazda wrote on Fri, 07 September 2007 11:51

If the v108[] values are sufficiently positive then the RW thinks the test planet is less desirable and hence it costs you less. However these values have a sign - if the planet value is higher (to the right of) than the centre point of the race band then these values are instead negative and so unlikely to produce a reduction in desirability and hence no reduction in RW cost. So the more test planets you have with hab values left of your ideal values then the less points you will pay.

Wouldn't that kind of quirk lead to a large difference in left vs right? I was under the impression that the observed differences were minimal.

Report message to a moderator