Quote from Scawen :

I see you have felt under attack from me, but I'd like to mention that I have felt under attack all year so far, not from TC but generally, as most of the time I have been having to deal with people working out ever more ways to try to circumvent every rule or limit we have, to the point of causing problems with the online experience. I've had some success with that but every time I get near the end, another issue seems to come along.

One piece of advice, which may help: Try to treat it as a technical challenge to solve, not an attack against you.
Switching around the thought process may make it less burdensome, or maybe even enjoyable to come up with solutions.

Depending on how your mind works, it may or may not make a difference, but some personalities (especially in programmers/engineers) thrive on challenge.

Quote from Scawen :

I never said they had.
...
Try to keep up and please stop suggesting I've said things that I haven't.
...
I haven't thought that or suggested it any any point.

Firstly, to the above point:

Quote from Scawen :

It's an ugly thing you have created.

Quote from Scawen :

... you are recreating many ugly aspects of capitalism in a game world and supporting a license rental trade in direct contravention of our license agreement ...
... as you have allowed a fun game to shift towards real world earning instead of staying on the fun side ...

The tone and words used heavily implies that you thought we actively created a system for people to buy in-game items for real-world money, and that we knew about and facilitated account renting/sharing. Some others' use of words suggest they had similar assumptions.

Merely having a purely in-game money/trading system is normal and far from controversial (see below).

We only found out about the rental issue as a result of this thread (and/or a DM that started it, I'm not sure of the exact timeline).

Thus, given the words you and others used, it never occurred to me that the fact our system simply allows in-game item/credit trading would result in such language/statements directed against us.

------------

Quote from Scawen :

... supporting a license rental trade in direct contravention of our license agreement

For the record, [TC] have been actively enforcing the "no account sharing" part of the LFS Terms of Service for many years:

• We have actively investigated suspected shared accounts (and have a system to help track this) and permanently banned a number of accounts with sufficient evidence that they are being shared by multiple people.
  
• Our system even automatically bans accounts showing the most obvious signs of being shared.
  
• After seeing more suspicious account activity very recently, we have also implemented an additional feature to disable accounts.
  

I'd say we've gone above and beyond to help enforce LFS account sharing ToS. Enforcing this isn't our responsibility, but we have always done it where we can, to help the LFS community.

------------

Since I was not aware of [TC] "allowing" trading for [TC] money, I have asked around for clarification regarding what that actually means.

Turns out people were using our Off-Topic "Marketplace" forum area, to trade things for [TC] money. This area was intended for people to trade real world items for other real-world items and/or real money.

The only official written stance about paying for [TC] money that we can find is from a discussion in 2012: "We don't encourage or endorse it but we have no control over what people do with their money, real or game-based." Beyond this, [TC] never really decided on an official policy. It apparently was not a problem for us until very recently either. The marketplace area has been removed for now, and we are currently discussing how to deal with advertising of trades.

To be clear, our forum's Marketplace area has never been used to trade, sell, or rent, LFS accounts.


I've always personally been against selling [TC] money for cash, however historically it doesn't seem to have caused any problems. I've even heard reports today of trades resulting in a number of S3 upgrades being bought for people who genuinely couldn't afford it (no actual money changed hands, but LFS vouchers were purchased and gifted).


------------

Background:

What [TC] have is a "credit/'money'/economy based progression system", which is incredibly common on many thousands of very popular games, and many multiplayer games. It is a core mechanic of many genres of games. It goes beyond simply unlocking items at certain stages to be used infinitely, which the majority of players get bored of quite quickly (eventually, you "win" and that's the end of it). The style of progression system, as used by [TC], is normal and far from controversial.

Several of those biggest multiplayer games have implemented payments systems to facilitate purchasing of in-game items with real-world money and/or trading between users for real-world money (Valve, Rockstar, EA etc), and was wildly controversial when it started (blame EA/Valve) and continues to be so. [TC] do not do this and have never done this. As mentioned, some other cruise servers have historically (don't know about now).


To use your Monopoly example. The entire point of Monopoly is to trade money and goods. Someone wins when noone else has any money. People play it because it's fun.
Trading real money/items for Monopoly money isn't in the Monopoly rules, and it's not in [TC]'s rules either.
One difference though, is that you don't win or lose in [TC], unlike Monopoly. In fact, with the mod rental system, you don't even need to have much money to drive all the cars these days, so there's less incentive to gain money quickly other than to make a number go up.

A vanishingly small number of users trading [TC] money with real money, while we would rather they wouldn't, doesn't really make a significant impact to the economy. It certainly doesn't go as far as "unbridled capitalism that appears to be currently corrupting the server"



Within LFS, [TC] weren't the first (or even second I think) to implement a money system. As far as I'm aware, being able to send in-game money to other players has always been a standard feature with cruise InSims and not unique to [TC].

The core implementation of [TC]'s money system is practically old enough to drink. It's an industry standard gameplay mechanic. It has been refined enough so that it doesn't easily inflate to infinity and keeps people interested (mostly).
It's not a novel or controversial concept in LFS or beyond in any way.
It hasn't "caused" any issues until recently being blamed for third-parties unscrupulous activities outside the platform.

This thread started off with 20-40 compromised accounts due to people cracking LFS, and devolved into [TC] being to blame because people who were already breaking laws abused our system?

Quote from Scawen :

I have repeatedly asked why it is necessary to allow money transfer between players, but have not received an answer yet.

It's a core gameplay mechanic. It's how the world works, and has worked before capitalism or even money. Trade is the basis for all economies around the world for millennia. Money is simply a tool to standardise value, or a stand-in for trade where goods aren't appropriate. It's interesting for people and gives a reason to continue playing. That's the reason it's the basis for so many games. If people lose interest, they move on. It is incredibly difficult to come up with a continuous progression system that doesn't include some kind of economy.

------------

I'm not sure what you expect us to do at this point, other than continue to proactively ban accounts with real evidence of sharing, as we always have.

We are considering actively cracking down on advertising in our platforms to sell [TC] money, but will that actually make a difference? People have been trading for real money off-platform, or for non-TC in-game LFS currency for years. As mentioned, other (not [TC]) servers have done it officially where people could pay the server admins for in-game items/money.

I'm not sure it would be helpful to "simply" remove a standard, core feature, which has many positive uses (mentioned previously, by several people). What about blocking trading in-game cars or items? They have "value" (even if we got rid of the money system altogether). Would you require every other InSim system to do the same? It would remove a lot of genuine interactivity between community members and in my opinion (and clearly others', looking at replies to this thread) doing so would ruin a large portion of it. Where do you stop? Does it even make a significiant difference to the account sharing problem?

Removing feature(s) from one server will do little to stop people sharing accounts one way or another, as they have done for many years without needing to trade [TC] money.

------------

The crux of the matter is this: how big/widespread of a problem is this actually? How many accounts are involved? Is this even happening with accounts that haven't been hacked?

If it's known that a significant number of accounts have been hacked, industry standards suggest it would prudent to do a global reset of GAME passwords - if not WEB as well, given the evidence of password reuse. This would save you a lot of work chasing down hacks from passwords that were stolen years ago.

------------

Finally, I really don't want to say the below out loud, but this comment just hurts, given the immense time and effort [TC] as a whole has put into LFS for nearly 2 decades

Quote from Scawen :

So after all the support I've given to cruise servers and [TC], now the result is you are recreating many ugly aspects of capitalism in a game world and supporting a license rental trade in direct contravention of our license agreement.

We understand that you, Eric and Victor have given the cruising community support over the years, but please bear this in mind:

• [TC] have been directly responsible for several hundred (thousands?) of S2/S3 licenses being bought. We have had over 44000 unique players connect, since we started tracking them.
  
• We have consistently been in the top few servers and sometimes the *only* server with decent a player base during some of LFS' dark times, no small part down to the sticking power of all our game mechanics.
  
• As mentioned above, we have always - voluntarily - actively helped to enforce LFS ToS on account sharing.
  

The [TC] team have been dedicated to LFS since 2006 and this year it will be 18 years since we began.

A large number of members who were around in 2006 have replied here today, and some who have not yet replied are disappointed to read what has been said about the servers we created and all care a lot about. These members have helped provide thousands of people with entertainment for almost 2 decades.


------------

This was posted after I'd written most of the above, so I'll reply separately:

Quote from Scawen :

It's funny how may people around here are attributing me with all sorts of stuff I haven't said, and aren't reading what I have actually said.

I realise it's 2024, but there must still be a place for replying to what people actually said, instead of making up stuff you pretend they said, and arguing against that? Or is that too old-fashioned now?

Please bear in mind that, especially in text online, the choice of words and tone (which, in hindsight, may have been poorly chosen), or omitted clarification, can give the wrong impression/interpretation.

------------

While I drafted the bulk of this post, I had input from Pete, Chuck and the rest of [TC] management, and we have all been variously working on, and thinking about this all day. We are taking this issue seriously. We believe a solution can be found from the many suggestions that have already been made in this thread to make it more difficult for people to share accounts, without significantly altering core, engrained functionality in use since 2007.

What I hope is clear by now is that there are many, many people who are trying to help LFS. [TC], Sim Broadcasts, NDR, and many other teams have members who are talented developers and IT professionals who can lend some actual help to come up with solutions if you should need it e.g. TOTP-2FA as mentioned by others above.

Quote from Scawen :

Well what you have, by allowing people to buy game credits, is several things.

Just to clarify something as this seems to be getting out of hand.

TC has *never* sold in-game currency (or items) for real money. Various other cruise servers have in the past (maybe still do?), but TC hasn't.

We've always been against it on principle, but there's not really a lot we can do about it - any trading of real money for TC money is happening off-server, between individuals. I'm not sure where you got the idea that TC is doing it ourselves.

Edit:
The only way of generating TC money is by driving, or performing driving-related tasks on our servers.
There are various other transactions/events (such as fines, cars wearing and losing value) that reduces the amount of TC money in the system.
There is no way to pay to generate more TC money than is already in the system "owned" by our users.

Last edited by Degats, Sat, 24 Feb 2024 17:49.

Hmm, I hadn't actually noticed that it blocks the messages from InSim as well. Probably not possible to do what you want then :/

That's how we do it for SBTV, I think that's the only reliable way.

Quote from LuEnric :

Nice, tks Scawen. Just a question, and about the Sirocco? We still gonna have the car in futures updates?

With the physics update, yes
/offtopic

Quote from Scawen :

Are you able to reproduce this?

The crash address points to loading an integer from a file, so not much to go on at this point.

I can't reproduce it by loading a test mod (with popup headlights) driving on another track then loading RO3. I wonder if you can do it again.

It hasn't done it again. It loaded RO3 straight away right after it crashed and I've just tried going from the same track to track combination I did last night (same mod revision I think) with no issue.

Hard crash immediately when loading RO3 in single player, with a test mod selected (which should have already been loaded from driving on another track seconds before)

Any chance you could delay closing by at least half a second when the lights turn off?
Most cars with pop-ups have a delay to save wear on the motors in case you flash more than once.

Also makes flashing lights weird:

You should never need to run anything to do with LFS as admin, unless you installed it somewhere where a normal user doesn't have write access (eg Program Files).

Quote from Gutholz :

Another option is to record your own racing line.
Just record the coordinates over a few laps and eventually you will have enough data. If LFS's path node system is not accurate for your needs, then you can make your own system.
The advantage would be that it works on custom configs, too.

This is pretty much what the LFS pth files are, it's a reference lap with nodes/lines saved at regular intervals (with additional geometry that isn't required for deltas).

For each lap you care about: save the position, direction, speed, and time since the start of the lap in whatever interval is useful. Compare that reference lap against the current lap/latest IS_MCI data and you can calculate the delta.

I can't remember exactly what the calculations are and I haven't got time to dig into it at the moment, but it uses a combination of speed and position of all cars from InSim, and measuring distances from the .pth node lines which are used as references.

LFS limitations for Simbroadcasts usage are mostly described here https://www.lfs.net/forum/post/2056282#post2056282. I don't think they're show stoppers, just make for more edge cases and added complexity that I will need to deal with.
I don't think they'd stop you from recreating LFS Lazy type stuff though.

You can use the .pth files in data\smx for the approx racing line.

I have a WIP live delta implemented for Simbroadcasts, though it needs work to be robust enough for our uses (I mentioned this in the other thread that asked about deltas).

All the data needed to do personal live deltas is available in InSim + .pth files.

Quote from Scawen :

... if a car has daytime running lights, does that mean it doesn't have a "sidelights" option on the headlights switch (traditionally have three settings: off, sidelights, headlights) is their headlights simply off / on / auto?

Yes, DRLs have a sidelights switch (for LED ones anyway):
DRL: Front only (except Scandinavia where they also have taillights); bright enough to outshine the sun
Sidelights: Dim front to not blind people when it's darker + taillights.
Headlights: Normally still have DRL on in dim mode in addition to dipped/full beam.

Auto lights usually have the above plus an auto position.

(Not suggestions, just an FYI 😉).

Quote from Marty_Deslions :

Hey Scawen, could you also add to the interface the "Lights: off/side/low/high" message when the player does the /light head next command? Now it appears when you manually press SHIFT+3, but not when you run the /light head next command.

Does /shift 3 show the message?
If it does, that's an alternative to /light head next if you want the message

Quote from Flame CZE :

The DashLights and ShowLights properties of OutGaugePack will need to be updated at some point to include all the new light features.


enum
{
DL_SHIFT, // bit 0 - shift light
DL_FULLBEAM, // bit 1 - full beam
DL_HANDBRAKE, // bit 2 - handbrake
DL_PITSPEED, // bit 3 - pit speed limiter
DL_TC, // bit 4 - TC active or switched off
DL_SIGNAL_L, // bit 5 - left turn signal
DL_SIGNAL_R, // bit 6 - right turn signal
DL_SIGNAL_ANY, // bit 7 - shared turn signal
DL_OILWARN, // bit 8 - oil pressure warning
DL_BATTERY, // bit 9 - battery warning
DL_ABS, // bit 10 - ABS active or switched off
DL_SPARE, // bit 11
DL_NUM
};

But the packet doesn't seem to have much spare bytes to use

It already has been (see insim.txt in the patch).
The bitmask is 32bits, so will take some filling up, it's just over half used with the new lights.

Quote from Scawen :

Quick poll:

Dipped / Full Beam or Low Beam / High Beam

FWIW, my car's manual alternates between dipped and low, and calls the other one "main"

Quote from KingOfIce :

Hello Scawen,
are you considering adding the new 7D information "engine damage" to insim (more globally, perhaps a new "damage" or "car condition" package with clutch slip, bodywork, suspensions, etc.)?

Yeah, I was also thinking during the race on Thurs that separating engine damage to a separate InSim repair flag would be useful (though I imagine that would also involve changing it to a unique damage type as well rather than generic, which I assume was done to make implementation simpler?).

Not sure if this is relevant as I was on D42, but I just had a hard crash to desktop while joining a server with lots of mods.
I not sure exactly where in the sequence it was as I wasn't really paying attention, but LFS had to download a lot of mods when I restarted and connected again so must have been soon after clicking join.

FWIW, I have a real-time delta feature mostly implemented (but not enabled) in the Sim Broadcasts InSim. It can be quite accurate (tested down to at least 1ms from a replay) with some limitations and caveats (see below).

It uses a combination of the LFS .pth files (or compatible custom ones that I make as needed for custom configs and entirely new layouts) and car position & speed from MCI packets.

A note for those who are not aware, LFS "nodes" actually refer to lines which are described in the pth files, drawn to the left and right of direction vectors with coordinates (nodes) which make up an approximate racing line.


I haven't fully finished the feature yet, as we intend to use it for more accurate reporting of the race order, and there are a few problems/limitations that raise some tricky edge-cases when needing to implement a seperate timing system. We need this for a couple of reasons:

1. LFS has a "bug" where if two cars are close enough to eachother to be within the same node, LFS might show the cars in the wrong order (I believe it sorts them by PLID or something) causing the positions to flip around a lot when they physically aren't overtaking eachother.
   
2. In custom configs, we only get position changes from LFS at sector lines, which can get confusing for commentary.
   

So, to the limitations (may only be a significant problem for Sim Broadcasts'/T&S use, but they're why I haven't yet finished the feature):

1. The car positions from MSI packets are not always accurate. I need to do some proper testing, but I believe it may be significantly worse when running on a server (though it may be just as bad on the client, TBC). This comes from the fact that MCI packets aren't sent in-line with position packets sent client <-> server within LFS. MCI packets are sent at regular intervals, whereas the internal packets are variable rate. This means that the MCI positions are relying on the LFS prediction, which obviously can't always be correct. Under most condititions, this doesn't cause a major issue, but in cases of severe lag (especially combined with fast control inputs) or heavy collisions into walls etc, the positions can end up being quite wrong for one or more packets.
   
2. In default configs (and most custom pth files), the Start/Finish line (and maybe sector lines?) don't neccesarily match a node. It is often halfway between two nodes, which can be several metres away. There is also no way for InSim to find out exactly where the S/F or sector lines are with default configs, though they can be read from the layout for open config. This may not be a problem when calculating deltas to another car (the purpose of this thread I guess), but does throw a spanner in the works for a custom timing & scoring system (which is Sim Broadcasts' main use) or for calculating more accurate split times than 100th of a second.
   
3. InSim does not know when the actual start of the race happens, or (mostly for custom layouts) the correct order of cars at the moment the race starts. The initial REO isn't neccesarily the final starting order because of cars joining late/spectating. It's possible the REO gets updated later, but I've not yet tested that. This means that you can't reliably start calculating deltas until a car has crossed a split (or potentially some other line, but that would need to be configured per layout).
   

Now, the above may not be a problem if all you need is a mostly correct delta, don't mind not having data till crossing a sector line and can work around some other edge cases. It makes my uses quite a bit more complicated though

Vehicle mod: XF GTI LIGHTBAR
Details page: https://www.lfs.net/files/vehmods/1432AA

SHORT DESCRIPTION:

Quote :

XF GTI with Lightbar

DESCRIPTION:

Quote :

Stock XFG with Lightbar, various marker lights & separated tail/brake lights

Configurations:

• Amber lights
  
• Blue lights
  

COVER SCREENSHOT:

I've raised the rev limiter on the latest version, so auto gearbox should now work properly.

#8

Quote from Scawen :

When practising for tyre changes, I was pressing a controller button I had assigned to run a script with /pitins commands. But I found myself looking in the chat to see the lines "ftyre super" and "rtyre super" confirmed after clicking the button. But I got confused when I couldn't see them. It turns out that because I had F12 open the messages are not displayed (as designed). But to avoid confusion in the heat of the moment, I think I should make the result of /pitins and /liveset visible in the chat regardless of F11 or F12 menus being visible. Any objections?

Quote from three_jump :

Sounds like a reasonable idea.

That actually gets me thinking...
In combination with multiple commands (per line or script) it might also be useful to be able to assign a name (or just use the script name). So instead of having muliple returns in the chat you would get something like "pitconfirm: wet".

Prefacing with the fact that I've not played with the new /pitins commands myself yet, but I imagine if it's confirming every setting in a script the chat may get a bit spammy?

If you want to confirm you ran the correct script, you can always add an /echo command to the end of the script - perhaps with coloured text to add clarity.

For qualifying the option to enforce HLVC, where a fail means the laptime gets deleted, would probably be the simplest solution - though that would involve fixing the HLVC bugs, if they still exist, and presumably wouldn't help for open configs - maybe having checkpoint/circle objects that can trigger HLVC fail would work there.
I suppose a time-penalty option would be needed for one-shot quali.

For races, I like the idea of being able to set somewhat arbitrary time penalties, to be served either at the next pitstop or by a race time adjustment (F1 rules).

However, I'm really not a fan of instant off-track/cut penalties during races as it's often not fair. When racing in close quarters with others, you could end up running afoul of it through no fault of your own and/or without gaining an advantage.
This is usually handled IRL by having a number of strikes where you can trigger a cut timing line x number of times before gaining a penalty. In endurance races, this is usually defined as x per hour.


tl;dr for some "easy" (hah!) wins:

1. Arbitrary time penalties.
   - a) Race: issued by admin/InSim for served at stop/race time. (HLVC is too strict for this, we're not MSV I hope)
   - b) Quali: issued by admin/InSim/HLVC.
   
2. Option to have HLVC delete a lap or add time penalty in quali
   
3. Control objects to trigger HLVC (behaviour as #2)
   

For racing, I think there are so many variables, it may be too complicated for LFS to have a good general solution. InSim preferred IMO (helped by 1. above).
An x strikes system based on race length *may* be doable without settings getting out of hand, but I'm not sure how useful it would be without built-in less-strict-than-HLVC detections.