Author Topic: v2.6.0 Changes Discussion Thread  (Read 10905 times)

0 Members and 1 Guest are viewing this topic.

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11861
  • Thanked: 21629 times
Re: v2.6.0 Changes Discussion Thread
« Reply #45 on: August 06, 2024, 07:41:08 AM »
Looks amazing so far Steve thanks a lot!
Could you please clarify the below? (Or if anyone else get's it please also feel free to help me out!)


- Species characteristics, such as growth rate, research rate, etc. are passed on when used as a base species for a new species design.

In v2.6, the new species copies the growth, density, research and production modifiers, but not in v2.5.1.
http://aurora2.pentarch.org/index.php?topic=13463.0
 

Offline AstroCrab

  • Able Ordinary Rate
  • A
  • Posts: 3
  • Thanked: 4 times
Re: v2.6.0 Changes Discussion Thread
« Reply #46 on: August 16, 2024, 06:03:48 PM »
Considering the new fire control options, wouldn't it be possible to have it operating similarly to turrets, where you input a specific tracking speed and the game does the math for you? That would be better than seeing a frakkton of 0.01 increments.
 
The following users thanked this post: Jovus, Zap0, Alsadius, nuclearslurpee

Offline nikarus2370

  • Able Ordinary Rate
  • n
  • Posts: 4
  • Thanked: 2 times
Re: v2.6.0 Changes Discussion Thread
« Reply #47 on: August 17, 2024, 12:01:11 AM »
Considering the new fire control options, wouldn't it be possible to have it operating similarly to turrets, where you input a specific tracking speed and the game does the math for you? That would be better than seeing a frakkton of 0.01 increments.

I'd argue instead of that, it would be easier to program a pair of boxes that just accept a number between 0.01 and 4.00 for the range/speed modifiers. Which is effectively what's already being done, but would save a lot of scrolling, and needing to code in a bunch of checks for "Did the user enter a range that's too high for their tech... they can only do 480,000km with a max range BFC but they've entered 1,800,000km".
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11861
  • Thanked: 21629 times
Re: v2.6.0 Changes Discussion Thread
« Reply #48 on: August 17, 2024, 05:25:01 AM »
Considering the new fire control options, wouldn't it be possible to have it operating similarly to turrets, where you input a specific tracking speed and the game does the math for you? That would be better than seeing a frakkton of 0.01 increments.

I'd argue instead of that, it would be easier to program a pair of boxes that just accept a number between 0.01 and 4.00 for the range/speed modifiers. Which is effectively what's already being done, but would save a lot of scrolling, and needing to code in a bunch of checks for "Did the user enter a range that's too high for their tech... they can only do 480,000km with a max range BFC but they've entered 1,800,000km".

The x1 and x4 (the most common) are already 1st and 2nd in the list, which will cover most of the time. The rest are no different than many other options for different component types.

I have considering re-doing the Create Project screen entirely to allow players to enter values, but that is a much larger change. The dropdowns contain information tagged to each item that is passed directly to the design functions. If I take the values from boxes, I then have to change the design function parameters, which then means updating all the automated design code to use the new parameter types.

I already did that in this case, modifying the beam fire control design function to accept decimals from the dropdowns instead of TechSystem objects. That led to adding new database fields so I could store those choices, because I needed to record them for the ship component code in the class design templates. This is because race-designed components are tagged with the tech systems used to create then, which no longer exist in this case. I also had to change the way NPRs designed ships, to use decimal values instead of tech systems. Because there is a lot of code in Aurora, it is often a lot more complex than simply changing the UI, plus all the changes also lead to increased chances of bugs.

Ultimately, it comes down to the amount of improvement in QoL vs the amount of effort required to achieve it. In this case, I finally found the lack of granularity annoying enough to justify the effort to change it :)
« Last Edit: August 17, 2024, 05:31:33 AM by Steve Walmsley »
 
The following users thanked this post: skoormit

Offline paolot

  • Lieutenant
  • *******
  • p
  • Posts: 161
  • Thanked: 25 times
Re: v2.6.0 Changes Discussion Thread
« Reply #49 on: August 18, 2024, 08:36:35 AM »
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).
 
The following users thanked this post: skoormit

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11861
  • Thanked: 21629 times
Re: v2.6.0 Changes Discussion Thread
« Reply #50 on: August 18, 2024, 09:58:49 AM »
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).

Theoretically possible, but extremely hacky. Future Steve trying to debug something a couple of years from now would not be very happy with current Steve :)
 
The following users thanked this post: skoormit

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1719
  • Thanked: 607 times
Re: v2.6.0 Changes Discussion Thread
« Reply #51 on: August 19, 2024, 06:45:11 AM »
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).

Theoretically possible, but extremely hacky. Future Steve trying to debug something a couple of years from now would not be very happy with current Steve :)

A question I just had, based on your observations of Auroras code quality. How happy is current Steve with past Steve?  ;D
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11861
  • Thanked: 21629 times
Re: v2.6.0 Changes Discussion Thread
« Reply #52 on: August 19, 2024, 09:55:13 AM »
Steve, wouldn't it be possible to hide the dropdown list, and add a box, to input the needed value, that instructs the dropdown to select the value to use in the rest of the program?
So the design part should not be modified, and there could be an easier way to input the data.
The box should anyway limit the maximum and minimum values, and the decimal digits to two (or any other number that's considered right).

Theoretically possible, but extremely hacky. Future Steve trying to debug something a couple of years from now would not be very happy with current Steve :)

A question I just had, based on your observations of Auroras code quality. How happy is current Steve with past Steve?  ;D

Fairly happy. I went into the C# rewrite with a lot of lessons learned from VB, so readability and ease of updating was a major factor, even above the most efficient possible code. I comment a lot, so its not too bad understanding what past Steve was trying to do, and use very descriptive names for functions and objects. That is especially important in complex areas, such as the AI code. In general, when I need to make changes, I don't have to spend much time trying to understand what is already happening. Where I usually get into trouble is some kind of knock-on effect of the change that I hadn't considered.
 

Offline ChubbyPitbull

  • Gold Supporter
  • Lieutenant
  • *****
  • C
  • Posts: 151
  • Thanked: 35 times
  • 2023 Supporter 2023 Supporter : Supporter of the forum in 2023
    2024 Supporter 2024 Supporter : Supporter of the forum for 2024
    Gold Supporter Gold Supporter :
Re: v2.6.0 Changes Discussion Thread
« Reply #53 on: September 04, 2024, 08:47:06 AM »
The "Say Thanks" button isn't strong enough, THANK YOU SO MUCH for making the maximum geological search radios customizable!! In my current game I've been working with several systems concurrently with widely dispersed asteroid belts where geo surveyors had to constantly be micro managed. This change is a huge quality of life improvement.

Is there a similar max set for the "Move to system requiring grav/geo survey" standing orders? I've noticed in my current ~80 year game, ships with that standing over who are starting from my home system only go a few jumps before getting stuck of a cycle of going back and forth through the same jump point.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11861
  • Thanked: 21629 times
Re: v2.6.0 Changes Discussion Thread
« Reply #54 on: September 04, 2024, 08:49:22 AM »
The "Say Thanks" button isn't strong enough, THANK YOU SO MUCH for making the maximum geological search radios customizable!! In my current game I've been working with several systems concurrently with widely dispersed asteroid belts where geo surveyors had to constantly be micro managed. This change is a huge quality of life improvement.

Is there a similar max set for the "Move to system requiring grav/geo survey" standing orders? I've noticed in my current ~80 year game, ships with that standing over who are starting from my home system only go a few jumps before getting stuck of a cycle of going back and forth through the same jump point.

There is no restriction so that sounds like a bug.
 
The following users thanked this post: ChubbyPitbull, Droll

Offline alex_brunius

  • Vice Admiral
  • **********
  • Posts: 1282
  • Thanked: 185 times
Re: v2.6.0 Changes Discussion Thread
« Reply #55 on: September 05, 2024, 09:08:15 AM »
Is there a similar max set for the "Move to system requiring grav/geo survey" standing orders? I've noticed in my current ~80 year game, ships with that standing over who are starting from my home system only go a few jumps before getting stuck of a cycle of going back and forth through the same jump point.

Ive seen some other odd or inefficient things with this standing order as well.

Mainly that survey ships tend to clump together and all end up in one or two systems after running all ships on it 5-10 years...

Would it be hard to tweak the logic to prioritize systems without any other survey ships in them or with queued orders to go there?