Jump to content

DEVBLOG: PANACEA LUA CHANGES - discussion thread


NQ-Wanderer

Recommended Posts

Since the log function has been removed, there is no longer a way to copy text from within the game. So it would be nice if there was another possibility, e.g. to copy and paste in the LUA chat window or a edit contant button for the database in order to use this item to get text in and out.

Edited by Ashford
Link to comment
Share on other sites

Hello, and first off, thank you, thank you, thank you. 

Not only did you add camera read data, you also are adding sound support. Removal of the log stuff scared me for a second, but then I released it was only those methods that got removed, not the actual logs. I think that is perfectly fine now that you've added support for sound playing. Though, I'm sure many people will come out of the wood work to complain now that it's planned to be removed.

However, what I wanted to say was the camera API could also be expanded in future. We only have read data, which is really good, but when someone brought it up in the post the other day, I actually started to realise it could be so much better as well.

The idea is to give, at least, very limited control over the camera, or even better, full control over look direction. Here me out on this one.
 

Quote

Right now, the camera movements aren't that natural, they're immediate and very gamey, but at least with minimal control we can smooth out movements to be more natural, add things like negating headbob, or add jerking when a ship experiences high Gs. Maybe even allowing us to program basic "cinematic" camera movements for a slow and constant pan, or a smooth one.

I'm sure it wouldn't be easy to prevent some smart people from exploiting this, or even easy to implement it at all, but it would certainly allow us to add QoL features you otherwise don't have the resources/priority at this time to do.

This is what I said before on the general discussion, but I wanted to add an addition detail I realised after I posted this. With the ability to control the camera, you can fix the very annoying issue for AR, and that is that it will always be one frame delayed. The simple reason is, you have control over camera data and the camera data you send will need to be used for the next frame, not the current one, exactly like AR. Thus, AR jerkiness is eliminated because the data is in sync.

That is all I wanted to add to my previous post, but maybe someone else here can expand on what I've said with their own thoughts... making cinematic cameras through Lua could really help with RP videos... so yeah...

@NQ-Ligo, I hope to see what you say with all of this, if there is some security concerns/exploit concerns... I think camera movement would be difficult to protect, but if you can control it such that it has a range of movement it cannot exceed, it can probably be solved.

Edited by EasternGamer
Accidentally pressed enter too early.
Link to comment
Share on other sites

I have extensive debug log in my flight script and removal of logging would really hurt. There must be an alternative to extract a debug log. What i have now is that debug logging writes to system log lines with special characters to frame the lines and then a powershell script extracts the lines and imports into VSCode.

 

Suggestion: the Lua log chat tab should allow to copy it to clipboard. It should contain full log of a session - not truncate it as now. The log may grow to megabytes.

Link to comment
Share on other sites

Side Note:  Removal of lua logging will not stop people reading the logs and using things written to do stuff.

 

If logs exist, and they record things like a core turning on and off, or any producable event in game, the log can still be used for nefarious purposes.

Link to comment
Share on other sites

Though I understand why the logging info issue had to be fixed, as someone constantly working with Lua and even building tools for it, I agree with the other players who requested some way to copy data from the game, be it JSON or anything. Even something as simple as being able to copy things from the Lua chat or to show a message box with a button to copy to clipboard would be enough.

 

This isn't just because of exporting things, but even for bug or error reporting, an user being able to copy a message from the Lua chat or some message box and send it to the developer would help a lot when debugging things.

Link to comment
Share on other sites

13 minutes ago, Sawafa said:

@Helediron @Ashford

Just connect screen to the control unit and use screen.setHTML(logtext). Then edit the screen and u will be able to copypaste info.

 

That's a hack but well, it's an option nonetheless. I still think that NQ should provide players with ways on doing things correctly instead of just retreating because a few will use for exploiting. Lua should NOT be able to write to log when not run directly, but it should be an option anyways.

 

 

12 minutes ago, Archaegeo said:

Side Note:  Removal of lua logging will not stop people reading the logs and using things written to do stuff.

 

If logs exist, and they record things like a core turning on and off, or any producable event in game, the log can still be used for nefarious purposes.

 

And yes I have to agree with that. Also, people extracting data from DU (including with malicious intents) will find a way or another, maybe using SVG to render quares on the screen and export data using that? It's possible. What NQ gonna do, remove SVG and Render Scripts altogether?

 

Also, I still think the biggest issue isn't even being able to write logs, but actually send input to the game, be it using AutoHotKey or Lua require (both of which seem to be allowed, as stated here). If NQ can't detect and fix that sort of thing, they are pretty much ignoring the big issue of botting and just removing something that had a ton of use cases and actually depends on the former to be useful to bot.

Edited by Wolfram
Link to comment
Share on other sites

Hi all!

I will try to answer your first questions. Don't worry, I'll do some more passes tomorrow. ;) 

No possibility to copy content out of the game? @Ashford @Helediron@Wolfram

52 minutes ago, Ashford said:

Since the log function has been removed, there is no longer a way to copy text from within the game. So it would be nice if there was another possibility, e.g. to copy and paste in the LUA chat window or a edit contant button for the database in order to use this item to get text in and out.

We know that these log functions are used by some people legitimately to get data out of the game, but it has never been the only way to copy data. But it was the only way to get data directly out of the game automatically.

In your case, you can use a screen and log on it. Currently you still have setHTML which will allow you to write very easily on it, without even worrying about the number of characters if your goal is just to copy the data out of the game at the end. You write your log in it, once finished you edit the content of the writing and copy the whole content.


I know that many players will express their concern at the removal of these log functions, even if their use was legitimate. However, it is important to understand that this is a decision that was made after much consideration and the balance was quickly tipped in favour of total removal. And any suggestion such as adding a Lua-only log file or segmentation of the logs, does not solve the problems as automation or drive overload. And even the fact it's executed explicitly only, it do not prevent automations and some exploits and leaks.

I'm not sure either that being able to select the Lua chat and copy it is a solution either, or even more practical than a screen anyway. 

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

On a personal note this time, I would suggest adding to your systems to allow your users or you, the developer, to connect a screen that serves as a console.
A bit like you do with a car, it's a closed system, a black box, but it can provide us with controller or error data through their control port.


What about reading the log ?

We see the logs as a tool for community projects, such as an external community market platform, so we want to keep the logs as accessible and readable as possible.
 

Therefore, we try to remove sensitive information from them as we did in the case of Market Orders. However, it is possible that some of the information may not have been considered dangerous at first sight. 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.



More possibilities for the game camera? @EasternGamer

50 minutes ago, EasternGamer said:

@NQ-Ligo, I hope to see what you say with all of this, if there is some security concerns/exploit concerns... I think camera movement would be difficult to protect, but if you can control it such that it has a range of movement it cannot exceed, it can probably be solved.

First of all, thank you for your topic, I have read it and it is interesting.

It's the kind of thing we could consider in the potential future, but as you said it can be complex and even more so to secure it. I'd like to say that I'm looking forward to seeing what you do with it and see what we can do or not.

Thank you for these suggestions though, they are complex suggestions, so it's hard to say whether or not this is something we could or would want to do right now.


Sound API, missing volume control. @Archaegeo

29 minutes ago, Archaegeo said:

system.soundVolume() is needed to go with play and stop so that the play volume can be less than game volume.

Indeed, this is something that is currently missing. The volume of the sound played will only depend on its base amplitude and the audio settings of the game.
This is something we'd like to add, but to be honest, it requires some deep changes to be done.

Anyway, as mentioned in the devblog, this is a first iteration that may evolve in the future.


I hope that these answers will help you all the same and help you to understand the situation on the logs, on some aspects, they are globally complex subjects.

Link to comment
Share on other sites

1 hour ago, EasternGamer said:

Hello, and first off, thank you, thank you, thank you. 

Not only did you add camera read data, you also are adding sound support. Removal of the log stuff scared me for a second, but then I released it was only those methods that got removed, not the actual logs. I think that is perfectly fine now that you've added support for sound playing. Though, I'm sure many people will come out of the wood work to complain now that it's planned to be removed.

However, what I wanted to say was the camera API could also be expanded in future. We only have read data, which is really good, but when someone brought it up in the post the other day, I actually started to realise it could be so much better as well.

The idea is to give, at least, very limited control over the camera, or even better, full control over look direction. Here me out on this one.
 

This is what I said before on the general discussion, but I wanted to add an addition detail I realised after I posted this. With the ability to control the camera, you can fix the very annoying issue for AR, and that is that it will always be one frame delayed. The simple reason is, you have control over camera data and the camera data you send will need to be used for the next frame, not the current one, exactly like AR. Thus, AR jerkiness is eliminated because the data is in sync.

That is all I wanted to add to my previous post, but maybe someone else here can expand on what I've said with their own thoughts... making cinematic cameras through Lua could really help with RP videos... so yeah...

@NQ-Ligo, I hope to see what you say with all of this, if there is some security concerns/exploit concerns... I think camera movement would be difficult to protect, but if you can control it such that it has a range of movement it cannot exceed, it can probably be solved.


What immediately comes to mind is a "maliscious" move someone could do with that, namely we already have auto-triggering scripts that go off when anybody comes close at the markets. If anyone can "force" my camera view to look at their "ad" on the markets, then I would very much hate any such change.

Link to comment
Share on other sites

Is it possible for there to be some way for the screen to know who is looking at it, or get the camera information? I've been working on some fun HUD code but a major limiting factor is not actually knowing who is looking at the screen, or more importantly, where from. I'm working on some work-arounds, but they're clunky. All I would need is getCameraPos, the rest isn't needed for my use case, and I think it would allow some cool stuff for screens to be able to react to the angle they are being observed from.

Link to comment
Share on other sites

1 minute ago, Metsys said:


What immediately comes to mind is a "maliscious" move someone could do with that, namely we already have auto-triggering scripts that go off when anybody comes close at the markets. If anyone can "force" my camera view to look at their "ad" on the markets, then I would very much hate any such change.

 

Requiring an explicit run would resolve that issue. I can't think of any malicious behaviour possible while an explicit run is required... They almost certainly exist, but I can't think of them.

Link to comment
Share on other sites

I understand the reasoning behind the logging changes NQ is making, but it is not going to stop the players they are looking to target with this and overshoot the intended purpose for that reason. This will be another "throwing the baby out with the bathwater" situation IMO.

 

The removal of logging only really hurts the players who use it in a productive and functional way, effectively creating the "emergent gameplay" NQ like to refer to.

It is trivial to write an overlay that is completely invisible to the game (or EQU8) to then write information to a screen and/or the HUD and OCR it off of there to use it outside the game, A bit more work than getting it from the logs but not by much once the tool is written (which is really, really easy)

 

Also, on the volume comments, I am not sure how that could be difficult to the point where it required "deep changes" as it is as simple as a DirectX object which I'd expect would be exposed to the Lua subsystem anyway for a number of other reasons. 

 

Link to comment
Share on other sites

7 minutes ago, ReconDo17 said:

So in the announcement of the "Panacea" update which its of note to know the meaning of that word as a start to what I am about to say. [...]

 

Indeed there were a few good things that came from the Demeter update [...]

 

I am not trying to be negative here [...]

Holy wall of text...
Dude... literally not a single thing you wrote here is relevant to his discussion. This is about the LUA ADDED in the next update. There is a separate discussion thread for what you posted.  To my perspective, this is in line with the update, it's fixing long standing issues, at least temporarily until players find ways around it. After ZarTaen made the sound player, and mentioned the possibility of the exploitation potential, it was a matter of time for them to remove it. Which is a long standing exploit concern. Now, whatever methods they use will basically not be "easy", as much as people claim it will be. I don't even know where to start with making an OCR that can scan my screen, and most people don't. And anyway, it's not on NQ to counter such things. That is on Anti-cheat to counter.

And on that note, not specifically referring to what you said really, there is literally nothing stopping you from going as far as to just hook up an external camera and pointing it at your screen to read a generated QR through SVG, to then perform some action. You can't stop it. I wouldn't know how to do it, nor would it be worth my effort, but you also can't seriously expect NQ to somehow prevent something like that. What NQ have done is prevent people like me from doing it. And what NQ are implying here is that doing such things aren't allowed and if caught, I doubt you will get off scot-free. And additionally it's not like exporting data manually has been disallowed, you can send a large amount of data to a screen unit and copy it that way if you like.

Also, I would like to petition that NQ Ligo get a Discord account so we can talk to him more directly regarding normal Lua when he's available. He can then more directly address questions that pop up in Discord... but probably like Deckard wouldn't talk much. 

Link to comment
Share on other sites

52 minutes ago, blazemonger said:

The removal of logging only really hurts the players who use it in a productive and functional way, effectively creating the "emergent gameplay" NQ like to refer to.

It is trivial to write an overlay that is completely invisible to the game (or EQU8) to then write information to a screen and/or the HUD and OCR it off of there to use it outside the game, A bit more work than getting it from the logs but not by much once the tool is written (which is really, really easy)

 

We are never out to hurt anyone, however we do have to protect the security of the game. 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. Reading the log files alone however, does not. 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.

 

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.

 

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

 

41 minutes ago, ReconDo17 said:

things said by NQ about auto mining were not true like being able to recalibrate in VR. Yes you can do it but at what cost your talents no longer work in VR so your wasting time doing it this way as you are not getting the full benefit of the miner.

 

To be clear, this was also very clearly stated in the patch notes. If you read them carefully you'll notice that the VR capable talents that are mentioned are the ones that count towards the generation of Calibrations. Not the ones that consume them. :)

 

1 hour ago, Metsys said:

What immediately comes to mind is a "maliscious" move someone could do with that, namely we already have auto-triggering scripts that go off when anybody comes close at the markets. If anyone can "force" my camera view to look at their "ad" on the markets, then I would very much hate any such change.

 

The camera Lua feature set does not permit a Lua script to take control of your camera. It grants the Lua the ability to read orientation of the camera. Allowing for such things as accurate "Alternate reality" HUD designs, that move with the background and allow you to have virtual "panels" around you. It does not however allow a Lua script to force your camera to look at something.

Link to comment
Share on other sites

1 hour ago, NQ-Ligo said:

Hi all!

I will try to answer your first questions. Don't worry, I'll do some more passes tomorrow. ;) 

No possibility to copy content out of the game? @Ashford @Helediron@Wolfram

We know that these log functions are used by some people legitimately to get data out of the game, but it has never been the only way to copy data. But it was the only way to get data directly out of the game automatically.

In your case, you can use a screen and log on it. Currently you still have setHTML which will allow you to write very easily on it, without even worrying about the number of characters if your goal is just to copy the data out of the game at the end. You write your log in it, once finished you edit the content of the writing and copy the whole content.


What about reading the log ?

We see the logs as a tool for community projects, such as an external community market platform, so we want to keep the logs as accessible and readable as possible.


I hope that these answers will help you all the same and help you to understand the situation on the logs, on some aspects, they are globally complex subjects.

 

Hey there: The json itemlist I'm gonna use is 1500kb, which is 30 screens full of info. I'm using it to put names to ID's. 

Using the log for:
-Marketdata
-Container contents (to get lists of them out of game)
-Lua logging when game crashes.

Extra solutions: A curated item list with names and (schematic)ID's 
Writing the log after client close. Or parts of the log?


At any rate, thanks for your clarification and hard work. Still enjoying the game a lot :)

 

Link to comment
Share on other sites

1 minute ago, SneakySnake said:

UP 

 

 

 

 

Yes absolutely PLEASE NovaQuark, if you guys want to remove writing to the logfiles as a feature then also allow us to disable them in first place. I don't need yet another part of my system being stressed by the game. Log into your AWS systems if you want to use something for debugging.

Link to comment
Share on other sites

3 minutes ago, NQ-Deckard said:

The camera Lua feature set does not permit a Lua script to take control of your camera. It grants the Lua the ability to read orientation of the camera. Allowing for such things as accurate "Alternate reality" HUD designs, that move with the background and allow you to have virtual "panels" around you. It does not however allow a Lua script to force your camera to look at something.

What he was referring to, Deckard, was relating to my comment about possibly malicious uses for a camera that would allow you to change such things. But I told him in a PM that you can just put that behind explicit activation and it would prevent it.  But should such a thing exist, limits would definitely need to be put in place, especially with a camera position set. I suggested it as a way to increase immersion which we could code on our side rather than waiting for NQ. Doing stuff that can increase immersion would help with a lot of the gameplay at the moment feeling very gamey at times. If you add on top of that, input exposure, you can even do stuff like "leaning" in Lua. It adds a new dimension, it would just need to be properly limited.

Link to comment
Share on other sites

6 minutes ago, NQ-Deckard said:

 

We are never out to hurt anyone, however we do have to protect the security of the game. 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. Reading the log files alone however, does not. 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.

 

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.

 

 

And how do you arrange supporting other players without logging? Hint: linking to e.g. screens is one major support issue. Now i should ask them to link  a screen to capture logging to resolve screen issue?

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...