Author Topic: Official v6.40 Bugs Reporting Thread  (Read 94694 times)

0 Members and 1 Guest are viewing this topic.

Offline Vandermeer

  • Rear Admiral
  • **********
  • Posts: 961
  • Thanked: 128 times
Fuel Overflow in Fleets
« Reply #105 on: May 21, 2014, 11:59:38 AM »
Hello, I recently started another game as I saw the new patch and played it for over 200 years in. I happened to stumble across an error that has already bugged me in the version before, yet I didn't report it because I wasn't sure what the cause was. I have figured it out now though.

In 6.3x I used a huge star fortress with (fighters included) over 200 ships in the task group. This task group had caused me more and more error windows popping up upon task group selection, depending on how many ships I had added. This is the error:

Since the fortress was composed of (at the time) 3 huge modules, each of 150m tons, considering the general fallibility occurring at those ranges, there was huge capacity of errors coming from all kind of directions, so I didn't really have a chance of deciphering it there. The rare phenomenon here was that the first mega-module (did not matter which) did not cause any error at all, while each later one, and even the numerous fighters and bombers would supposedly increase the error window number by 1 (didn't count them exactly, but there were many). After clicking through all of them, I could use the task group just normally. Of course having to click through 200+ windows is a little too much then for practicality. I would have dealt with 3 or so, but this? No.

Now in 6.4-6.42 I have (luckily?) encountered the same problem again, yet not with such a hybris project but instead with a new strategy of mine: Fuel Depot Modules. Basically I forfeited fuel harvester ships this time, as they just don't work the way I want to - their automatic orders make them deposit their fuel at some pointless mining colony or asteroid instead of the headquarters where I want it. So in the pursuit to minimize micromanagement, I started building fuel harvester bases instead which had no engines anymore. Whenever their relatively small tank would run full, I would just transfer all the fuel of the bases on location towards a special built Fuel Depot Module, which could store alot more. Looks like this:


Should the depot eventually run full too, I just issued an automatic order for one of my tugs to fly there, take the tank back home, release 90% fuel and then take it back to the original task group. I experimented alot before coming to this, and finally found this to be the least click and think intensive method.
Now, since the Ferry here is basically nothing but one giant fuel tank, it is coming into the range where maximum fuel capacity of the game becomes relevant. Here are its specifications (unnecessary stuff hidden due to spoilers):
Code: [Select]
Naquadah Ferry Ia class Tanker    1,400,000 tons     119 Crew     83032 BP      TCS 28000  TH 0  EM 0
1 km/s     Armour 24-1114     Shields 0-0     Sensors 1/1/0/0     Damage Control Rating 3     PPV 0
MSP 130    Max Repair 128 MSP
Intended Deployment Time: 60 months    Spare Berths 1    

Fuel Capacity 1,365,000,000 Litres    Range N/A

Gravity Shield [just a renamed techy CIWS] Base 50% To Hit
This design is classed as a Commercial Vessel for maintenance purposes

Now, this is important - The games maximum possible fuel storage is 2^31,  which is ~2.1475 billion liters, so this design is around half way up to that already. Upon building multiple of these thingies to have some sort of stock I could rely on, I suddenly had to discover that those ships would produce the very same error that the fortress task group had before. One would be no problem, but more in the same TG would spawn a single or more error windows.
Perfect! A ship with only fuel tanks and a couple ciws - finding error sources doesn't get any easier than this. Obviously the error is related to the total fuel capacity in the fleet. It seems that though you could have up to ~2.14b liters on a single ship without problems, having more fuel than that number in total fuel capacity in a fleet will still cause an error. ..Nothing fully game breaking, but annoying.

I started to analyze this problem a bit more closely. I had so many error windows before, so I expected that every ship that was added to the TG after the limit was broken, would spawn another error window. As I thought I got exactly one error window when pairing two ferries in one group:


However, when adding a different ship to that - one that didn't have any fuel on its own, I unexpectedly did not get a second error window:

..So it seems that the error is not multiplied by simple ship count. But it could still be that every actual engine carrying ship would be a problem. Method of elimination, and...

...Nope. Still only one error window. It seems something has changed towards 6.4, since otherwise the hundreds of error windows in my last game could not be explained. A special thing to notice in the last picture is the total fuel count of the fleet in the lower right corner: It shows only the added fuel capacity of one ferry and the tug. The actual capacity should be 1.365b greater, yet it seems the game cannot process this.

Ok, so how to get more error windows. I had more in the same game when many ferries were in my shipyard TG, so it seems there is some correlation to actual fuel tank size rather then just number of ships now. Surprisingly I did still not get a second error window when adding a third ferry, but finally received it when having four ferries in one group.
Now it is just calculation:
Total fuel capacity of two ferries - 2.73b = 1.27 times the games maximum of ~2.147b
Three ferries - 4.095b = 1.9 times maximum
Four Ferries - 5.46b = 2.54 times maximum

I had one window with 2 and 3 ferries, and two windows with 4, so one can conclude that for every Multiple that the fuel maximum in a fleet has been breached, it spawns exactly one error window.

Now one last thing I wanted to eliminate. Maybe landed fighters and such could still cause more windows, since I had so many in the last game (mainly due to 240 fighter+facs), so I tested that too with a loaded PDC hangar (which had 1b fuel capacity on its own):


..Luckily it didn't cause any extra windows, so I guess 6.4 has really changed the wind here, making huge fortresses with fighters feasible again.
Number of error windows = times the 2.147 maximum has been breached, rounded down.


That was the error report. I would love if the maximum fuel capacity for a fleet could be heightened a bit over the ship maximum. Though with the fighter problem eliminated it is not that daunting anymore, and definitely not breaking, it still is somewhat bothersome that when you build huge ships, you can basically only ever have one in a fleet if you don't want to deal with error interruptions. Also, it isn't like 2.15b is really far up for fleets or single ships alike. In my current game I started conventional with the given 500 million guys this time, so very basic, and didn't even have a rich starting system (I think it was only around 1m duranium and few other minerals). Yet, upon discovering a few systems in the neighborhood and starting to exploit them, I easily had resource to build a fleet of my large 50 cargo stores freighters again (which I like since it reduces micromanagement, and I wouldn't ship structure in smaller increments either) - and the ferries who caused the problem here are just the same size equivalent of those, so it really isn't hard to stumble across this limitation with normal budget already.
Depends on play style of course. I see most people here prefer the small and many ships instead, which is strictly speaking really more effective because of options to divide force or freight/whatever capacity finer. I prioritize minimizing management burden and versatility of single ships though, and thus I clash onto this barrier.

/// If it helps, here is a link to my current stevefire.mdb: https://drive.google.com/file/d/0B3vZFhO9KKngOFdaa1h1aDZ2OGc/edit?usp=sharing
« Last Edit: May 21, 2014, 12:10:48 PM by Vandermeer »
playing Aurora as swarm fleet: Zen Nomadic Hive Fantasy
 

Offline Charlie Beeler

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1381
  • Thanked: 3 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #106 on: May 21, 2014, 12:59:12 PM »
Vandermeer this really isn't a bug.  You're hitting field definition limits.  Steve tends to have used the int data type in a lot of the presentation fields.  The int data type has a value range of -2,147,483,648 to 2,147,483,647 (ie it is a 32 bit, signed, two's complement). 

Steve will have to address whether he is willing to mine through all the code to change all the int types to say long (64 bit....).  I predict that whould have an adverse effect on those that are running Aurora on older systems.  For that matter, it may hasten issues with longer games reaching VB6 memory limits faster.
Amateurs study tactics, Professionals study logistics - paraphrase attributed to Gen Omar Bradley
 

Offline Vandermeer

  • Rear Admiral
  • **********
  • Posts: 961
  • Thanked: 128 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #107 on: May 21, 2014, 01:15:06 PM »
Oh, so it is a hard 32 bit issue? Damn, that seems like a hard barrier. ..Hmm, however, colonies are allowed quite larger limits than just ~2 billion for fuel, minerals, maintenance and whatever. I have no idea of the true complications behind such programs, but shouldn't it by this example be possible to accommodate larger numbers without 64bit? Or does this just cause too big of a rewrite at this point?

//Edit: Oh! Maybe there could also be a way to completely circumvent a potential 64bit transfer in the situation, if it was possible to just eliminate the summed fleet fuel calculation, the error window barrage would vanish too. I am not asking this for this helpful (and maybe even game functionality wise essential) display to vanish for real, but I assume there are clever ways in programming to prevent this sum to be generated in a direct calculation way. Larger numbers than 2^31 can obviously be displayed and calculated in 32 bit, so like if there was some sort of code wise compression through multiplication factors and who knows what, shouldn't this make it possible again, and without 64bit?
Does anything I said here make sense?^^' (<- Voted for "Excel" on the "most complex program I use"-list)

And a second idea -working but seems too much hassle- could be a new sort of fuel (antimatter?). It could have the same "storage space to range" ratio, so not really be more effective, but it could have only 1/1000th the liter count or so (/like a very large module would have 1000 liters space instead of 1m now). To prevent the issue of too small consumption increments coming up if smaller craft were to use this, one could limit the fuel storages to only very large and ultra modules or so.
I am not suggesting this to be done, as it seems like too much to change for the gain. But I had to uncover that it is at least a possible way, again without going 64bit. /Edit//


// To add to the post above: I just stumbled across another possible source of why I had so many more error windows in my 6.3x game. If a fleet can exceed the limit for fuel, why not for cargo too? The number is tracked just like fuel in the window below, so I guess this will spawn error windows as well. Probably a way more than with fuel even, so the mass of windows could still come to be in 6.4 :(. Will know that in some time when I construct another fortress/mother-cityship.
« Last Edit: May 21, 2014, 01:46:43 PM by Vandermeer »
playing Aurora as swarm fleet: Zen Nomadic Hive Fantasy
 

Offline Charlie Beeler

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1381
  • Thanked: 3 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #108 on: May 21, 2014, 01:53:24 PM »
Functionally yes it is a limit imposed by 32-bit addressing.  (1 byte = 8 bit) 

I need to make a small correction, I was using a Visual Studio 2008 reference for data types.  It appears that in VB6 Int is a 2-byte field with a range of only -32,768 to 32,767 and Long is a 4-byte field with a range of -2,147,483,648 to 2,147,483,647.  To have numeric value any larger Steve would need to use one of the decimal precision data types and accept some inherent range risks. 
Amateurs study tactics, Professionals study logistics - paraphrase attributed to Gen Omar Bradley
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5657
  • Thanked: 372 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Official v6.40 Bugs Reporting Thread
« Reply #109 on: May 21, 2014, 02:34:35 PM »
Functionally yes it is a limit imposed by 32-bit addressing.  (1 byte = 8 bit) 

I need to make a small correction, I was using a Visual Studio 2008 reference for data types.  It appears that in VB6 Int is a 2-byte field with a range of only -32,768 to 32,767 and Long is a 4-byte field with a range of -2,147,483,648 to 2,147,483,647.  To have numeric value any larger Steve would need to use one of the decimal precision data types and accept some inherent range risks. 

Don't you love when Microsoft redefines computer terms?
 

Offline bean

  • Rear Admiral
  • **********
  • b
  • Posts: 921
  • Thanked: 58 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #110 on: May 21, 2014, 03:03:37 PM »
OK, I will increase the size of the array that holds potential assignments.


Excellent.  I await with baited breath, as that game's more or less on hold until that's fixed.
On a related note, would it be possible to add a 5th ground rank?  I regularly have officers promoted to 'full General' on my big games, but there haven't been enough problems for me to raise this before.
This is Excel-in-Space, not Wing Commander - Rastaman
 

Offline Charlie Beeler

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1381
  • Thanked: 3 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #111 on: May 21, 2014, 03:11:13 PM »
Don't you love when Microsoft redefines computer terms?

It's worse than that for me.  My back ground is mainframe COBOL.  Data fields are defined in a completely different manor. 
Amateurs study tactics, Professionals study logistics - paraphrase attributed to Gen Omar Bradley
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #112 on: May 22, 2014, 04:39:52 PM »
I'm trying to transport a terraforming PDC which is around 100,000 tons.   It seems to be impossible to automate the delivery of PDC components.   I can get my cargo ships to make a single run of PDC parts, but no more.   They always "Fail to pick up PDC components from Earth.   Please reschedule the order. "  The PDC is done being prefabbed, and is on Earth.   This problem happens no matter how I try to automate the delivery.   Whether its queueing up a bunch of load and unload orders, or queueing one set and setting it to repeat.   This is brutal because it'll be quite a few trips to transport all the parts.   Either it's a bug or I'm missing something.
 

Offline NihilRex

  • Lieutenant
  • *******
  • N
  • Posts: 188
  • Thanked: 2 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #113 on: May 22, 2014, 08:25:57 PM »
Ive run into a similar problem as Barkhorn, but it seems to only happen when running cycle orders.

Best solution I have found is to use a larger cargo fleet.
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #114 on: May 22, 2014, 08:32:09 PM »
I've used both means of automation on other installations.   It seems to have something to do with the PDC.

Oh well, I did eventually finish delivering it, it was just a pain.
 

Offline Saibot

  • Warrant Officer, Class 1
  • *****
  • S
  • Posts: 79
Re: Official v6.40 Bugs Reporting Thread
« Reply #115 on: May 23, 2014, 10:33:38 AM »
I've had 2 civilian fuel harvesters near Neptune constantly "moving to Sorium site at Neptune" but never actually entering orbit and harvesting for over a year I believe(sorry I don't know precisely when they were created/arrived).
 

Offline Kaiser

  • Commander
  • *********
  • K
  • Posts: 322
  • Thanked: 41 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #116 on: May 23, 2014, 02:06:12 PM »
I discovered the system of Lacalle9352. The system is located to 2 jump points from the Sol system (Sol - Luhman - Lacalle).
I gave to my jump ship the order to jump in Luhman and after to Lacalle, the mission has been accomplished, but I cannot enter in the system. I mean, I cannot see it in the menù on system map, but I can see it on f9 with planets, stars etc etc, but again I cannot fisically enter to it ;(
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5657
  • Thanked: 372 times
  • Forum Admin
  • Discord Username: icehawke
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2022 Supporter 2022 Supporter : Donate for 2022
    Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Official v6.40 Bugs Reporting Thread
« Reply #117 on: May 23, 2014, 02:40:51 PM »
I discovered the system of Lacalle9352. The system is located to 2 jump points from the Sol system (Sol - Luhman - Lacalle).
I gave to my jump ship the order to jump in Luhman and after to Lacalle, the mission has been accomplished, but I cannot enter in the system. I mean, I cannot see it in the menù on system map, but I can see it on f9 with planets, stars etc etc, but again I cannot fisically enter to it ;(

On the F9 screen, follow the Jump Points. Go to the JP tab, select the appropriate JP and click Enter. The link might be broken.
 

Offline Kaiser

  • Commander
  • *********
  • K
  • Posts: 322
  • Thanked: 41 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #118 on: May 23, 2014, 02:50:54 PM »
Thank you Erik, It works!!! The system is rich of interesting planets, it would be a pity do not explore it!
 

Offline AbuDhabi

  • Sub-Lieutenant
  • ******
  • Posts: 104
  • Thanked: 2 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #119 on: May 23, 2014, 05:31:32 PM »
Playing 6.42. Found a black hole. Black hole's pull was greater than my scout's maximum speed, so I sent it right into the thing because I thought it would die faster.

Nope! If your speed is made negative by the BH, you can't accelerate at all - even in the direction of the hole! So I guess my scout will take some months to finally get to the event horizon, at -77 km/s.

The scout then proceeded to run out of fuel. But still moved at the same slow speed towards the BH.

---

In addition, robot guardians and captured excavation sites are weird. It went like this:
Find abandoned facility, sent teams and construction brigade.
They find robots, and robots kill them, taking over the colony... but the colony keeps the civilian contracts it had, as it did the order to bring additional soldiers on my own transports.
The newly captured site becomes a new alien race, can't communicate, but whatever. This is roughly working as designed, maybe.
I make a new colony on the planet, and send soldiers there, and through the ground forces screen, I am able to transfer my earlier reinforcements from the enemy held colony to the one I made.
I kill the robots, and take over the site (which now is Conquered).
Now I have two sites of the same species on the same planet, with their own inventories and crap.

Any way to merge them without having to transport all the transportable stuff, and abandon that which can't be transported?
« Last Edit: May 23, 2014, 08:12:02 PM by AbuDhabi »