Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Metalax]

Generally speaking, more is better. However there is also no pressing need for all of the modules of a type to be located on a single ship. It is perfectly reasonable to send a ship/platform with only a few modules and have the capability of the colony build up as more ships/platforms arrive. The only real exception to this is for maintenance modules where you need to have sufficient present for their effect to reach the size of the ship they are intended to maintain. Even then, they don't all need to be on a single ship/platform.

I'm not sure where you are getting the idea there is a hard cap, or any sort of cap, on the number of Sorium harvesters? The only constraint is how big do you want to allow the harvester ship/platform to be. Even if you do have only a certain number of harvester modules on a ship, there is absolutely no issue with simply having multiple harvester ships operating at the same location. Anyway you can't set up a population or facilities at a gas giant.

[Dramegno]

on the end of everything thread that has been linked her a couple times here lately one of the things listed is a cap on sorium harvesters which is a little over 15330 modules according to the thread. The style that I am wanting to try in this game is why be reasonable when being unreasonable lets you build needlessly complicated mega-ships/platforms. 

[Metalax]

on the end of everything thread that has been linked her a couple times here lately one of the things listed is a cap on sorium harvesters which is a little over 15330 modules according to the thread. The style that I am wanting to try in this game is why be reasonable when being unreasonable lets you build needlessly complicated mega-ships/platforms.

Ah, if you are deliberately going to be building near to any of the game engine limitations, you really should say that clearly when asking for advice, as without that people will assume normal levels of gameplay.

IIRC that one is due to hitting the cap on fuel production, which is separate for each ship so you can easily get around it by having multiple ships. Do note that trying to dump all that fuel at a colony may cause overflow errors of it's own.

[Dramegno]

I will be doing that then. Speaking of overflow errors it seams that their is a time limit outside of slowdown for the game which is somewhere in the early 4000's year wise. I found this by putting labs at 5% construction and have a bunch of them qued up

[Greenbane]

So I asked Steve on the official forums about the benefits of migrating Aurora to C#, something he's started doing.

Here's his reply:

Performance is main advantage, although there are a few others. I've just ordered a new PC with Windows 10 (currently on 7) so time is catching up with VB6 . Developing past the current functionality will be a lot easier in a modern language. Performance should be enhanced because everything is being loaded at start-up and the game is run entirely in RAM. So far I am loading all system bodies, survey results, ships, fleets, classes, missiles, etc into objects in less than 10 seconds. My game has 500 systems, 60,000 system bodies, 100,000 system body survey records, 2300 ships, etc. so most games will be a faster load.

Simply swapping systems in the tactical map is noticeably improved. Changing to the Alpha Centauri system in VB6 has a delay of perhaps 1-2 seconds. In C# it is instant. If you select the system dropdown and hold the down arrow, it looks like the end of Wargames

Because windows forms has advanced a lot since VB6, the window design is a lot cleaner and I can start from scratch in terms of deciding where to put everything, rather than squeezing more and more things into an existing layout.

Database-wise I am currently using Access so I can run the same database in both C# and VB6 to compare results. However, I have set the data access code up to allow me to easily change DBs so I will move away from Access once the program is close to completion. Probably SQL Server as I am very familiar with it. I've been considering how to handle the saving side and I am leaning toward creating complete game save files rather than updating a single file, so you will have multiple save positions in the same game.

Another advantage of C# is that it allows multi-threading, which may help with sensor updates as I can run several systems simultaneously. I won't use multi-threading just for the sake of it because I understand you can get yourself into trouble fairly easily but I'll play around with it and see if it makes a significant difference.

BTW For those familiar with C#, I have found one of the major advantages over VB6 (beyond the obvious advantages) is using LINQ and Lambda expressions to retrieve data from collections - very useful and powerful.

Excellent stuff!

[RadtheCad]

Sounds great!  Can't wait to play it.  Funny, Pulsar's been around for tears now and Steve seemingly catches up, just like that... 

[Willfor]

Sounds great!  Can't wait to play it.  Funny, Pulsar's been around for tears now and Steve seemingly catches up, just like that... 

100% not surprised at all by that development, to be honest, haha. It's a passion project, and he's got his entire codebase to pull from for structuring the code.

[Greenbane]

Well, it is a few years overdue, but I'm glad it's finally happening.

[Dozebôm Lolumzalìs]

What speed can I expect enemy ships to be going at

Why do my plasma carronades say "range 0km" in the ship but "range 160 000 km" in the tech report?

[Lord Shonus]

What speed can I expect enemy ships to be going at

Why do my plasma carronades say "range 0km" in the ship but "range 160 000 km" in the tech report?

The first part is impossible to answer, as it depends heavily on tech level. The best thing you can do is set a solid baseline (for example, ships should be 1/3 engine with 10% power boost over average) for you own ships, and plan to fight them. Since missiles are much easier to upgrade (by reducing range or warhead for more engine) if necessary, you'll do OK if you do so.

In the second case, you either forgot a reactor or a beam fire control.

[Dozebôm Lolumzalìs]

What should I aim for in terms of speed for beam fire control? Anti ship, not anti missile.

Unturreted beams have a tracking speed of either the ship speed or something else. What is that thing?

[Lord Shonus]

Unturreted beams have a tracking speed of either the ship speed or something else. What is that thing?

Unturretted beams have a tracking speed of the ship speed or the fire control speed, whichever is lower. As using beam fire controls that are too slow to hit the ship they're mounted on is an expensive form of suicide, the speed of your ship should be considered a hard minimum.

[Dozebôm Lolumzalìs]

Nonono, there's another thing. I'd check the wiki, but it's down.

Basically, whichever is higher of [ship speed] and [this thing] is the weapon speed. Whichever is lower of [weapon speed] and [fire control speed] is the effective speed of the attacks.

[Flying Dice]

You might be confusing the distinction between turreted and hull-mounted weapons with a more complex determination of the latter's tracking speed. The former's tracking speed is the lower of the turret traverse speed or the FC tracking speed, the latter's is the lower of the ship's speed or the FC tracking speed. As far as I'm aware there's no factor affecting hull-mounted weapon tracking speed other than ship speed or FC tracking speed.

[Dozebôm Lolumzalìs]

I don't have any intuitive sense for speeds and distances.

How far should I be aiming for when I design:

Missiles?

Beams?

How fast should I be aiming for when I design:

Ships?

Beams (attacking)?

Missiles (both attacking and of missile itself)?