NEED INFO Build 493 Unstable

[88mphTim]

It is not a fals positieve I now have a infected browser and **** this is unacceptable!

The same file was uploaded to both locations. It came from somewhere else.

If you were correct, it would have happened to everyone who installed it, not just you.

 

[88mphTim]

Is there a build 493 SDK release or do we have to wait for a stable build to get that?

Yes.

 

[88mphTim]

I also might end up with an infected browser &/or pc if I ignored the virus warning from Eset and ran the .exe

While everyone who does not use ESET got no warning, and no virus....... Sounds like he has malware, and a quick google search can tell you where a specific infection comes from. Freeware, and this one sleeps, it sounds like, until a morning startup.

 

[TechAde]

Yes.

Thanks Tim, but is that a 'Yes, there's a build 493 SDK' or a 'Yes, we have to wait for a stable build'?

 

[88mphTim]

Thanks Tim, but is that a 'Yes, there's a build 493 SDK' or a 'Yes, we have to wait for a stable build'?

Stable.

 

[TechAde]

Stable.

Righto, thanks.

 

[88mphTim]

Yes, I agree - it's very inconsistent that only Eset users are getting it, & you obviously are running it with no probs - I did attempt to submit the quarantined .exe to Eset but was unable to, probably as the size of it is too large..

Edit: of course there is one other possibility: you are infected but don't know it. I've been in touch with Eset UK so they will be able to tell me whether it is actually a false-positive. Which I imagine will be reassuring to us if it turns out to be so..

Feel free to post an update when you get it. I'm still using google as my search engine.

It is relatively easy to get those search engine issues. My dad has done it a few times, most recently installing TeamSpeak. Hell, even Sun Java tries to give you an Ask toolbar. I've never done it - yet - as I tend to read what I am installing. An increase in worry based on a false positive, I can understand the questioning.

 

[kaptainkremmen]

Avast was concerned while I was installing. Don't normally see that. When finished it said nothing was wrong and sorry for the wait .

 

[88mphTim]

Avast was concerned while I was installing. Don't normally see that. When finished it said nothing was wrong and sorry for the wait .

We do have to put a security cert in our installers now, not sure if Jeremy does it for the unstables......

 

[MarcG]

Avast was concerned while I was installing. Don't normally see that. When finished it said nothing was wrong and sorry for the wait .

I use avast and got no such warning or notification, only when I click Manage Mods (see thread further down the page) do I get a slight issue.

 

[Tony]

Ok I've had a reply from Eset:

Dear Tony Simmonds,

Thank you for your submission.
The downloaded file will be undetected in our next update.

Regards,

ESET Malware Response Team


So I'm guessing from that reply that it is a false-positive & they'll add whatever it was that was causing it to their "ignore" list - worldwide presumably

I did ask for confirmation that it was actually a false positive, so might get that affirmation tomozz

 

[88mphTim]

Appreciate you taking the time, Tony.

 

[Tuttle]

Ok I've had a reply from Eset:

Dear Tony Simmonds,

Thank you for your submission.
The downloaded file will be undetected in our next update.

Regards,

ESET Malware Response Team


So I'm guessing from that reply that it is a false-positive & they'll add whatever it was that was causing it to their "ignore" list - worldwide presumably

I did ask for confirmation that it was actually a false positive, so might get that affirmation tomozz

AFAIK the information and the certification about the false positive have to be confirmed by you and/or by the author (company) so I don't think they can give you any further information about that.

To obtain a full scan of the file you need to package it and then send that file to ESET but honestly I can't see the point for a stuff like that. It is clearly a false positive.

EDIT; hmmm...I guess you already sent the file. n/m

 

[Adrianstealth]

hiya

gave this build a quick try, problem below :

3D vision bug ( New to this release -no problems previously ) the tires on all cars do not render in 3d (everything else renders fine)

 

[DrR1pper]

Well, i tested (for 1.5 hours) the min FFB torque value using the default 60% overall effects strength in the t500 control panel and 0.8 ingame ffb multi for the megane at Mills Metro to avoid ffb clipping.

I really like it. It resolves the weakness of (or should i say non-existent) low end forces that occur during turn ins and exits of corners. Where the wheel would get loose and you'd be left sort of flapping the wheel about trying to find/judge grip, balance and confidence in the car.....no more. Solid consistency improvement through-out an entire corner (especially the slow ones!), from turn in to exit. This meant i was more than happy to keep on the power (rather than having to coast) during these situations and i was continuously receiving information through the ffb about the car's balance. Just excellent! Thank you for adding this Terence/Dev's!

There was only one negative which you predicted perfectly Terence, that is the oscillation around the wheel's equilibrium position (however it wasn't aggressive or dynamically unstable but a little annoying none the less) . In the corners, so long as i didn't change the car's balance aggressively (which is a no-no anyway) the ffb force at the wheel kept to one side from turn in to exit. This meant it didn't cross over that discontinuous point (at 0% ffb force ingame) producing a sudden change from +8% to -8% torque at the wheel. Only when driving aggressively with counter steer required (causing the ffb to flip direction in the corner) or driving down a straight could i feel the slight bump/jump change from +/-8% force at the wheel.

I think there are two main reasons for the problem. The first reason is that the deadzone amount i've calculated for my wheel (the same used for testing other wheels) measured only the forces required to overcome the static friction and not the rolling friction. Which is why when i used 8% min FFB torque, it would not oscillate if i put the wheel in a position that started from static but if i gave it a slight nudge, it was enough to then overcome the static friction and the wheel would oscillate intermittently on it's own. It's not an issue in the corners but can be felt on the straights.

The second reason is that the new response curve from adding a min ffb torque (whilst very good) is still a linear approximation. In reality the ffb wheel is producing an initial non-linear slope (in the dead zone region) that then turns into a linear line. So, i've added a little more to the equation to account for the initial non-linear slope.



Maybe this could smooth out or completely remove the slight oscillations around the 0% ffb torque?

 

[kosmo1982]

am i the only one who lost 50% of fps with this build? amd fx6100 and ati 7850. Must be something wrong with my pc. but my settings seems to be exactly the same as in previouse build.

 

[Tony]

Appreciate you taking the time, Tony.

Glad to be of help

Well I've had an automatic virus update just now from Eset, (19.15 GMT) & it seems they're as good as their word, as a new scan on the .exe was uneventful. So I recommend all Eset users to try & scan the exe again if you 've recently had an update to your virus signature

Gotta' say I'm a fan of Eset - had their software for quite a few years now & they've not missed anything - touch wood!!

 

[ForthRight]

Well, i tested (for 1.5 hours) the min FFB torque value using the default 60% overall effects strength in the t500 control panel and 0.8 ingame ffb multi for the megane at Mills Metro to avoid ffb clipping.

I really like it. It resolves the weakness of (or should i say non-existent) low end forces that occur during turn ins and exits of corners. Where the wheel would get loose and you'd be left sort of flapping the wheel about trying to find/judge grip, balance and confidence in the car.....no more. Solid consistency improvement through-out an entire corner (especially the slow ones!), from turn in to exit. This meant i was more than happy to keep on the power (rather than having to coast) during these situations and i was continuously receiving information through the ffb about the car's balance. Just excellent! Thank you for adding this Terence/Dev's!

There was only one negative which you predicted perfectly Terence, that is the oscillation around the wheel's equilibrium position (however it wasn't aggressive or dynamically unstable but a little annoying none the less) . In the corners, so long as i didn't change the car's balance aggressively (which is a no-no anyway) the ffb force at the wheel kept to one side from turn in to exit. This meant it didn't cross over that discontinuous point (at 0% ffb force ingame) producing a sudden change from +8% to -8% torque at the wheel. Only when driving aggressively with counter steer required (causing the ffb to flip direction in the corner) or driving down a straight could i feel the slight bump/jump change from +/-8% force at the wheel.

I think there are two main reasons for the problem. The first reason is that the deadzone amount i've calculated for my wheel (the same used for testing other wheels) measured only the forces required to overcome the static friction and not the rolling friction. Which is why when i used 8% min FFB torque, it would not oscillate if i put the wheel in a position that started from static but if i gave it a slight nudge, it was enough to then overcome the static friction and the wheel would oscillate intermittently on it's own. It's not an issue in the corners but can be felt on the straights.

The second reason is that the new response curve from adding a min ffb torque (whilst very good) is still a linear approximation. In reality the ffb wheel is producing an initial non-linear slope (in the dead zone region) that then turns into a linear line. So, i've added a little more to the equation to account for the initial non-linear slope.



Maybe this could smooth out or completely remove the slight oscillations around the 0% ffb torque?

I think your post was worthy of it's own thread in the Unstable forum.

You mentioned in your earlier post that T500 users should try a minimum FFB torque value of 8-10% when using 60% FFB in Control Panel. I was just wondering what you recommend if using 100% FFB in Control Panel, or is the whole point of this new setting so that we can use 60% (to remove clipping) and still remove most of the FFB deadzone?

Sorry if it's a stupid question - i'm not used to this level of technical stuff with FFB, but I'd definitely like to have the best setup for my wheel.

Thanks again for your effort in testing this stuff.

 

[88mphTim]

Glad to be of help

Well I've had an automatic virus update just now from Eset, (19.15 GMT) & it seems they're as good as their word, as a new scan on the .exe was uneventful. So I recommend all Eset users to try & scan the exe again if you 've recently had an update to your virus signature

Gotta' say I'm a fan of Eset - had their software for quite a few years now & they've not missed anything - touch wood!!

No way? Holy cow they are on it.

 

[Jamezinho]

Gotta' say I'm a fan of Eset - had their software for quite a few years now & they've not missed anything - touch wood!!

Agreed. Been using ESET for years and it's never failed me. Then again, I've got a close family member who works for them out in the US so I'm a bit biased!