This matches the storage of the pgr in terms of talking about percentage values as integers rather than fractions (this decision wants cementing asap, and we need to decide that all percentages will be defined in one sense or the other)

XAPBob wrote on Tue, 03 June 2014 10:29

do we want to encode the additional flexibility that the original code has (but never exposed) of having an "off centre" perfect (so you get a short tail on one side and a long tail on the other?) I think it's probably easier to add it in later if needed.

I'd like it, as long as it doesn't take too much time to do. Alas, we don't have real-world test-cases for it.

To what type of real-world test-cases do you refer? Do you want examples of organisms which show this type of habitat preference, or do you refer to it not having been implemented in previous builds?

I wanted to, but I have no clue how to convert the printed values to 'clicks'... The planet report also doesn't seem to report hab values, or am I misreading it?

Ok, it will be a while before I can do any coding, but I would like to help and it looks like you all can handle most of the coding as it is.

So I will do some thinking and post on Doc's list.

Your "mixed-engine" fuel calcs will be a neat addition.

Quote:

Your "mixed-engine" fuel calcs will be a neat addition.

That would be for the server side where we have to est. the fuel usage over multi-turns. So we should include the IS/AR changes and account for the fuel being made during the trip by engines and fuel x-ports. That would give us a better est. of fuel usage.

This is a bigger project then I've done in the past, from 1983 to 96 I did custom "Point of Sale" software (the main money maker) in C++ but I did about everything myself and after a while it was mostly boiler plate stuff. Then I retired and when to the Caribbean and had too much Run and Beer.

Anyway, I'm busy right now but I'm working on writing the test for the movement code and then the code itself.

Quote:

Your "mixed-engine" fuel calcs will be a neat addition.

That would be for the server side where we have to est. the fuel usage over multi-turns. So we should include the IS/AR changes and account for the fuel being made during the trip by engines and fuel x-ports. That would give us a better est. of fuel usage.

This is a bigger project then I've done in the past, from 1983 to 96 I did custom "Point of Sale" software (the main money maker) in C++ but I did about everything myself and after a while it was mostly boiler plate stuff. Then I retired and when to the Caribbean and had too much Run and Beer.

Anyway, I'm busy right now but I'm working on writing the test for the movement code and then the code itself.

We do need to start fleshing out how to represent fleet, ships, and designs. I guess "ships" as such don't need a representation, i.e. a fleet can point directly to a design?

Would something like this be best:

Edit2: Why don't the code tags work on this forum? Proposal for representation at https://gist.github.com/vanatteveldt/11d69410ed49bd8ca06c

I also thought it would be good to have at least one 'integration test' with a universe definition with all fields that we are using and testing the whole process_turn chain, so we can see if there are any inconsistensies in how the universe files are used and so we have to maintain at least one example of a fully fleshed univserse+turn definition.

This is a bigger project then I've done in the past

Ship designs also carry "calculated" info, such as Mass, Cost (original and/or current/miniaturized), Armor, Shielding, MaxFuel, Rating, Number Built, Number surviving, Cloaking/Jamming, Init/Moves, which could be conveniently stored right with the "static" design info and recalculated when needed (such as getting tech, during prod, after battles)

Quote:

I also thought it would be good to have at least one 'integration test' with a universe definition with all fields that we are using and testing the whole process_turn chain, so we can see if there are any inconsistensies in how the universe files are used and so we have to maintain at least one example of a fully fleshed univserse+turn definition.

Neat. Do we have a list of all the fields yet? I can fill them with "random" data as needed.

Code tags need wrapping in colour tags:

[ color=darkblue][ code][ /code][ /color]

{"players" : [{"id": 1,
              <race info etc>,
              "ship_designs": [
                 {"id": 1,
                  "name": "Cargo Mover",
                  "hull": "medium freighter",
                  "engine": "fuel mizer",
                  "components": [{"slot": 1, "type": "super cargo pod", "quantity": 1}]
                   }
                ]
              }],
"fleets" : [{"id": 1
              "owner": 1,  
              "tokens": [{"design": 1, "quantity": 20, "damage": 12},
                         {"design": 2, "quantity": 5}],
              "fuel": 2800,
              "cargo": [0, 0, 100, 12]
            }]
}

I'm not sure I agree here. In the universe representation I think only actual information should be stored, not calculated fields. The engine can 'cache' all this info if that is good for performance, and if needed for the client we can make a 'calculated fields' API calln to avoid reimplementing things in javascript, but I think we should really restrict the API definitions (of which the universe representation is the most important) to actual unique data.

What I think we should do is simply fill it as we develop. What I envision is this: whenever someone writes or updates a module, always also write/update the *unit* tests (which is a minimal test of all different corner cases, exceptions, etc, of that particular module), and update the *integration test*, which should cover all representation issues (ie use all fields, with multiple instances if needed for e.g. immunities vs hab ranges) and which is meant to ensure consistency between modules.

Cool. I had tried the other way around (color within code) but that (obviously) didn't work. I can't edit the post anymore it seems though, so I'll just copy below:

Proposed representation for ship designs and fleets:

Have you looked into freestars code? It implements all this logic pretty much along with a big chunk of the logic of the rest of the game.

I'm curious why don't you want to reuse it?

I don't have anything against reusing it, but I feel that in most cases the difficulty is not so much in implementing the logic, as in writing the tests, ensuring correctness, etc.

Are you familiar with the freestars codebase?

Could you extract the relevants pieces of code for some of the complicated logic?