I agree, but I have doubts about instant acceleration.Shiolle wrote:
If we have a fleet of multiple bubbles of different mass, they must have some way of moving at the same speed to maintain formation. Of course that speed won’t exceed top speed of the heaviest bubble. I think they say that a bubble can achieve any speed up to its top speed instantaneously.
As for formation, either the ships form similar group, hence, similar group mass, or move all in one big bubble.
Our discussions on this concluded that forming a group will save fuel as only one ship has to maintain the bubble.
For small groups the normal bubble is big enough, so no consumption increase and not much for bigger groups.
Extra power obviously comes from the weapons & shield consumption part.
I think for simplicity we should leave this complex calculation out for now. Priority is to get the sim running first.
Agree, I don't like special treatment when it can be done otherwise. Also classification change with time and tech level.
I don’t want to hardcode ship classes (cruisers and assault ships, etc.) into the editor.
I also use mass for load out measurement. That’s why I need to know how large is the ship’s final mass including full cargo hold and fuel bay –
to know how much the ship can carry. Only when the setup is done we know it’s total dry mass.
*nodes* The problem with this kind of things is that parameters are influencing each other and we run into unending loops.
IMHO starting with payload and working up to heavier systems ease things up and lessen difference to needed requirement.
That's alright, but still it should be part of the ship mass. *shrug* This would save construction work in later expansion.
It’s irrelevant because normal propulsion cannot be used in planar space (except inside in bubble movement that are not in yet either) and I don’t intend to model normal space so far.
Basics!
The difference for plane space and normal space is not that much, so I'm not concerned about trouble when trying to expand it.
(+accelleration, max. weapons range, environment)
There is because the ship is still in 3D within the bubble. The problem is the translation from one universe into the other of which we have not been informed.
And there is no inertia there either. I meant it could be used later in normal space (if it’s to be ever implemented).
In any case, having the basics already there and proper naming saves the more trouble some change of the whole structure later.
While the only thing need to do now is have the parameter there.
I meant it as example info. We don't need to simulated building time or cost for now.
I didn’t mean that the ship is modular (as in universal replaceable parts).
If the program works on many external files rather than internal data, which can be edited freely, then it would save lots of tweaking of the program itself.
But phe program must be able to handle long lists eg. subsystem types.
We only need simple definition script to handle how they work or how to handle their parameters.
These can be chooseable from a drop list and depending on script info, the details could be changed. (I know it's not simple.)
So the bulk of the program is going to be graphics, file and some scripting. The actual sim part will be much less in terms of code.
I can help out with progamming except graphic which I haven't done for too long. Just let me know which part.
I only need to install the programming language and do a quick crash course.
That's exactly what I meant. As propulsion mass depends on overall ship mass, it's the heaviest system and the frame will be build around it.
I think I need to elaborate a bit on what I meant by basic structure. Ship “skeleton” (ships frame), all outer hull, all those layers you mentioned.
Also, did you get those numbers from modern rocket science, or are they from some info on sekai universe?
Crew quarters and such are minor. Fuel tanks are also minor although they are biggest in size and carry the most mass, just not as concentrated as propulsion.
Infos are from proton-antiproton engine for insterstellar 'ship' dated 2003.
The only problem in that doc is that the AM propellant formular is not correct. (either intentionally or not) It's too complicated so I do not dare to redo all the steps for a correct version.
You have no idea about automation or maintainance.
Nor do I know what standardized crew is.
(which suggests pretty low level of automation for such a technologically advanced society).
Besides, do you have any information what all those 150 men do on modern destroyers? What are their duties?
example: for any helicopter for each flight hour it needs 30+ hours of maintenance;
for any fighter for each flight hour it needs 20-30 hours of maintenance;
Assualt: Roil class: 5+2 command, 12 engineering, 3 administrative
Attack: Caubh class: 7+1 command, 17? (<20) hint somewhere in SNS4, probably says somewhere in SNS3
cruiser: Gothlauth class: 8+5 command, 110 enlisted
Cow class: (400)
I can get the info...for now, the one thing most people forget is that ships operate in shifts which means you need 3x required normal duty crew.
Yes, it think it's some squareroot formula with low fractional exponent (m^x; x<0.5).
Just another basic stub parameter.
Do you propose to presume that a ship has to be able to achieve 25g acceleration and knowing its mass calculate F?
Acceleration or thrust are tied to mass, so whichever you chose is the same, but in order to know value in one aspect or the other you can't go around making the conversion.
It's just nice to see it, though.
How it's done internally isn't important for the user, but it could save later tweaking of core program code, since it's a simple calc.*shrug*
See above. Yes, when the output increases or because all generator output are contributing. Imagine a field generated by many so they strengthen as a total.
But when ships converge bubbles, their bubble got bigger, right?
Or maybe what bubbles converge do bubble generators on all ships contribute to bubble’s size?
But for ease we should ignore the complicated calculation for group bubble for now.
We should model grouping careful since many expansion will happen here.
I think they said to conserve they stopped and did the repairs and cut the life support down. In any case it must stay operated in plane space.
I think that in BotS 1 they said that bubble generator consumes the same amount of fuel regardless of movement speed.
It won't hurt to have this parameter. Lets just play around with the parameter and see how it turns out.
Right, that's why I want to get rid of any forced limitations. When designing it will be apparent that it's not worth it to have shield on small vessels as the strength is not enough to do anything.
But I want to allow great flexibility in customizing shields.
As mass and size of the ship increase, minimum mass of shielding system to be able to cover ship’s surface increases too. Minimum shield strength for a given mass reflects that.
There is no point in setting shield capacitor to not be able to absorb at least as much as shield strength allows.
That is the case with every other system: mass is always calculated, never directly changed.
Since mass and capacity are tied it doesn't matter which one is changed.
I would say we have a display telling the minimum strength number as info. [And maybe even a checker to automatically apply it, if generous.]
If the user wants to have it or not is his choice. This way civil ships can be created without shields as well as the shuttles. (it may give a nice escort scenario.)
Well, sooner or later you might see the need to change either. But it's fine by me.
(We just need two procedures for this, when one is changed etc. , just have to make sure an update is run each time.)
No. This is just another formal formula, wether it is needed later or not, dunno.
Do you think I need to calculate that loss separately if I can just lower kfps to reflect that?
But it sure gives a nice overview when having the info.
I just took over your list.
You say that, but later you contradict yourself:
I think maybe it’s practical to divide weapons not into anti-ship and point defense for the purpose of offlining but into high and low power use.
I think we have to consider power usage anyway to determine system shut down, so this would be a good way to tied it up without extra programming.
IMHO in battle you really don't want to shut down weapons and rather sacrify other systems even shields if you see a chance.
But this requires intelligence we cannot afford for now.
A solution would be to have checker choices for 'normal' or 'prioritise weapons' or 'prioritise defense' or 'deathwish' or 'kamikaze'
normal refers to what we do depending on power usage
prioritise weapons means we keep all weapons on as long as possible.
prioritise defense means we keep point defense and shields as long as possible.
deathwish would mean all energy on weapons, no shields.
kamikaze means ramming the enemy ship (an option Lexhue was considering when her ship was nearly disabled) This would require some special damage calculation. cue: impulse crash
*shrug* Just another random thought.
Agree, so just another formality.
I think that to allow a fast weapons to calculate a chance to shoot down a mine in each shot is too inefficient performance-wise.
least two time per second that lone will produce massive load on processor. (Random thoughts)
For now we consider group performance only for actual calculation. But this still bases of single weapons performance.
Only bad programming would need that much time. (I assure you it's possible to calc all primes up to 2 billion with just 2 million cycles on an old PC)
At least we should take a roll for each weapons type for each ship.
Actually, in the real world the military uses tables to calculate firing parameters. Maybe we can do this, too.
But I doubt it's faster. Also this means internal data which is bad. *shrug* Just another random thought.
We should avoid AI if possible, but if needed it should be separated in it's own module (tree).
I think I’ll have to implement priority targeting for AI.
Antiproton cannons will prioritize larger ships, but when none around will also shoot mines, laser cannons will do the opposite.
I don't really want to complicate this, but I think prioritizing target is best.
Antiproton cannons should priortize ships when they are within the bubble or within range. Except mines weapon fire don't work outside of it.
No sense to keep a weapon hot when you can't use it.
We might need precalculation for position so we don't waste a shot when a ship is going to be there the next second and the cannon would need to recharge by then.
I think the smart way is just calculate a safety range in addition to firing range.
Yes, but it makes a difference in the program code. If weapons type modifiers are used you can change them for all of the same type.
I think that from the math point of view it is no different than assigning two different values to them.
Also consider this: Shp represents the penetration potential of the weapon.
Since I don’t factor armor, the only defense need “piercing” is the shield.
Strp on the other hand represents the spread of damage, like that of a large explosion.
You can easier compare their performance by their basic damage. And you can have different weapons type without writing everything new. Just rename weapons type in its parameter.
On the other side, if you do it everytime for each weapon you will loose oversight and it will be a mess in the long run.
Still, the weapon energy has to be reduced, if you have separate values, you will deduce from Shp part, and have some left over or deficit while
you have hull damage whit extra Shp or deficit left. It's just not realistic. In reality you have energy which can translate from one form to the other.
The basic damage value is just pure energy which translate via the modifiers into the different damge form.
We should leave explosion out for now, since it's really too complicated, or we will end up with something unsatisfying.
You said we needed different calculation since it seem different weapons work differently on different ship classes.
What do you mean? There are no ship classes (cruisers, assaults, etc.) defined as objects.
never mind
Yes. Remeber them releasing water to cool the amor, and remember the pipes when they take out the armor for repairs?
Do ships of sekai universe really have that?
I think that means that every time the hull is penetrated there should be a cloud of quickly crystallizing steam near the breach, but all I see is smoke and fire.
No crystalization because weapons effect will vaporize them. Also it's too much work to animate this all the time.
You may not realize it but anime tech is always well thought out since the last 25+ years.
Also water is the propellant and cooling fluid. Modern starships will have to use it for hard radiation protection. It's just ideal for all these jobs, but it's a damn hazardous fluid.
You bet. *whahaha*
Did you play SFB or Starfleet Command games?
However that system is immensely complex.
Especially the part where you randomly select damaged systems based on their mass.
He will just notice the increasing number of damaged and destroyed ships in each bubble/group/fleet.
I know. Keep the formal design but we can make it faster by simplyfying calculations.
We just 'precalculate' after a ship design has been done. (need to think this more in detail)
We can add the first 3 layer defenses together as one. If their total defense is not penetrated then no need for subsystem calculation.
We use one simple loop with zero check (we just add defense value as damage and subtract until zero from dmgpen, no complex calc needed.)
We will use our power usage list, the biggest is obviously the easiest to hit. (The algorithm is pretty much similar for shut down.)
We do a sum again devided by the smallest system so that each system is a multiple of the smallest system.
We take a roll based on the sum and just look up the number in the list. (need to decide how to count, though)
Simply add damage etc.
Repeat for core system.
This will require about 100 cycles at most.
Yes, but the advantage of all this is you can have an extensive log to look into the battle details.
This is where the system will slow down because of the I/O operations going on.
If you have ever seen such a log...I will post some insights later when I put them all together for you.
Penetration is based on the 'armor' defense value which is independent from the hitpoint value.
What about that piercing beam I mentioned earlier? It doesn’t destroy 50% of hull, but it does damage internal systems.
See, armor defense value represent thickness and hitpoint represent the surface.
If hitpoint is zero it means that there is no layer on the surface anymore.
At 50% half the surface lays bare, so you could have a chance not to hit any layer part or not.
We check if a weapon penetrates the armor thickness, but this does damage to the surface, hence we add the defense value as damage.
So this is not like most games where the armor has to be gone in order to do internals.
You can do damage if you got the weapon or you will take a very long time to wear the armor down until you can peenetrate it.
OK, I think I get your idea.
Hit is generated only once for each shot. The same number will then be used both in miss and damage calculation.
To be clear does this mean the ship will receive full damage or is damage part of the function curve as in your mine receiving damage?
Have you read my edits (at the end) from last post?
Edit:
Limited sharing Docs you asked for.
Edit:
Change of plans to drafting up crew size.
We use mass squareroot formula for engineering regarding propulsion. Same with command crew which will be expanded depending on size of crew. (to be fixed later)
Now, for each system type we add a certain number of crew depending on system type.
For example computer and sensor we only need one per shift. For big weapons like the EM or proton cannon we need two.
Now we need to add one supervisor for each system type. Half of these will be officers.
Shuttles will be special. (I wonder if summing all fractions will give some interesting crew) size.
Last edited by Almael on 9/27/2009, 9:04 am; edited 1 time in total