Home » Stars! 2.6/7 » The Bar » Stars 3
| | | | | | | | | | | | |
Re: Stars 3 |
Thu, 05 June 2014 04:15 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
LittleEddie wrote on Wed, 04 June 2014 20:37Quote: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.
Cool, that sounds really great. Send me a pm if you need any help in working with the repository, test modules, etc.
Edit: 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 will hopefully have time tonight to tackle the production side.
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.
[Updated on: Thu, 05 June 2014 04:31] Report message to a moderator
|
|
| | |
Re: Stars 3 |
Thu, 05 June 2014 05:50 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Thu, 05 June 2014 10:15We 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
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)
Addendum: Cargo Capacity & Scanner Ranges too.
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.
[Updated on: Thu, 05 June 2014 13:37]
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| |
Re: Stars 3 |
Thu, 05 June 2014 06:34 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
m.a@stars wrote on Thu, 05 June 2014 05:50
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)
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.
m.a@stars wrote on Thu, 05 June 2014 05:50
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.
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.
[Updated on: Thu, 05 June 2014 06:34] Report message to a moderator
|
|
|
Re: Stars 3 |
Thu, 05 June 2014 06:36 |
|
mrvan | | Officer Cadet 1st Year | Messages: 220
Registered: May 2014 | |
|
XAPBob wrote on Thu, 05 June 2014 05:03Code tags need wrapping in colour tags:
[ color=darkblue][ code][ /code][ /color]
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:
{"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]
}]
}
[Updated on: Thu, 05 June 2014 06:37] Report message to a moderator
|
|
|
Re: Stars 3 |
Thu, 05 June 2014 07:07 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
mrvan wrote on Thu, 05 June 2014 12:34I'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.
Well, these would be the 2 main reasons for storing that "calculated" data somewhere convenient:
1) it's akin to "caching" (whenever some number is looked up more often than it needs to be updated)
2) it saves the client from having to calculate it, sacrificing just a few bytes of space. (speaking of which, I forgot "Cargo Capacity")
and 3) it "conveniently" centralizes things, as long as a calculation is done whenever it's easier to do (such as when a Design is 1st validated), but it's used somewhere else.
I agree it's perhaps not necessary to actually save the calculated fields to file, tho.
Quote: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.
So, "unit tests" will need their own data, and larger tests will need theirs, too? Fine by me. Call me when you need a nice map, ship or race designs, or just data in bulk.
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
| | |
Re: Stars 3 |
Thu, 05 June 2014 07:40 |
|
m.a@stars | | Commander | Messages: 2765
Registered: October 2004 Location: Third star to the left | |
|
theval wrote on Thu, 05 June 2014 13:13Have 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?
Yup, I've looked into it more than I should have. I like some things, but not the rest. Excessive hardcoding, rigidity of structures, and others, make it a complex read, and even more complex refactoring/improving/reusing, despite its being written in my favored lingo.
Successful efforts need to be simpler and far more flexible, IMO.
Note: what's up with being unable to edit posts? I want to add "Cargo Capacity" and "Scanner Ranges" to my earlier list.
[Updated on: Thu, 05 June 2014 07:41]
So many Stars, so few Missiles!
In space no one can hear you scheme! Report message to a moderator
|
|
|
Re: Stars 3 |
Thu, 05 June 2014 07:52 |
|
theval | | Petty Officer 3rd Class | Messages: 43
Registered: May 2014 | |
|
mrvan wrote on Thu, 05 June 2014 13:28I 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?
Yes, I'm. I find it quite nice and accessible to unprepared contributor. There are several issues, but they are barely a problem, given that the engine is structurally complete, compiles and works.
mrvan wrote on Thu, 05 June 2014 13:28Could you extract the relevants pieces of code for some of the complicated logic?
No, I'm working a Qt GUI for freestars. I have no time to contribute to your project, though I appreciate your effort and wish you success.
Report message to a moderator
|
|
|
Goto Forum:
Current Time: Mon Apr 29 20:09:03 EDT 2024
|