Author Topic: Aurora C# Screenshots  (Read 145635 times)

0 Members and 2 Guests are viewing this topic.

Offline Tchey

  • Leading Rate
  • *
  • T
  • Posts: 11
  • Thanked: 4 times
Re: Aurora C# Screenshots
« Reply #270 on: July 28, 2016, 06:25:24 AM »
Hello,

I didn't come around here for a long time.  I played it on Windows when i was dualbooting, but now for almost 2 years i think, i'm using only Linux.

Will it work with Linux with the re-coded version ?
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Aurora C# Screenshots
« Reply #271 on: July 28, 2016, 07:24:26 AM »
Will it work with Linux with the re-coded version ?

The issue is that you'll need to have a Linux .NET environment, which I think is Mono.  I haven't paid close attention to this, but looking at the Wikipedia page for Mono, it looks like it currently only goes up to .NET 4.0.  Since Steve is probably on VS 2015 (which is at 4.6.1), there's a good chance that the Mono level won't be high enough.  In addition, everyone I've ever talked to (admittedly not many) who's tried to run .NET apps on a flavor of unix has said the port isn't that robust.

So I'd be skeptical about it working on Linux.  First, the .NET version Steve is using probably isn't supported.  Second, I suspect the Linux libraries are going to be buggy.

John
 

Offline Inglonias

  • Lieutenant
  • *******
  • I
  • Posts: 170
  • Thanked: 69 times
Re: Aurora C# Screenshots
« Reply #272 on: July 28, 2016, 08:07:39 AM »
Quote from: Kytuzian link=topic=8438. msg95078#msg95078 date=1469583099
If this was going to happen, every single completion date would have to be an estimate, as a million things can change the production rate of anything (minerals missing, improved construction rates, new governor, et cetera).

I don't see the issue.  That's how completion dates are calculated right now

Having a completion date, even as an estimate, for an entire production or research queue would be quite handy.
 

Offline Kytuzian

  • Sub-Lieutenant
  • ******
  • K
  • Posts: 132
  • Thanked: 9 times
Re: Aurora C# Screenshots
« Reply #273 on: July 28, 2016, 11:49:27 AM »
I don't see the issue.  That's how completion dates are calculated right now

Having a completion date, even as an estimate, for an entire production or research queue would be quite handy.

I'm not saying it's a problem to do it, I'm saying it's a waste of time to label it as an estimate, because all the completion dates are estimates.
 

Offline JOKER

  • Chief Petty Officer
  • ***
  • J
  • Posts: 49
  • Thanked: 3 times
reply
« Reply #274 on: August 01, 2016, 11:42:55 PM »
There's some ideas about improving battle performance, reducing micro-managing and making NPR more challenging.

What's the problem?

1.NPR don't know how to make "effective" missile design. Their missile tend to have fast fire rate (which means no alpha strike) and very long range (which means slow speed). So their ASM can't penetrate our defence, their AAM are only good at anti-ship work. And sometimes player will make beehive-like missile ship and launch thousands of missile, that do cause performance problem.

2.Beam weapon is crap. Their short range and uselessness against atmosphere made them almost completely useless, unless you both run out of missile.

3.Too much micro-managing in design, build and battle. It's annoying to arrange hundreds of missile launchers and magazines on big ships. It's even worse when you have to calculate how many components you should build in factory. It's terrible to arrange target in battle when you want to see the firework.

What's my solution? My idea is somehow WWII-like.

1. Make missile bigger and force NPR to use alpha strike. Think about WWII torpedo, a typical DD carries 4-8 launch tubes that can launch only once or twice (need half an hour to reload), a torpedo bomber carries one, and one torpedo is enough to sink CL or break DD into half. To make fewer and bigger missile effective, we have to remake point-defence mechanic, but I have no idea how.

2. I may prefer Legend of the Galactic Heroes style battle. Beam weapon could have much longer range (100-200m), lock on and fire at a battlegroup rather than a single ship , like what happens when you shoot bird flock with shotgun. Steve could introduce random distribution to decide which ship is hit. However, to avoid kiting with long range weapon, beam weapon range should not differ too much, and huge cannon need a long charge time. New tech could improve damage distribution or atmosphere penetration.

With random distribution of hit, shield will be very valuable, as we can't simply focusing all firepower on one ship to overcome it. But to avoid impenetratable shield, shield may not recharge in battle, or only recharge when turned off.

I thought Steve once said some problem in simulating beam more than 5-second. I can accept missile mechanic.

3. If Steve can't improve weapon system now, please at least do this. We do need a "weapon array" mechanic to pack fire control, launcher and magazine as one, and to pack all ship components as one. One weapon array will be like "1 missile fire control, 50 missile launchers, 5 missiles for each launcher" or "1 beam fire control, 6 laser cannon, 2 reactor". It will greatly benefit designers. Component package would have similar effect.
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2791
  • Thanked: 1053 times
Re: Aurora C# Screenshots
« Reply #275 on: August 08, 2016, 03:07:34 PM »
Quote
2.Beam weapon is crap. Their short range and uselessness against atmosphere made them almost completely useless, unless you both run out of missile.
Disagreed there. The choice between missile and beam should not be made on purely tactical grounds, and it's a question that has plagued the designers of both real life aircraft and ships. For example, USAF fielded the F-102 Delta Dagger which had only missile armament. During Vietnam war, it was discovered that air-to-air combat still required an element of dog fighting and USAF pilots found to their horror that they often encountered situations where they would have need a gun. Similarly, almost all military ships include some sort of cannon or gun onboard, regardless of the reality of airplanes and missiles dominating naval combat for decades now.

So the choice is not only of tactical matters, but also of strategic and logistical ones. For missiles, you need supply ships and ordnance factories producing said missiles. For beams combatants, their logistic tail is much smaller - and regardless of the tactical situation, they will never run out of ammunition.

Quote
3.Too much micro-managing in design, build and battle. It's annoying to arrange hundreds of missile launchers and magazines on big ships. It's even worse when you have to calculate how many components you should build in factory. It's terrible to arrange target in battle when you want to see the firework.
You do not need to build any components in factories. If you want to maximize your output, you don't get to complain that there is too much micro-management involved. The shipyards will happily built your ships from scratch - if you want to speed up that process, then calculate the components required. If you don't want to calculate such things, then let the SYs do their job and accept the longer build times.

As for battle, you only need to assign missiles, weapons and fire controls once - they will remain as they were set up forever. Unless battle damage or the player changes them. There are buttons to copy assignments across a TG or even your entire race.

 

Offline JOKER

  • Chief Petty Officer
  • ***
  • J
  • Posts: 49
  • Thanked: 3 times
Re: Aurora C# Screenshots
« Reply #276 on: August 09, 2016, 09:59:06 AM »
As for battle, you only need to assign missiles, weapons and fire controls once - they will remain as they were set up forever. Unless battle damage or the player changes them. There are buttons to copy assignments across a TG or even your entire race.

I mean assign target. Imagine that you both have 100 ships in battle and then imagine how many fire controls you must control. For my typical design (100 launchers on ship, 4 mfc), there will be 400, and I can't simply use auto target as some mfcs would not be assigned correctly.

If you like micromanaging that much, it's personal. I don't.
 

Offline TCD

  • Lt. Commander
  • ********
  • T
  • Posts: 229
  • Thanked: 16 times
Re: Aurora C# Screenshots
« Reply #277 on: August 09, 2016, 10:13:17 AM »
So the choice is not only of tactical matters, but also of strategic and logistical ones. For missiles, you need supply ships and ordnance factories producing said missiles. For beams combatants, their logistic tail is much smaller - and regardless of the tactical situation, they will never run out of ammunition.
While that is true, it does pose a major problem for NPR competitiveness as the AI is currently designed. Perhaps we can come up with a few tactics the AI could be programmed with to improve its "logistics war"? Achievable strategies that I can think of would include:
- sending obsolete warships ahead of the main fleet to use up missiles.
- damage sinks to be included with AI fleets, but might be tricky to get the AI to build the right balance of sinks to actual war ships?
- more use of raiders targeting resupply ships. Perhaps the AI could create stealthy ships to move behind enemy lines that only attack individual ships without active sensors? Again may be difficult to stop the aI wasting resources throwing ships against traveling warships or jump pickets.
- aggressive targeting of fuel harvesters wherever possible. It should at least be easy to guess where fuel harvesters are likely to be, but again problem is getting raiders past jump gate pickets.
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: Aurora C# Screenshots
« Reply #278 on: August 09, 2016, 12:55:48 PM »
I mean assign target. Imagine that you both have 100 ships in battle and then imagine how many fire controls you must control. For my typical design (100 launchers on ship, 4 mfc), there will be 400, and I can't simply use auto target as some mfcs would not be assigned correctly.

If you like micromanaging that much, it's personal. I don't.
Splitting the fleet up into TGs can help a lot with that.  Set up one ship of each class in each TG as the 'master', and manually set the FCs on it, then copy them over to the other ships in the TG. 
This is Excel-in-Space, not Wing Commander - Rastaman
 

Offline waresky

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1486
  • Thanked: 8 times
  • Alpine Mountaineer..ohh Yeah!
Re: Aurora C# Screenshots
« Reply #279 on: August 10, 2016, 02:08:10 PM »
No specific time-frame - will depend on my level of enthusiasm but I hope months, not years.

Wb Steve!!!!

am really happy and hungry for news!

C-Aurora its like as "fresh beer cup"...:d am waitin for "C+JustDownload"..:D
 ;D
 

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11669
  • Thanked: 20441 times
Re: Aurora C# Screenshots
« Reply #280 on: August 10, 2016, 03:23:59 PM »
No screenshots but a short update.

Research progress in the construction phase is done, as is auto-sharing of tech due to treaties, trade, etc..

Orbital Movement is virtually done. I ran a timed test for my current game, moving all system bodies, including moons, asteroids, etc (60,000 objects in 500 systems), plus moving all associated fleets, contacts, etc in orbit. It took slightly less than 0.1 seconds :)
 
The following users thanked this post: Manekaalecto, Demonides, Tanj, QuakeIV, snapto

Offline chrislocke2000

  • Captain
  • **********
  • c
  • Posts: 544
  • Thanked: 39 times
Re: Aurora C# Screenshots
« Reply #281 on: August 11, 2016, 04:43:23 AM »
Steve

That sounds very promising on performance. Any sense on how long the same process was taking under vb6?
 
The following users thanked this post: waresky

Offline Frick

  • Chief Petty Officer
  • ***
  • F
  • Posts: 43
  • Thanked: 14 times
Re: Aurora C# Screenshots
« Reply #282 on: August 12, 2016, 06:59:35 AM »
No screenshots but a short update.

Research progress in the construction phase is done, as is auto-sharing of tech due to treaties, trade, etc..

Orbital Movement is virtually done. I ran a timed test for my current game, moving all system bodies, including moons, asteroids, etc (60,000 objects in 500 systems), plus moving all associated fleets, contacts, etc in orbit. It took slightly less than 0.1 seconds :)

For reference, how long would that take in VB Aurora?
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: Aurora C# Screenshots
« Reply #283 on: August 12, 2016, 08:49:47 AM »
Woo, progress!
 

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11669
  • Thanked: 20441 times
Re: Aurora C# Screenshots
« Reply #284 on: August 13, 2016, 10:08:23 AM »
Steve

That sounds very promising on performance. Any sense on how long the same process was taking under vb6?

I've switched asteroids on in the equivalent VB6 game and run the same portion of code. It required three minutes, 20 seconds :)

However, despite C# being 2000x faster for this section, it isn't just due to execution speed and holding everything in memory. Part of the reason is that I've coded it differently so that I keep track of what fleets/missiles/contacts I will need to move ahead of time, rather than checking it during orbital movement. When I originally wrote Aurora, I didn't realise how large it would eventually become so I didn't emphasis performance while coding. Now I am considering performance from the start and that alone makes a big difference.

« Last Edit: August 13, 2016, 12:43:20 PM by Steve Walmsley »
 
The following users thanked this post: Demonides, Sheb, Ayeshteni, MarcAFK