Shrugger! Unity!

[keith.lamothe]

Of course, if the crew has no-one tasked with doing these calculations, then the maximum thrust won't be updates in the ship's internal information system and the navigator will be having trouble.

Can this happen because the accountant was away from his post trying to get to the beer hall, but blocked by a horde of kittens?

[Shrugging Khan]

Not yet, because none of those elements (except for the accountant and a non-functional beer hall) are implemented at present.

But if all goes according to plan, then it will be entirely possible for the accountant (crewmember tasked with with Analytics, Bureaucracy and Domestic Management)  to be on his way to the beer hall (Container module with habitation modification and beer-type resources), only to notice that the module he tried to pass through on the way had its entire internal space taken up by kittens (cargo / fuel / compressed oxygen / an enemy boarding party / passengers / alcoholics / actual kittens).

Since nobody else on board was trained in ANA, BUERO and DOM abilities, no interim accountant could be appointed by the Command section, and the ship would fly on outdated navigation data. THAT part is actually implemented already.
What's missing there is the ability of the crewmembers to try and make the calculations anyways, with all the possible mistakes that entails.

It's supposed to be that kind of game.


Edit: Just in case you think I'm joking - I'm not. Kittens are actually a viable resource (or would they count as crewmembers? That I don't know.)  for keeping up troop morale. Of course, some soldiers might object to having innocent noncombatants on a vessel of war, but that's a different factor.

[keith.lamothe]

I hope the general modes of ship destruction leave largely-intact pieces instead of just vaporizing.  That way we can see the Accountant's engravings of the kittens.  And the Navigator's engravings of the Accountant.

[Shrugging Khan]

Unless you're *really* saving money (or trying to churn out ships as quickly as possible), the standard setting for ship component construction is for them to have re-sealing equipment on board in case the adjacent component gets blown off by incoming fire, a collision or a separator charge. So it's perfectly possible to cut a ship in two (or twenty), with the surviving crew still going about their business in accordance with their orders...or, perhaps in the absence of relevant orders, with the crew trying to keep up morale by documenting their fleet's struggle with the enemy, the long journeys, and their accounting department.

Actions without orders aren't implemented yet, though.

Edit: Given that I'm already running into performance issues, I'm suspecting that this game might turn out quite a bit like DF in the long run - death by low FPS.

[Draco18s]

Edit: Given that I'm already running into performance issues, I'm suspecting that this game might turn out quite a bit like DF in the long run - death by low FPS.

#Configuraions
MaxCrewSize:3
MaxFleetSize:5
MaxShipComplexity(Modules):10
MaxSolarSystems:4
MaxPlanetsPerSystem:3

NANOEMBARK, HERE I COME!

[Shrugging Khan]

Ship construction, component variations, prettier visuals, thrusters-you-can-switch-off (I failed to notice that the AI was unable to throttle down), smoother rotations, brake-to-rendezvous and a single class to handle all things related to the camera and the GUI...done!
Well, functional, at least. Still needs lots of work - but it works!

Now I'm looking at refining the rotate-to-aim code again, because they're still doing some spinning around the Z axis, and I finally understood why - because they just compare their angular velocity's magnitude to the angle-yet-to-traverse, the AI has no way of noticing when it's going in circles around the direction it's meant to point at. I'm bad at explaining this, so let me illustrate it with an example:

• Ship has angular velocity to the right, and its nose is currently pointing above the target
• Ship accelerates its rotation downwards to meet the target
• Shorty after, the ship has downward angular velocity, while pointing to the right of the target

Unless the angular velocity is so large that it triggers the AI's "fukc directions, we're spinning too fast, just de-rotate!" safety, they will continue to rotate *around* the right direction.

Now, I realise this is probably not exactly anyone's speciality (it certainly isn't mine), but can anyone explain to me how to check whether a Vector of rotation is, roughly speaking, going "the right way"?

I've done some testing, but so far I wasn't able to get a good grasp of it. So thanks if anyone can help a little 

[Draco18s]

They're doing a barrel roll.

[keith.lamothe]

I would suggest computing your desired rotation in two parts: left-right, and up-down.  So you'd be applying two different thrusts (if you were off on both) : one on the left-right until you hit turnover, at which point you'd decelerate to angular rest _on that plane_ ; and then another on the up-down until you hit _that_ turnover, and then you'd decelerate to rest on that plane.

Both could run simultaneously, and one may or may not hit turnover or at-rest before the other.

But if I'm thinking of this right the two should work if you treat them as orthogonal (non-interacting) to each other.  I don't think it would necessarily be ideal because it's probably like traversing the height and base of a right triangle instead of traversing its hypotenuse, but one thing at a time

[Shrugging Khan]

Well...this is weird. I finally upgraded from a single AI method to a full AI class, and now the rotations work again without the rotation code having changed at all. Huh.

That said, some of my classes have recently broken the 1,000 line mark. Hooray!
And my editor has broken its code folding feature. Pain!

Also, turrets are in. And different weapon types (LAZORS!). And more randomisation in the ship constructions. And my brother wrote a name generator, so the sailors now have names. I suspect he did it just so I'd feel bad about getting them killed. I also tossed out a batch of obsolete classes and tidied up a lot of old code.

It almost appears as if I were programming faster and with more concentration the more I should actually focus on my coming exams. Silly idea, isn't it?

Well, getting back to those growing classes...at how many lines would you say a class is too big? When does it, in your eyes, become too unwieldy? Or is it actually the opposite and you'd rather have huge but fewer classes than a large number of smaller ones?

[keith.lamothe]

Well...this is weird. I finally upgraded from a single AI method to a full AI class, and now the rotations work again without the rotation code having changed at all. Huh.

It was just holding out for a promotion.

Well, getting back to those growing classes...at how many lines would you say a class is too big?

I'd have to recuse myself on that one.  I think one of AIW's _methods_ has over 10,000 lines.  The thing that sets up all the ship stats (giant switch statement).

Though that's uncommonly huge for us.

But main classes getting over 5000 lines isn't uncommon for us.

Most of the classes are pretty small, though, and we tend to have a fairly large number of files from all the splitting up.

Generally I don't navigate the code files by scrolling, but rather by doing a text-find and something like "DoShipStep" to jump to the method where each of Fed's ships does its in-combat logic, etc.

So it's more of a "random access pattern"

Though with the many files that follow the enum/typedata/instance pattern I do often rely on the fact that the enum values are all at the top.

[Shrugging Khan]

Alright. Ships, Components, Cultures, Fleets, and Factories are all procedurally generated. Rotation works. Propulsion works. Weapons work. Turrets work. The AI knows what it's doing. There's battles, and although they're very very short due to the absence of cover, armour or anything else resembling defence, they do happen and play out roughly as they should.

I guess that's a minor milestone!

Thanks for all the support. Considering that half a year ago I couldn't program at all, you two really helped me 

[keith.lamothe]

Congratulations for coming so far in half a year

Programming is learned by slamming your head into a brick wall over and over again until the wall falls down.

[Aklyon]

Congratulations for coming so far in half a year

Programming is learned by slamming your head into a brick wall over and over again until the wall falls down.

But what if the wall falls down intact?

[keith.lamothe]

Congratulations for coming so far in half a year

Programming is learned by slamming your head into a brick wall over and over again until the wall falls down.

But what if the wall falls down intact?

That's the idea, actually.  You just walk over it.

Programming is also about knowing when to make a minimum of assumptions, and when to make as many as you possibly can

[Draco18s]

The AI knows what it's doing.

Oh sh*t