Vega-strike-engine-source: Strange velocity 'bouncing' behaviour with SPEC

[Calendis]

Platform: Linux
Using the latest master (vssetup identifies as 0.6.0)

Sometimes (about 50% of the time? It's hard to say), when using Auto-pilot to approach or leave a major object, the ship's velocity will not behave properly. It will rapidly 'bounce' between seemingly random velocities from the hundreds range to the tens of thousands. During this, the positions of major objects also seem to bounce, but maybe this is only an illusion due to the rapid velocities involved?

This will continue to happen even after auto is turned off, making it essentially impossible to control your vessel. The effect can sometimes be calmed by switching to another target, but it will come back. This is while auto pilot is off, so targeting different objects shouldn't affect my control. I have tested using "default", "realistic", and "classic" physics, and it can occur on all three modes.

Flying close to a major object using autopilot and then switching targets seems especially likely to trigger this. I can provide additional information if needed, or record a video

[nabaco]

Hi Calendis,
Thank you for the report. We have seen this issue too. Could you please attach logs to the issue, after issuing the following command?
vegastrike > output.log 2>error.log

A few questions

1. Does this happen while targeting any object? I have seen it happen when flying to a jump point sarrounded by asteroids, and thought it might be related due to the complicated maneuver the autopilot tries to do.
2. Did you try to do a manual SPEC flight? I think I had the same issue flying manually too, so it might not be related to autopilot.
3. In case it happens in manual SPEC flight too, does it happen in long regular flight?

Meanwhile, we're investigating the issue too.

[Loki1950]

Deja voodoo very old behaviour any gravity well affects SPEC and the behaviour can seem random since I have been unable to build an executable on Mint 19.3 I can not give a informed option but it has been a comment about SPEC that is long standing

[stephengtuggy]

I have seen this same bug. Was planning to report it; just hadn't gotten my thoughts together yet. Thanks, @Calendis .

[Loki1950]

Well i am seeing the expected behaviour used auto from starting planet orbit Atlantis set ship to proper orientation on Serenity base toggled auto SPECed straight to the base dropping out of auto 2500 m from base hit "Home" to match velocity asked for docking clearance docked with no issues saved game now to hack the save file for mega cash and continue testing

[Loki1950]

For all testing auto you need to line up your target destination before you toggle auto not doing so is what leads to the erratic behaviour further advise UtCS assumes you know how to fly your ship and is unforgiving of bad ship handling so do Oswald's tutorial to learn the basics

[Calendis]

Thank you for the report. We have seen this issue too. Could you please attach logs to the issue, after issuing the following command?
vegastrike > output.log 2>error.log

I might have done something wrong, but it didn't like that! Crashed with Panic exit - mission file output.log not found. error.log was written, but I don't think it contains anything useful since the game crashed instantly.

1. Does this happen while targeting any object? I have seen it happen when flying to a jump point sarrounded by asteroids, and thought it might be related due to the complicated maneuver the autopilot tries to do.

I was able to get it to happen just from flying to a planet
2. Did you try to do a manual SPEC flight? I think I had the same issue flying manually too, so it might not be related to autopilot.
Yes, it happens during manual SPEC. On first test, it happened after I was close, once i switched targets off of the object I was lined up with. On test two, it happened much before I even reached the object! Didn't switch targets at all.
3. In case it happens in manual SPEC flight too, does it happen in long regular flight?
What's the best way to test this?

@Loki1950 I am actually on Mint 19.3. I did the tutorial, and notably, this didn't occur during Oswald's tutorial. I don't remember this particular issue ever happening when I played the game a few years ago, so I think it's a recent issue. Turns out it wasn't related to auto since it can occur from regular spec.

[Loki1950]

@nabaco forgot to put ./ in front of the the cmd line he gave you ;)

[Calendis]

@Loki1950 Ah thanks.
@nabaco I've attached the logs
error.log
output.log

[Loki1950]

@nabaco is away for the weekend @Calendis can you describe what you did during this session because I see no activation of SPEC in either log after further testing on my local version I find that logs will be useless for debugging as the velocity is not logged

[nabaco]

While testing #86, I didn't get this issue, until I killed a ship. Now in all other cases I got this issue, I killed a ship before hand. It seems that when I'm getting locked on someone's radar, the SPEC drive is going nuts...

-- UPDATE --
Second time it happened when I tried to fly to a non-planet object. (Oldizey: Diplomatic Center 1). SPEC drive went haywire, and I crashed into it :disappointed:

[royfalk]

This is an issue that I remember from 15 years ago. The way I see it, there are a couple of things here at play:

1. SPEC is sensitive to mass. I've had capital ships force me out of SPEC when they intercepted me. I see this as a feature, though I don't fully understand the mechanism.
2. Planetary objects, of course, have the same effect. The startup system is actually weirder than most because it's a binary system.
3. I've seen the bug where SPEC starts and stops. Not sure if it's intentional (cool effect or a bug).
4. There's also the question of auto-pilot for SPEC. It has an algorithm for determining the best course, which may or may not be optimal.
5. Crashing with SPEC shouldn't be possible right now, though we may/should program it in for edge cases.
   Bottom line, SPEC should be a well encapsulated module. Once we refactor it, we'll be able to have a meaningful discussion about whether the design matches the reality.

[Loki1950]

Some bases also have SPEC inhibitors and some of the Confed enforcer ships as well the auto pilot code was written by @klaussfreire .Re: crashing while SPEC in on you can fly through a sun/star ATM as for the fluctuating velocity it was always so part of the beast.It's the wild vector changes that should not happen though that can happen if you just toggle the auto without lining up on your destination first.

[stephengtuggy]

Guys, I am definitely seeing objects (planets/bases) move around relative to my ship. It makes me seasick to watch a lot of times. Makes the game almost unplayable at times, for me.

For instance, I will be sitting in space, having just undocked from Serenity, not going anywhere. Yet Serenity starts moving across the sky away from me! Two steps forward, one step back. Juddering, you might call it. To the tune of many kilometres per "step."

Also, SPEC kicks in way too fast when leaving a planet. Then it slows down again, then speeds up again, etc.

I don't remember these things being anywhere near such a problem two years ago. I think this might be a different beast than what was there before.

[Loki1950]

First of have been matching velocity with your target location the "Home" key then lining up the two sets of cross-hairs on the HUD before you engage either the autopilot or SPEC i'm not seeing any of this except the varying SPEC multiplier which is normal behaviour and yes you will change heading quite a few times as the autopilot skirts gravity wells with SPEC multiplier variation all the way so I not having these issues at all so I suspect the wetware at the keyboard always remember you always have velocity vector relative to all objects with mass

[BenjamenMeyer]

I've seen similar; the gravity well explanation fits, but this may be a case where we need to introduce some more (or change) configuration around the physics engine and make the default more forgiving.

@Loki1950 states that the "classic" configuration is more akin to how Wing Commander worked vs the realistic configuration.

Regardless of which configuration (realistic, classic) is used the game should be fun to play and relatively easy do jumps and docks.

[Loki1950]

Not sure if the relevant variables behave in a linear fashion
config file line
```

```

[Loki1950]

Missing comment line that that block starts with
<!-- REAL accel is game_speed * game_accel go figure. No nested comments (apparently) allowed by expat -->

[stephengtuggy]

@Loki1950 I will try the Home key; thanks for that.

[stephengtuggy]

First of have been matching velocity with your target location the "Home" key then lining up the two sets of cross-hairs on the HUD before you engage either the autopilot or SPEC i'm not seeing any of this except the varying SPEC multiplier which is normal behaviour and yes you will change heading quite a few times as the autopilot skirts gravity wells with SPEC multiplier variation all the way so I not having these issues at all so I suspect the wetware at the keyboard always remember you always have velocity vector relative to all objects with mass

Matching my velocity with the target location via the Home key, plus lining up the crosshairs on the HUD, certainly does help. And based on your latest explanation, @Loki1950 , I finally see why this might be necessary -- even in a game LOL. As you said, the player always has a velocity vector relative to all objects with mass.

There is still some 'bouncing' behavior that is unexplained though. I am running in censorship mode Censored. Is it possible that a ship I don't see is affecting my movements?

[stephengtuggy]

Between Default, Classic, and Realistic, I last chose Default. FWIW.

[Loki1950]

All the the censorship is a few of the loading splash screens had a religious type who said that they where inappropriate for his little sister,now as for an invisible ship we do have a clocking devise but it's very rare it something in calculating the psychics frame perhaps.

[stephengtuggy]

@Calendis can you see if lining up the cross-hairs and using the Home key helps with the issues you've been encountering? Perhaps combined with using the Default or Classic configuration, in order to speed up acceleration and velocity-matching?

[BenjamenMeyer]

Q: is this defined well enough that we can either close it or move it to 0.7.x? Or is this a must fix for 0.6.0?

[nabaco]

I personally think we must fix this in the coming release, as it makes the game play really challenging.

[stephengtuggy]

Only trouble is, it may require a deep dive into the code that we don't have time for, if we are going to get 0.6.0 out the door quickly.

[stephengtuggy]

@nabaco So you are seeing it too?

[nabaco]

Yes, I experience it frequently during my tests.

[stephengtuggy]

I think it would be helpful to have a video capture of this behavior, to help explain it/identify it. Perhaps I could make a video capture. I will have to read up on how to do that with ffmpeg or something though.

[BenjamenMeyer]

@stephengtuggy there's a number of tools you can use - even a simple Zoom session recording your window would suffice. I know there's some better stuff out there - taking a look at Debian/Ubuntu I see Kazam, Peek, and Deep Screen Recorder; haven't tried any of them. Not sure what platform you're on. We probably should document something of that nature until we have a built-in tool to capture a video of the game play (I know we can do screen shots already.)

[stephengtuggy]

@BenjamenMeyer I'm on Ubuntu. My Debian environment is a virtual machine, suitable for compiling the code and minimally running it, but not really for testing gameplay.

Turns out that Ubuntu has a built-in feature for doing what they call a "screencast". It looks like this will be easier than I thought.

[stephengtuggy]

Here is a video of Serenity juddering away through space just after I undocked from it: https://youtu.be/komVYMHZJdI

[stephengtuggy]

Here is another video: https://youtu.be/vpXnVYyAF3g In this one, the target crosshairs disappear and reappear. When this happens, it often seems to coincide with problematic autopilot behavior, such as overshooting (zooming past) the target object, or perhaps simply spinning around in space with the autopilot unable to find the target planet.

[stephengtuggy]

Still working on documenting at least one more of these problematic game behaviors.

[BenjamenMeyer]

@stephengtuggy thanks for the videos. I haven't actually seen this behavior myself.

https://youtu.be/komVYMHZJdI

• seems to have issues with knowing where in space the vessel and/or the planet is
• initial issue seems to present itself between 1-3 seconds where the base jumps away and back again

https://youtu.be/vpXnVYyAF3g

• I see the cross-hairs go away, but I don't see them return. Am I missing something?

[stephengtuggy]

My Vega Strike settings:

[stephengtuggy]

https://youtu.be/vpXnVYyAF3g

• I see the cross-hairs go away, but I don't see them return. Am I missing something?

I didn't manage to capture the "return" part on video. The cross-hairs did come back though. They were cutting in and out several times in a row, as they have a habit of doing. I caught the middle section of that.

[nabaco]

I recommend to try compiling the game without #57, and then to try and reproduce the issue.
I suspect that this change is the culprit.

[evertvorster]

I am seeing something like this too. Build vegastrike from master git repo on 17/June/2020.

https://youtu.be/ZUqAY-XcZyQ

That video I had just launched from that station. No SPEC has been engaged (yet) As best as I can describe it, some objects seem to bounce around in space, others not. When nearing a planet I see many dots bouncing around on the radar, which is also not something I am used to seeing.
----Edit----
Just want to add, the game is nearly unplayable because of this bug, SPEC would shoot past planets, can't dock with mining bases, etc.
Not knowing the code in the least, I can only comment on what it "feels" like.
It feels like some objects are semi-randomly changing their position in space. I have seen this on ships and bases, but not all the time. However, the errors in position are not completely random, they are bounded in a tight area. This would suggest to me that there is some rounding of the position description of some objects going on.
It would also explain the SPEC jumps, as SPEC uses distance from object to determine how much of a speed multiplier to apply, and when the relative distance is fuzzy.

[evertvorster]

@nabaco I read in a very old document that VegaStrike engine is supposed to use double precision to accurately simulate the huge distances. https://wiki.vega-strike.org/Vegastrike:Features under 0.2.9 changes. When I look at the files in #57 I see a lot of mention of "float" which has about half the digits of "double" Could this loss of precision be why things appear to be jumping around in space, or am I barking up the wrong tree?

[Loki1950]

@evertvorster I pointed this out a while ago as well though my understanding of the code is minimal just experience doing the same calculations by hand with a sliderule in the days before micro-processors

[evertvorster]

@Loki1950, you really are showing your age! I am not a young 'un either, and have maybe _seen_ a slide rule twice. Anyways, I am going to be poking at this bug, even though what I know of coding is often described as dangerous, as this stops me from playing/enjoying the game. I have loads of time on my hands due to the town where I live being locked down because of COVID-19, and a dust storm brewing outside.

[evertvorster]

More information on this bug... Just launching from the mining base in Cephid-17, and then stopping, I can see the station apparently jumping around. It may be my ship jumping, motion in space is relative. However, my speed meter is pegged at 0, so I think it's the base. If you watch is for a about a minute, the base position settles down, where it's supposed to be. After about a minute is starts to jump around again. It is worth noting that SPEC was not enabled at all. I can upload a video, if anyone is interested. However, it looks like a pretty hard bug if everyone is seeing it. This bug destroys game play, so there should be no release until this is fixed in my opinion.

[Loki1950]

Have you used the "Home" key to match velocities that has been my first action after every launch almost from the start of playing this game it has become a habit

[BenjamenMeyer]

Something to try since we suspect the recent vector refactor:
https://github.com/vegastrike/Vega-Strike-Engine-Source/blob/master/engine/src/gfx/tvector.h#L175

Try changing the above to use only doubles for both vector types.

[evertvorster]

@BenjamenMeyer I replaced every instance of 'float' for 'double' in that file, but now I get a compile error.
I think where it is going off the rails is here:
--------------------snip-------------------------
[ 0%] Building CXX object CMakeFiles/OPcollide.dir/src/cmd/collide2/Ice/IceAABB.cpp.o
In file included from /data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/gfx/vec.h:8,
from /data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/gfx/quaternion.h:4,
from /data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/cmd/collide2/opcodesysdef.h:28,
from /data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/cmd/collide2/Stdafx.h:21,
from /data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/cmd/collide2/Ice/Stdafx.h:1,
from /data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/cmd/collide2/Ice/IceAABB.cpp:21:
/data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/gfx/tvector.h: In instantiation of 'class TVector':
/data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/xml_support.h:125:39: required from here
/data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/gfx/tvector.h:67:25: error: 'const TVector& TVector::operator=(const TVector&) [with S = double; T = double]' cannot be overloaded with 'TVector& TVector::operator=(const TVector&) [with S = double; T = double]'
67 | const TVector& operator=( const TVector &a );
| ^~~~
/data/OS/aur/vegastrike-engine-git/src/Vega-Strike-Engine-Source/engine/src/gfx/tvector.h:56:14: note: previous declaration 'TVector& TVector::operator=(const TVector&) [with S = double; T = double]'
56 | TVector& operator=( const TVector& other );

[evertvorster]

Just removing one more variable... this same error also happens with boost libs of the python2 variant.

[BenjamenMeyer]

@evertvorster thanks for trying

[BenjamenMeyer]

Hmm...there's 9861 float references but only 1532 double references in the source...

[evertvorster]

Tested this with the 6.6.x branch & python2, the bug is present there, too.

[evertvorster]

I compiled the stable_2020 branch, and this does not seem to have the bug. I do have a question, though. I see on my radar little dots that are bouncing around, sometimes so many of them that they look like clouds, but can't seem to target them. What is that all about? I have to say, there are a whole lot fewer of those bouncing dots in the stable_2020 branch.

[evertvorster]

The bouncing dots on my radar turned out to be ships, but they stop bouncing when under the targeting crosshairs, with the stable_2020 engine.

[BenjamenMeyer]

Looking closer at PR #57 I think we have some conversions going wrong.

I'm going to suggest we:

• look closely at any QFloat references - they're actually Doubles not Floats
• Check usages and ensure everything is working with doubles in that code appropriately

The original code might have expressed a Float but may have worked internally on a Double; or even only worked on Doubles. I do like the structure of the new code better.

Also from some of my discussion with @evertvorster I think this issue has been present all along, it's just that the refactor brought it more to the forefront of things. Hopefully that means we'll also have a more comprehensive solution/fix too.

[BenjamenMeyer]

One thing I noticed - in tvector there's a note about QFloat being a float; however, that's not the case - it should have been a double.

Also we might have gotten a little ambitious in add f to x.y values in code reviews.

[Loki1950]

That is what happens when the person refactoring does not understand the underlying logic of the code in question

[BenjamenMeyer]

@Loki1950 agreed; and we're all learning the codebase here. We'll get it fixed; that much I'm sure.

Any how... created a specific chat for anyone wanting to live discuss this:
https://gitter.im/vegastrike/vegastrike_bug-91_discussion

BTW - QFloat could be either a Float or a Double...guessing it's system dependent; either way, it's been dropped out. I'm presently comparing 0.5.x and 0.6.x to try to bring it back and provide something for folks to test with.

[royfalk]

A brief explanation for people trying to figure out this vector stuff. This is from memory, so I may get some minor detail wrong but I’m confident of the substance.
There are two vector classes – Vector and QVector (not to be confused with std::vector).
They represent vectors in space.
Vector is float based and QVector is based on double.

To implement this, they wrote a vector.h with the basic implementation and placeholders for A and B (probably FLOAT and QFLOAT).
This file does not compile.

In gfx/vec.h they included vector.h twice. The first time they surrounded it with a macro defining FLOAT=float and QFLOAT=double and the second time in reverse.
That way, they implemented the same code twice with minor changes. This is important, as we need to convert from float based vector to double and in reverse.

You probably can’t just willy nilly search and replace float to double and stay with QVector because the save game does some binary stuff that depends on the type.

My implementation was basically the same but with templates. I then defined Vector to XVector and QVector to XVector. It should and appears to be the same.

Unfortunately, I’m finding the code to be very hard to refactor in any meaningful way without breaking stuff.

For the record, I recall a lot of these “bugs” from 2006 or so. Dots on the radar are ships in SPEC. Ship in auto pilot triggering SPEC repeatedly near destination and overshooting. I think maybe even stations moving (but there I could be wrong).

From: Benjamen Meyer [e-mail]
Reply-To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Date: Saturday, 20 June 2020 at 6:35
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Roy Falk [e-mail], Comment [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Strange velocity 'bouncing' behaviour with SPEC (#91)

@Loki1950https://github.com/Loki1950 agreed; and we're all learning the codebase here. We'll get it fixed; that much I'm sure.

Any how... created a specific chat for anyone wanting to live discuss this:
https://gitter.im/vegastrike/vegastrike_bug-91_discussion

BTW - QFloat could be either a Float or a Double...guessing it's system dependent; either way, it's been dropped out. I'm presently comparing 0.5.x and 0.6.x to try to bring it back and provide something for folks to test with.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/91#issuecomment-646932074, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEBZVKJ2EWRLF4EME4DRXQVBJANCNFSM4M27CAIA.

[BenjamenMeyer]

@royfalk thanks for the info; yeah - I can confirm too. I've been reading through the code and trying to find places that were appropriate to change.

Reading through...there's a lot of places that rely on Float for external functionality (external libraries, graphics calls, etc) so I don't think we can go to double only outright...we'd still need a conversion at some layer. Question is if we can keep to double as much as possible and drop to float at the last minute where required? Or would that itself introduce too much in terms of precision loss...

OTOH, if float/double proves to be too big an issue, then it might be necessary to bypass that all together and move to bigint computations which were not practical on systems of old but should be now. That, however, would be a huge departure...and I wouldn't recommend such an undertaking any time too. (Just noting it while I'm thinking out loud on the issue.)

[BenjamenMeyer]

With #150 merged that solves the issue for the 0.6.x branch, so moving the target of this over to 0.7.x.

FTR, I'm okay with doing similar merges as #150 for 0.7.x and 0.8.x _when those branches get cut off master_ as temporary solutions so we can continue moving forward as we do have general date targets (EOY 2020) where we want to have those out; however, I'd like a final solution by the time we cut the 0.9.x branch.

[BenjamenMeyer]

Also lowered the priority for the time being. Once we hit 0.9.x if it's still not solved then it needs to be the highest priority again.

[evertvorster]

Evert_Testing_Serenity_Cephid_17.tar.gz

This is a test file that shows the bug clearly. If you are running an engine that is bugged, just launch the ship. On my computer the mining base jumps around in space on a bugged engine.

[evertvorster]

Some more info on this bug:

There does seem to be a time component too.
When watching a bouncing installation for a minute or so, it settles down in one spot. What would make a precision go bad, then good, then bad again?

The bounce seems to be along one axis only.
The installations, when they bounce, it is along a straight line.
If it was a general loss of precision, the bounce would be in all directions. It may just be a typo in one of the axis' definition somewhere.

I'll fly around the universe, and see if it affects one faction more than others. So far I have seen klk'k and purists bounce, no one else.

[evertvorster]

Adding more descriptions of the bug in-game:

I have seen some extra weirdness. Started a new game, and once I launched, Oswald started to chat me up. His target on the radar was bouncing around. However, when I oriented my vessel to have him in the middle of my radar, he did not bounce. (and the dot on the radar was stationary) In fact, I only saw him bouncing on the radar.

With the unified units.csv, there are a LOT less dots on the radars, and about one or two will be bouncing.

Then I flew over to Serenity. It was hanging around in one spot in space. Then, it's shields started flashing like something was attacking it, but I did not see anything. Then, it started bouncing around in space. The bouncing lasted for about a minute, then stopped.

So, there seems to be some kind of time factor too.

Then I jumped to Stirling... in Stirling, the jump point to Cephid-17 was bouncing around. It definitely was the jump point moving in space. As luck would have it, there was an asteroid field around the jump point, and it was stationary, with the jump point jumping along a straight line.

I believe the bit of a video that I captured earlier with this bug in action shows the mining asteroid also moving along a single axis.

[BenjamenMeyer]

Yeah, I think everything I've seen has been a single axis too.

[stephengtuggy]

FYI: When dots on the radar are bouncing around slightly, that is intentionally part of the game. (Though we might want to look at changing it.) When the dots are going crazy, however, that might be a different story.

[stephengtuggy]

In other words, the radar dots are a separate issue, as far as I can tell.

[royfalk]

I think I said it earlier, dots moving fast is probably SPEC ships moving in FTL.
I remember this from the last decade, so not a new thing.
The Evert mining base bouncing is definitely my regression.

From: Stephen G Tuggy [e-mail]
Reply-To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Date: Monday, 13 July 2020 at 0:40
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Roy Falk [e-mail], Mention [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Strange velocity 'bouncing' behaviour with SPEC (#91)

In other words, the radar dots are a separate issue, as far as I can tell.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/91#issuecomment-657279367, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBECAZ5A637SCAM3TQVDR3IUVBANCNFSM4M27CAIA.

[evertvorster]

@royfalk the spots bouncing on the radars are NOT ships in SPEC.

Even before the Vector refactor, the bouncy spots are definitely not ships in SPEC.
It probably was a porky pie (lie) that someone told to make pesky users go away.

Reason for saying this? When targeting these bouncy dots, they turn out to be vessels just sitting around. This is confirmed by the spots staying in the same general area. Ships in SPEC shoot across the radars, and that I see often, too.
Look at:
https://youtu.be/YnQLkb_OazM
It is a short video grab showing a targetted LIHW ship, pootling along at non-SPEC speeds. When he's in front of me, his target does not bounce. When he's off to the side, he's bouncing like a mofo.
Engine used is 0.6.0, with the vector refactor rolled back, so... historic behavior.

So, is it related to the bug after the Vector refactor? I don't know, but they look similar on the radar.

As Stephen said, it probably was intended behaviour to have some spots bouncing on the radar, for whatever reason. (Cloaking? ECM active?) That would explain the time factor I mentioned earlier, but not the linear-ness of the error after the Vector refactor. It's quite sloppy coding to re-use variables, so I am tempted to agree with Benjamin, in that it probably would be best to pair out the various variables that we re-used, and find the spot where they intermingle.

[royfalk]

If I had to guess, I’d say that’s a bug in the radar code and not an intentional feature.
I suspect that as we clean up the code, a lot of stuff like this will also disappear.

From: Evert Vorster [e-mail]
Reply-To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Date: Monday, 13 July 2020 at 12:02
To: vegastrike/Vega-Strike-Engine-Source [e-mail]
Cc: Roy Falk [e-mail], Mention [e-mail]
Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Strange velocity 'bouncing' behaviour with SPEC (#91)

@royfalkhttps://github.com/royfalk the spots bouncing on the radars are NOT ships in SPEC.

Even before the Vector refactor, the bouncy spots are definitely not ships in SPEC.
It probably was a porky pie (lie) that someone told to make pesky users go away.

Reason for saying this? When targeting these bouncy dots, they turn out to be vessels just sitting around. This is confirmed by the spots staying in the same general area. Ships in SPEC shoot across the radars, and that I see often, too.
Look at:
https://youtu.be/YnQLkb_OazM
It is a short video grab showing a targetted LIHW ship, pootling along at non-SPEC speeds. When he's in front of me, his target does not bounce. When he's off to the side, he's bouncing like a mofo.
Engine used is 0.6.0, with the vector refactor rolled back, so... historic behavior.

So, is it related to the bug after the Vector refactor? I don't know, but they look similar on the radar.

As Stephen said, it probably was intended behaviour to have some spots bouncing on the radar, for whatever reason. (Cloaking? ECM active?) That would explain the time factor I mentioned earlier, but not the linear-ness of the error after the Vector refactor. It's quite sloppy coding to re-use variables, so I am tempted to agree with Benjamin, in that it probably would be best to pair out the various variables that we re-used, and find the spot where they intermingle.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/91#issuecomment-657424193, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEGMNB4FTOCHXCK55T3R3LEQHANCNFSM4M27CAIA.

[stephengtuggy]

@Calendis Thank you again for reporting this issue. After a lot of effort, we believe it is finally fixed. Can you confirm?

[Calendis]

e. After a lot of effort, we believe it is finally fixed. Can you

Oh man, sorry I've been gone for so long. I'll try compiling now

[stephengtuggy]

@Calendis No worries. Have you been able to compile it?