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

0 Members and 3 Guests are viewing this topic.

Offline Deedasmi

  • Leading Rate
  • *
  • D
  • Posts: 10
Re: Official v6.40 Bugs Reporting Thread
« Reply #165 on: June 09, 2014, 07:40:39 PM »
When you start a new game with no ships created, the ship screen is not very idiot proofed

Rename, random name, Auto rename, and lock design throw errors
NPR class crashes the game (What does this button even do?)
New armor causes infinite error 91 loop

This may have been user error, but I had a 15 ship fleet.  One ship got dropped out of the fleet due to maintenance failure, and exploded.  When I selected the task group, I would get the "Task group does not exist!" message.  With the task group (that does not exist) selected, deleting the selected task group would delete both task groups and all ships in the parent TG.
 

Offline Vandermeer

  • Rear Admiral
  • **********
  • Posts: 961
  • Thanked: 128 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #166 on: June 14, 2014, 10:46:20 AM »
I've stumbled across an error with a class III black hole. I moved a little fleet of separate task groups (stacking in the same location with identical speed) into a system, each of which consisted of a ship tractoring another smaller ship. They were flying with 7500 each into it (which means they slowed down to 4500 in the influence of the hole), and took route towards another jump point close to the center. Strangely and despite their displayed speed still reading the same for everybody, for unknown reasons the formation broke up, leaving a sub-stack of 3 task groups behind, while the other 5 traveled ahead (also as a stack). When time passed I recognized that the stack of 3 was not just dislocated a bit, but indeed traveling slower than the others, again despite their speed reading being identical.
What happened here was only revealed to me when the first group had already passed the target jump point to the next system: Apparently the other task group was not even flying towards the jump point as it first appeared (jump gate and center were close), but directly flying to the central body, with their speed being ~3000, no matter what their display said. I couldn't see it for a long time, because again the target jump point was so close, and I was already distracted with battles in the next system. The issue seems to be that the tractored ships of those three have for some reason been recognized separately by Aurora, and given that they have no engines, thus this speed and direction... . I could confirm this by releasing the tractor for each object, which let my tugs roam the system freely again, but when I flew in to establish a new tractor connection, it would result in the same problem again.(appears Aurora remembers the speed of those tractored bodies somehow) Right now there seems to be no way to save those tractored ships when tugs obviously can't do anything.
What is really strange about this is that the others made it through, despite at least two of them having identical conditions. I have a save of the situation before I set route through this system, because in for Aurora empirically appropriate paranoia I figured something might just go horribly wrong here. So I tested this a second time and had with the same fleet this time different ships suffering under the same effect. Obviously there is just some randomness. ..Next I will test is moving them through one by one. Anyway, it seems tractoring and black holes currently don't go well together in Aurora.

Here are spoiler containing pictures.
http://abload.de/img/unbenanntyfb0c.jpg
This one shows the three task groups with one having their module detached. As you can see the detached module flyies exactly in formation with the the other two tugs, indicating that they have the same speed of 2999, despite the reading being different. So those tugs actually just follow their tractored modules into the hole without resistance. The tug that detached its module however could break free of the deathtrap and is therefore slightly offset.

http://abload.de/img/unbenannt20zrme.jpg
This only shows the system diameter and why I could not immediately tell where they were really going, which would have given of the problem instantly. Had I targeted another jump point, I would have seen the functioning parts flying left and the other ones strangely going right for the extermination route, and it would have been obvious.

///Update: I found no way of preventing this by now. Bundling them in one task group renders that task group crippled all the time, no exceptions. Sending them through one by one, does strangely result in the exact same crafts being affected as in the first try. This indicates that there is something special with those, but I cannot see what. It is not the commercial tug part, as there is an identical one in the fleet that made it just fine. All of those three tractor military sections, but so do two of the other ones that made it through. The military parts are partly hangar, partly ordnance storage, and partly weapon platforms. There are no special differences from the building design that would explain the differences, so something else must be the culprit. I will test more.

///Update2: Ok, I have a hot tip that I could still not confirm. It turns out that the one difference between these free units with their military appendages that didn't make it, and the other two that did, is just the alphabetical order. The two that made it had the combinations H... against P..., as well as L... against P... for the tug part versus the tugged respectively, while the three that did not do it had E to D, and two times L to A.
I think it can not be coincidence that those groups that got dragged had their immobile tractored parts alphabetically first, while the others didn't. Seems the alphabetically first ship dominates the task group in the check that considers if the fleet has enough engines to get away, without considering possible tractoring. However, I could not change this outcome even when renaming both, the design and the ships so that they should stand alphabetically lower. This could however be the case, because there may be some hidden flagging of the original design or something, that just stays with the ship id and makes it therefore impossible to change the order without building a new one.
I could also have overlooked something, or maybe this was just malicious coincidence and it is something completely different. :(
« Last Edit: June 14, 2014, 03:21:52 PM by Vandermeer »
playing Aurora as swarm fleet: Zen Nomadic Hive Fantasy
 

Offline mtm84

  • Sub-Lieutenant
  • ******
  • m
  • Posts: 131
  • Thanked: 36 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #167 on: June 17, 2014, 10:59:49 AM »
Not sure if a bug or user error.   I sm'd a large sorium deposit onto Jupiter when it had none, but the civilian harvesters won't go to it.   My harvesters can get fuel from it if I send them there, but the auto commands "move to gas giant with sorium" and "unload fuel at colony and move to gas giant with sorium" will never send the harvesters back to Jupiter.
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5658
  • 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 #168 on: June 17, 2014, 11:02:49 AM »
Not sure if a bug or user error.   I sm'd a large sorium deposit onto Jupiter when it had none, but the civilian harvesters won't go to it.   My harvesters can get fuel from it if I send them there, but the auto commands "move to gas giant with sorium" and "unload fuel at colony and move to gas giant with sorium" will never send the harvesters back to Jupiter.

You did this via the System screen (F9) rather than the modify colony screen?
 

Offline mtm84

  • Sub-Lieutenant
  • ******
  • m
  • Posts: 131
  • Thanked: 36 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #169 on: June 17, 2014, 11:12:52 AM »
Quote from: Erik Luken link=topic=7012. msg73966#msg73966 date=1403020969
You did this via the System screen (F9) rather than the modify colony screen?

Yes, I was on the system screen.    If I remember correctly on turn one I used sm to re roll sol's mineral numbers, and got one I like except for no sorium on Jupiter so i added that in by hand (all from the f9 screen).    I didn't notice till years into the game when I sent my first harvesters to Jupiter, gave them the unload and move to gas giant order, and they wound up on Neptune, the only gas giant that had sorium originally.    If it makes a difference I used sm to do a full body survey then when I got what I was looking for mineral wise i unservyed the system, except for earth.   

Edit: you can set up colonies on gas giants?
« Last Edit: June 17, 2014, 07:04:44 PM by mtm84 »
 

Offline Erik L

  • Administrator
  • Admiral of the Fleet
  • *****
  • Posts: 5658
  • 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 #170 on: June 17, 2014, 11:25:28 AM »
Yes, I was on the system screen.   If I remember correctly on turn one I used sm to re roll sol's mineral numbers, and got one I like except for no sorium on Jupiter so i added that in by hand (all from the f9 screen).   I didn't notice till years into the game when I sent my first harvesters to Jupiter, gave them the unload and move to gas giant order, and they wound up on Neptune, the only gas giant that had sorium originally.   If it makes a difference I used sm to do a full body survey then when I got what I was looking for mineral wise i unservyed the system, except for earth. 

Edit: you can set up colonies on gas giants?

No, you can't. But there is two ways of adding minerals to a body/colony. The first is the way you did, which adds "raw" minerals to the planetary body. The second is adding refined minerals to the colony.
 

Offline NihilRex

  • Lieutenant
  • *******
  • N
  • Posts: 188
  • Thanked: 2 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #171 on: June 19, 2014, 08:57:15 PM »
I accidentally hauled a shipyard all over the galaxy.  Now, it has disappeared from all Tractors, and I get an error 5 with every increment.

Error 5 in Get TowedShipyardXY invalid procedure call or argument.

This has basically killed the campaign.
 

Offline Brian Neumann

  • Vice Admiral
  • **********
  • Posts: 1214
  • Thanked: 3 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #172 on: June 21, 2014, 07:40:59 PM »
Steve, there has been a long standing discrepancy with beam weapons damage.  When you design a beam weapon it gives the range on that screen.  If the range is greater than the beam weapon fire control the damage should be greater than 1 at the fire control's max range.  Currently the damage of beam weapons drops off to 1.  This only really shows up in the laser types as the top end designs can have really huge ranges.  I designed a 80cm advanced spinal laser (120cm total) which does 337 damage with a max range of over 45 million km.  I would think that the damage it would do at 1.4 million km would be about 96% or 325 approximately.  When I look at the ship design screen it shows a much lower damage at long range (32).

Code: [Select]
Quad 15cm C6.25 Far Gamma Ray Laser Turret (2x4)    Range 720,000km     TS: 100000 km/s     Power 24-25     RM 12    ROF 5        3 1 1 0 0 0 0 0 0 0
120cm C25 Far Gamma Ray Laser (1)    Range 1,400,000km     TS: 25000 km/s     Power 377-25     RM 12    ROF 75        226 113 75 56 45 37 32 0 0 0
Particle Beam-20 (2)    Range 1,200,000km     TS: 25000 km/s     Power 48-25    ROF 10        20 20 20 20 20 20 0 0 0 0
Fire Control S08 700-100000 aegis (1)    Max Range: 1,400,000 km   TS: 100000 km/s     86 71 57 43 29 14 0 0 0 0
Fire Control S02 175-100000 pd (2)    Max Range: 350,000 km   TS: 100000 km/s     43 0 0 0 0 0 0 0 0 0
Fire Control S02 700-25000 lr (1)    Max Range: 1,400,000 km   TS: 25000 km/s     86 71 57 43 29 14 0 0 0 0
Beam Core Anti-matter Power Plant Technology PB-1 (5)     Total Power Output 160    Armour 0    Exp 5%

When I did a test firing the damage actually inflicted at 1.2 million km was 37, I would have expected the damage to be over 350.  A test firing with a particle beam did the damage it showed (20 points).  The damage from railguns and carronades is just to low at long range to matter.  In my test they did 1 point of damage which is about right anyway.

My best guess is that the damage done is being scaled by the max range of the fire control and not the range of the weapon itself.

Brian
 

Offline Charlie Beeler

  • Registered
  • Vice Admiral
  • **********
  • Posts: 1381
  • Thanked: 3 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #173 on: June 22, 2014, 07:48:52 AM »
Brian,  beam damage drops off dramaticly.

I had a discussion with Steve a couple of years ago and he provided the formula:

Effective Range (in units of 10k) = Contact Dist / Weapon Range Modifier
If Effective Range < 1 Then Effective Range = 1
Weapon Damage = Round Down (Weapon Damage Output / Effective Range)

As you can see it is not liniar as you'd expect. 
Amateurs study tactics, Professionals study logistics - paraphrase attributed to Gen Omar Bradley
 

Offline Brian Neumann

  • Vice Admiral
  • **********
  • Posts: 1214
  • Thanked: 3 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #174 on: June 22, 2014, 01:42:32 PM »
Brian,  beam damage drops off dramaticly.

I had a discussion with Steve a couple of years ago and he provided the formula:

Effective Range (in units of 10k) = Contact Dist / Weapon Range Modifier
If Effective Range < 1 Then Effective Range = 1
Weapon Damage = Round Down (Weapon Damage Output / Effective Range)

As you can see it is not liniar as you'd expect. 
Thanks for the formula, this does explain the damage that I was seeing.  Which also means it is not a bug at all.

Brian
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11695
  • Thanked: 20557 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #175 on: June 22, 2014, 03:30:14 PM »
I accidentally hauled a shipyard all over the galaxy.  Now, it has disappeared from all Tractors, and I get an error 5 with every increment.

Error 5 in Get TowedShipyardXY invalid procedure call or argument.

This has basically killed the campaign.

If you still have the ship that was towing the shipyard, try using that ship to tractor something else. That might clear the problem.

 

Offline NihilRex

  • Lieutenant
  • *******
  • N
  • Posts: 188
  • Thanked: 2 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #176 on: June 22, 2014, 10:11:32 PM »
I have moved on, using a saved "setup" database to restart, however I do still have that database and will make the attempt.
 

Offline JacenHan

  • Captain
  • **********
  • Posts: 455
  • Thanked: 115 times
  • Discord Username: Jacenhan
Re: Official v6.40 Bugs Reporting Thread
« Reply #177 on: June 24, 2014, 12:00:36 AM »
A few leftovers from previous versions, they don't affect gameplay much but might as well post them here: The "Auto-Rename Shipyard" button still says that the names are from Earth shipyards, and the "Ships in Class" tab in the ship design screen has an obsolete "Show civilian registered" option near the bottom.
 

Offline IanD

  • Registered
  • Commodore
  • **********
  • Posts: 725
  • Thanked: 20 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #178 on: June 24, 2014, 02:50:33 AM »
Minor bug will only a small effect on game play. The Ships Requiring Repair tab does not show ships which only require armour repaired. In addition when you repair such a vessel in a shipyard there is no required materials displayed, I assume this should be duranium?

Ian
IanD
 

Offline IanD

  • Registered
  • Commodore
  • **********
  • Posts: 725
  • Thanked: 20 times
Re: Official v6.40 Bugs Reporting Thread
« Reply #179 on: June 25, 2014, 07:10:53 AM »
Not sure if this is a bug or not. Version 6.43, every set of ruins I come across has a research anomaly associated with it. I'm not complaining but it just seemed overly generous on Steve's part.  :D

Ian
IanD