Jump to content

DEVBLOG: PANACEA LUA CHANGES - discussion thread


NQ-Wanderer

Recommended Posts

1 hour ago, NQ-Ligo said:

. In this case, please let us know @Archaegeo . We would rather "secure"/"censor" the data on the lgos, than have to remove them completely. Of course, I can't guarantee that in the future this will be assured, if it becomes unavoidable we will get to that point. But that is not our goal.

 

The issue is parsing the log to do outside things, aka notify on discord or via text message etc.

 

If you intend for the log to be readable for some purposes, I would recommend a randomized delay before the log gets written so it cant be utilized for instant notification of in game events.

 

Example from log: 

<record>
<date>2022-01-17T19:48:50Z</date>
<millis>1642450010131</millis>
<sequence>18617</sequence>
<logger>D:\Bamboo1\xml-data\build-dir\WC-REL21114-CSTS\Source\game\scripting\DPUnit.cpp:212</logger>
<level>WARNING</level>
<class>WC-REL21114-CSTS.game.scripting</class>
<method>NQ::DP::Unit::execute</method>
<thread>21872</thread>
<message>Executing a Lua method in the wrong thread. method='setAxisCommandValue', inFlush=true, method is Flush compatible:false, method is Update compatible:true</message>
</record>

The above occurs whenever a method is done in flush that isnt allowed.  If i was nefarious, i would do that intentionally and log parse for it for my nefarious notifications

Link to comment
Share on other sites

4 minutes ago, NQ-Deckard said:

We are never out to hurt anyone, however we do have to protect the security of the game.

That is not what I am saying here and, as I mentioned, I understand the reasoning behind the change, even when I expect it will not be very effective in addressing the reason for it

 

 

4 minutes ago, NQ-Deckard said:

On top of which, what you're describing above is very much not in accordance with the EULA and will see you get into trouble for it.

Besides NQ not having any way to know or detect whether such a solution is used, it is really not relvant whether it is against EULA actually in that regard. Mind you, while I know this can be done and how, I have no interest in this at all, I am pretty sure though that the audience these changes are aimed at do as well and will use it the moment this is pushed through so the change effectively is nullified instantly.


 

4 minutes ago, NQ-Deckard said:

There are a number of other concerns, such as the ability to write directly to a players hard drive through the logs. Which is one of the primary concerns about the logging functions.

While that is a fair argument, IMO that should, on the occasion it is seen and reported, be dealt with outside of the game, As in, you spam people's logs, you are warned, then banned. What you describe is actually a violation of EULA and as such perfectly actionable.

 

 

4 minutes ago, NQ-Deckard said:

We have also been very clear about this from day one when players found this function. We were not enforcing it, but it was never a "feature", and never included in the codex. I have mentioned on multiple occasions in multiple locations that the logging functions would likely one day be redacted but we would observe what came from them in the meantime.

Yes, I get that, however what you are effectively doing is actually discouraging emergent gameplay in removing things that enrich the game for many because it may offer opportunity to exploit or otherwise harass for some. As I mentioned, baby and bathwater.

 

 

4 minutes ago, NQ-Deckard said:

As such, the audio feature is being developed to provide a suitable replacement for the community created audio framework.

And I certainly appreciate this consideration 

 

 

To be honest here though, the solution really is not this, the solution woudl be an API exposed to players and available to use and build your own toolset or offer public services to the community as a whole. As NQ, you control what is exposed AND get data about who used what and when. Data which you can then correlate against actions by the same player(s) in game to track and manage potential abuse.

 

We know the game has an API framework in place, we had access during the start of Beta before NQ closed it. It would be great to see NQ build on that and offer it as a means for us to enrich the game as a whole with a relative small investment from the side of NQ.
 

Link to comment
Share on other sites

Funny thing is, both me, @Archaegeo and @blazemonger are showing a few examples of how this whole "disabling writing to logs" could be nullified, even though against the EULA. Truth is, even though we won't do it ourselves, whoever plays DU for exploits and profits is probably already doing it in some way, and both don't care and definitely won't be saying out loud and pointing out to the devs.

 

My overall view on this thing is, if NQ really wants to push for the emergent gameplay they keep claiming for, where PLAYERS CREATE THINGS, they will either eventually have to deal with people exploiting (either by improving their anti-cheat or giving their GMs ways to see what's going on the player's client, whatever) or just close down all the creative parts of the game and make it something sterile like Star Citizen, at least you don't have to worry about players misusing Lua.

 

We can keep going forever on this subject too:

- Removing log writing for legit players means they might not be able to do some cool stuff, like external UIs to show ship stats, while exploiters will probably use QR/bar codes + OCR to keep exploiting

- Then you DRM the whole game client, pixels aren't accessible anymore, legit players and streamers can't capture or stream the game, exploiters might use the QR code from previous point and just point a webcam to the screen

- Then you go full on crazy, render the whole screen as a black screen, no info, nothing - congrats, there's no game!

 

Also, I'd like to point out the big issue here isn't even outputting stuff from Lua into the computer. Like, that data is already all available to players with Lua anyways, they will eventually find a way to output it in an automated way. The big issue is players being able to input data to the game client, via virtual keyboard/mouse input. Sure, doing so would kill some stuff like Joy2Key and AutoHotKey, but is probably the most guaranteed way to stop botting.

Link to comment
Share on other sites

2 hours ago, NQ-Ligo said:

However, it is possible that some of the information may not have been considered dangerous at first sight.

 

I'd like to remind people that even innocent-seeming data can be an issue with regulation.  

 

Laws like GDPR are very clear, and this was discussed a long, long way back...but even something very simple like logging a "Player ID" is absolutely an issue with GDPR.

 

The law doesn't care if an ID is anonymous -- any ID that is unique per person is protected data. That's what the law plainly says. That's why your IP address is considered protected under GDPR -- it can't identify you as a person, but can still be used to track you as a person. With no way to opt out, NQ is/was absolutely not compliant with GDPR laws. 

 

So...in this one situation, give NQ a bit of a break. Giving players robust tools while also complying with legal requirements isn't as simple as it might seem. 

 

(Please do more than 5 minutes of research on GDPR if you believe player IDs aren't covered as an identifier -- there's ample plainly worded articles discussing what counts as an identifier)

Link to comment
Share on other sites

Logging was/is CRITICAL to my development of an enhanced flight script.
It allowed gathering information essential to understanding how physics in DU work (e.g. air density vs altitude, engine thrust vs. air density, the coefficient of drag etc.). 

It permitted me to identify (and report) BUGS. E.g. the time when the API (correctly) reported the construct mass sans nanopack mass, but the physics engine was including the nanopack content mass (which caused the ship to crash I might add).

So to maintain and improve the flight script I log once a second vital flight information (think of it as my BLACK BOX). Removing this capability is  unconscionable, as will become clear as time (and code changes) will prove.

Link to comment
Share on other sites

24 minutes ago, blundertwink said:

 

I'd like to remind people that even innocent-seeming data can be an issue with regulation.  

 

Laws like GDPR are very clear, and this was discussed a long, long way back...but even something very simple like logging a "Player ID" is absolutely an issue with GDPR.

 

The law doesn't care if an ID is anonymous -- any ID that is unique per person is protected data. That's what the law plainly says. That's why your IP address is considered protected under GDPR -- it can't identify you as a person, but can still be used to track you as a person. With no way to opt out, NQ is/was absolutely not compliant with GDPR laws. 

 

So...in this one situation, give NQ a bit of a break. Giving players robust tools while also complying with legal requirements isn't as simple as it might seem. 

 

(Please do more than 5 minutes of research on GDPR if you believe player IDs aren't covered as an identifier -- there's ample plainly worded articles discussing what counts as an identifier)

 

If NQ wanted to be 100% GDPR compliant the changes would do minimal if any change. Take for example the "Birds" people used to place on markets that tracked what players got close to them, they did that by combining Detection Zones with Lua's function to get the master player's ID (the ID currently running the unit) and saved it into a databank, probably. If NQ really wanted to prevent this sort of issue they would have limited that function to only ever return the player ID if they ran the PB directly, instead of being able to do it when running indirectly (via DZ, button, etc).

Link to comment
Share on other sites

7 minutes ago, Wolfram said:

 

If NQ wanted to be 100% GDPR compliant the changes would do minimal if any change. Take for example the "Birds" people used to place on markets that tracked what players got close to them, they did that by combining Detection Zones with Lua's function to get the master player's ID (the ID currently running the unit) and saved it into a databank, probably. If NQ really wanted to prevent this sort of issue they would have limited that function to only ever return the player ID if they ran the PB directly, instead of being able to do it when running indirectly (via DZ, button, etc).

 

I mean... By that argument... wouldn't just seeing people's names around you also be breaching that? If a player ID is a problem, surely a unique name is as well? I will admit I haven't read up on the law in question, but it just seems like a weird argument that an MMO shouldn't allow players to know... that other players also play the game? I can't imagine the game would function if we were never allowed to know that particular people exist in the game world with us.

Link to comment
Share on other sites

1 hour ago, blundertwink said:

Laws like GDPR are very clear, and this was discussed a long, long way back...but even something very simple like logging a "Player ID" is absolutely an issue with GDPR.


Except it is not a playerID, it is a characterID and those are two very different things

 

If the ID can be used to identify a real person then yes. If the ID only identifies the in-game character then no.

 

As far as I know the ID you see in game has no accessible link to a player account. Yes, NQ will be able to make that connection outsid of the game, but as soon as the login servers pass you on to the game servers, your player identity goes away and all that is there is the character which is not protected under GDPR as the character itself does not allow you to link it back to the account and the player behind it. I'm pretty sure that was actually the reason that they changed the login from the charactername to the email address at some point.

 

Defiinition:

Quote

The EU’s GDPR only applies to personal data, which is any piece of information that relates to an identifiable person. It’s crucial for any business with EU consumers to understand this concept for GDPR compliance.

 

And also
 

Quote

‘Personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

 

SOURCE

 

 

By this definition the characterID in a game is not protected under GDPR as it does not relate to a natural person, it relates to a fictional character and you are not able to connect the ID with a natural person.


But we're getting off topic here ;)

Link to comment
Share on other sites

Quote

Yes, NQ will be able to make that connection outsid of the game, but as soon as the login servers pass you on to the game servers, your player identity goes away

 

The fact that the character ID doesn't directly relate to a player is immaterial, it's still a unique ID that can be used to directly or indirectly identify a human being. There's ample writings describing unique IDs and natural persons according to GDPR's definitions...it isn't so simplistic. 

 

Let's pretend DU isn't a game, but an e-commerce website. It creates fictional avatars for everyone -- and tracks them by an avatar ID. Would any court accept the idea that you aren't tracking a real person, but a fictional character...? Obviously not. They wouldn't treat a game much differently. 

 

The reality is that GDPR (okay and laws in general) aren't straightforward and objective -- there's huge grey areas, like about what "reasonable" means in the context of indirect identification.

 

That's my whole point about bringing up GDPR...it can be involved and complex, and there's a big difference between "we're 99% sure we're in compliance" and a real lawyer signing off. 

 

1 hour ago, blazemonger said:

But we're getting off topic here ;)

 

Well, agreed...wait, since when do we care about topics...? I thought every thread was an opportunity to talk about PvP? 

Link to comment
Share on other sites

This is long overdue imo.  While some people might find ways around it, with the functionality 'removed', those people can be banned for their actions.  While many may keep their scripts private, the most problematic example of a nefarious script is one that transmits data between players - requiring trust of two or more players, that neither reports the other.  Orgs that use these sorts of scripts either have to never recruit people again, or be very careful about it, and even an old veteran who got mad at the game and org could report the org, getting all members banned

 

Risking a ban of an account that you've invested so much time into hardly seems worth it, and as a whole, very few people are willing to use bannable exploits, compared to the number of people willing to use vague grey area tools

 

Also, most workarounds mentioned are very detectable.  Anything that uses the lua, such as drawing QR codes or logging via invalid flush calls, is pretty obvious if NQ were to receive a report and check the lua on a player's control units - and might could even be detected automatically in some cases.  

 

 

 

Otherwise, very few legitimate uses will be impacted.  The logfiles themselves will still contain things like market data or MU data by the sound of it.  Something like physics data collection, or item/recipe data, can log to a string and into a screen instead, to be copied out on a case by case basis.  Logging from lua script to file every tick is no longer possible - but shouldn't be, because that results in some very inflated logfiles that can cause slowdowns for users in some cases, and if done maliciously, could result in filling up a user's entire disk.  Logging to a screen or databank would be more appropriate

 

 

 

I do agree with Arch, though; this is only one step in the right direction.  The logging as a whole needs to be trimmed drastically - they are massive, tend to have many meaningless lines that occur every tick with the same data, and a lot of the things logged can likely provide info that you wouldn't want people to extract from DU.  I think the best strategy isn't to make a list of things to remove from the logs; instead, make a list of things that actually should go there, and remove everything else

Link to comment
Share on other sites

very nice changes

 

as already mentioned please center camera position on command seats to allow easier and symetrical custom user interfaces ( huds) - probably easier to push this to the 3d design team responsible for the character animations.

 

also very much appreciate the removal of log writing per ingame LUA

any player controllable ingame feature should never be allowed to write data to the physical ( real world) drives, especially if these can be invoked by other players without notice! -> security first!

the issues to read game data from screen instead of file for exploiting are not really relevant for this decision as the intention is ( as i understand) to protect the computer system running the game and not prevent cheating, the exploiter will alway find a way...

that beeing said, non harming content created with this will need replacecement features and you already started adding these regarding the sound, please continue to do so with the other cases mentioned here!

 

also nice to see you interact with us in this thread more. keep it up and work with the feedback in a transparent way!

 

 

 

Link to comment
Share on other sites

There are already some ship related sounds in game like `Shield activated` and so on.
I would suggest moving them to the audio folder and use your new audio framework to call those sounds from default script.
Or at least the ability to disable the default ship voice sounds.
This would allow us to make fully customizable "Ship Voice Assistants".

Link to comment
Share on other sites

7 hours ago, antanox said:

very nice changes

 

as already mentioned please center camera position on command seats to allow easier and symetrical custom user interfaces ( huds) - probably easier to push this to the 3d design team responsible for the character animations.

 

The camera view is technically in line with what you see in the seat IIRC. It definitely is a pain though, but there are simple ways to counter it to have the HUD "symmetrical" for the player in the seat.

Link to comment
Share on other sites

Quote

However, we will see with the team if a better solution is possible, there is no perfect solutions currently.

 

I really hope there will be a good solution for data export.

Several projects in the community depend on that.

 

We in our org built in months of work a whole own economy system.

Members can store their ores in our ore deposit, they get "HC" (our own currency) in exchange, and can use these HC in the fully automated shopping center to buy nearly any item for a cheap and steady price (what is important especially for new players). Our players can transfer their HC to other members, or can use them to order something from our industry department (if its not in the shopping center, or a really large order). This system works well and is a great addition and an advanced community creation. (If you are interested, check this video: Hyperion Warehouse and HC-System it's German and not 100% up to date, but you can understand most of the content just with the visuals)

 

And there are many more complex systems like this from other orgs and players, that rely on sync with external databases, because the DBs in the game are too small to handle this.

 

All of these advanced scripted community creations would be lost if there is no proper and easy way to export the data anymore.

If we are restricted to just the ingame DBs, this will kill massive creativity in scripting because of the limitations.

Hyperion_HC_System.png

Link to comment
Share on other sites

20 hours ago, blazemonger said:


Except it is not a playerID, it is a characterID and those are two very different things

 

If the ID can be used to identify a real person then yes. If the ID only identifies the in-game character then no.

 

 

A lot of people misunderstand the GDPR like this.  There doesn't have to be a way to map the ID back to a person in order for it to be personally identifying information.  It only has to be true that there is only one real human who would be generating that particular piece of information.

So if the EULA says one character is only allowed to be played by one human then the character ID is personally identifiable information even if there isn't a way to map it back to the specific human.

A credit card number, for example, is personally identifiable information.  I have no way to get the owner's name, address, etc from that credit card, but the card number is only supposed to be used by one person so it's personally identifiable.

Link to comment
Share on other sites

3 hours ago, Hachiro said:

 

I really hope there will be a good solution for data export.

Several projects in the community depend on that.

 

We in our org built in months of work a whole own economy system.

Members can store their ores in our ore deposit, they get "HC" (our own currency) in exchange, and can use these HC in the fully automated shopping center to buy nearly any item for a cheap and steady price (what is important especially for new players). Our players can transfer their HC to other members, or can use them to order something from our industry department (if its not in the shopping center, or a really large order). This system works well and is a great addition and an advanced community creation. (If you are interested, check this video: Hyperion Warehouse and HC-System it's German and not 100% up to date, but you can understand most of the content just with the visuals)

 

And there are many more complex systems like this from other orgs and players, that rely on sync with external databases, because the DBs in the game are too small to handle this.

 

All of these advanced scripted community creations would be lost if there is no proper and easy way to export the data anymore.

If we are restricted to just the ingame DBs, this will kill massive creativity in scripting because of the limitations.

 

I do understand your concerns, but I'd like to reaffirm that we've been very clear about the logs not being a feature and these options potentially being removed at a later date.

 

We are not opposed to players creating wonderful digital creations that work wonders with the game, however backchanneling that data through the games logs using in some cases closed source third party created software to then transfer that to databases stored online with who-knows-what data its collecting is not the right way to create this and that concerns us.

 

None of this means that we don't see the use cases of an API or similar data export options, and we don't know when or how yet. But it's something we can look into in the future.

 

For now however, data exportation will in most cases need to be done via screen units on demand if desired.

 

- Deckard

Link to comment
Share on other sites

40 minutes ago, NQ-Deckard said:

 

I do understand your concerns, but I'd like to reaffirm that we've been very clear about the logs not being a feature and these options potentially being removed at a later date.

 

We are not opposed to players creating wonderful digital creations that work wonders with the game, however backchanneling that data through the games logs using in some cases closed source third party created software to then transfer that to databases stored online with who-knows-what data its collecting is not the right way to create this and that concerns us.

 

None of this means that we don't see the use cases of an API or similar data export options, and we don't know when or how yet. But it's something we can look into in the future.

 

For now however, data exportation will in most cases need to be done via screen units on demand if desired.

 

- Deckard

You are going to hurt script development. Logging is essential. I understand your concern about using logs in real-time, but limit it to that.  Preventing logging completely is not your option.

- Linking screens is not easy for non-developers. You are hurting our ability to support others. You should also understand that usually accessing logs happen post-mortem - after something strange happened. Setting up screens is then too late. Links are also very scarce resource.

- You can lock logfiles exclusively with deny-read. This prevents other processes reading logs in real-time but they will be available after game is closed. This is one-liner fix and safe.

- Implementing copy to clipboard from Lua chat is easy and safe. But if this is only option, the stored log must be longer than now.

 

This is the end of discussion from my part. If you decide to cripple script development, i'll just move on elsewhere.

Link to comment
Share on other sites

13 hours ago, Hachiro said:

whole own economy system.

If I understand correctly, you need the ability to create custom currency in game to be able to handle that without external DB?
I would really love to see custom currencies in DU, this will add so much to "civ building" aspect of the game.

Link to comment
Share on other sites

This is a recurring trend.

Since is MUCH quicker and easier to remove then it is to create, it seem this is preferred solution to most NQ actions these days.

So my advice to NQ would be this. Each time you remove something players actively use in-game, make sure you have an adequate replacement solution ready beforehand.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...