Jump to content

DEVBLOG: ATHENA LUA IMPROVEMENTS & ADDITIONS - discussion thread


NQ-Wanderer

Recommended Posts

Some basic lua for the d-sat could help. Nothing fenzy, only the data you can earn per hand. The position of the targeted mark, maybe an event to scan the position. D-sats are large elements and doesn't fit in a cockpit most of the time. It should possible to operate them from the command seat.

Link to comment
Share on other sites

6 hours ago, CoyoteNZ said:

We need Lua for Dispensers!

 

set contents, set price, and events transaction made, or transaction failed. 

 

Was really hoping this time when the post said new Lua functions 😩

And LUA control of rights (check player id) w/ reverse dispenser! (receive item, pay money!)

Link to comment
Share on other sites

On 4/22/2022 at 6:51 PM, LeeFall said:

"With this update, we’re making a fundamental change in text rendering technology." Had me in tears... You guys are jokers.... text rendering technology hahahahaha. Please stop tinkering with screens etc and create some game play loops... Thanks.

Jim! I'm a text render engineer dammit! Not a game designer!

 

Do you want your house painter fixing your car? Do you want (in this case) the programmer designing your game loop? I personally think that is a bad idea, I think the reason we're in this mess is because too many people that aren't game designers designed the game. On the other hand, we wouldn't have DU in the first place if it weren't for those same people...

 

Too many people on these forums fashion themselves (undiscovered) game designer talent, often their designs or 'fixes' have the depth of a pool of rainwater. Game designer is an actual job, requiring experience and insights! Some get lucky and fall into it due to innate talent, but there are actual game designer courses (that are actually quite interesting), some even part of Bachelor programs.

 

I think that expecting more game play loops before, during or just after launch (beyond what's already been announced) highly unrealistic. To be honest, I expect that if DU doesn't achieve their expected post launch income numbers, DU might not reach the end of the year before they pull the plug permanently...

Link to comment
Share on other sites

43 minutes ago, Cergorach said:

I think that expecting more game play loops before, during or just after launch (beyond what's already been announced) highly unrealistic.

So if we use the standard definitions for development cycles, you are saying that NQ is going to release the game in alpha state?

Link to comment
Share on other sites

34 minutes ago, CptLoRes said:

So if we use the standard definitions for development cycles, you are saying that NQ is going to release the game in alpha state?

If we're using standard definitions for development cycles, they've redefined the initial release state and all the other 'promised' features will be added in expansions down the road...

If you look at it from that pov, it might be a 'full release'...

Link to comment
Share on other sites

Hi everyone!
 

Well before starting, I would like to thank you for your feedback, whether it is positive or "less positive". I will try to answer your questions in a general way, hoping to bring the hoped answers.

First of all, I must respond to the critics:
 

On 4/22/2022 at 4:23 PM, RockSlaughter said:

For a game that's losing players because lack of content, you sure do keep wasting time on useless stuff. People are literally screaming at you to make more things to do, other than building and mining, and you're just like "hmmmmmm lets make it prettier!" Stop wasting time on this stuff!! Do this AFTER the game is fun and engaging!

 

On 4/22/2022 at 6:51 PM, LeeFall said:

"With this update, we’re making a fundamental change in text rendering technology." Had me in tears... You guys are jokers.... text rendering technology hahahahaha. Please stop tinkering with screens etc and create some game play loops... Thanks.


I can totally understand that this aspect of the game is secondary for you, and it's normal, not all players are interested in Lua, just like not all players are interested in pvp, or industry, voxelmancy ...etc. 
But remember that in a studio, not everyone is working on the same thing at the same time. People who work on Lua, and myself, are multi-tasking but not necessarily working on pvp, or content, or art...etc at the same time, or even just for some like me, pvp/content/art is not in their work domain. It do not means that there is nobody working on these aspect when we do some Lua changes.

 

Core to core data exchange & elements LOD

This aspect is really complex, when Lua is run locally by the client, it always has to interact, get data from elements or control them. So the more access you want to add, the more data you have to constantly load/request. This can be very tricky on the server side.


Imagine, having the ability to get rangefinder or radar data from a building at a distance of 10 SU (for an absurd example), you have to get ALL the buildings around the target, terrain voxels...etc! That's a lot of data to query, load, update, etc.

And on top of that, even with all the good will in the world, it is really complex to keep everything loaded all the time. That's why we've even added a build limit setting, to allow players to adjust it according to their bandwidth and computer configuration.

Anyway, even if we could, I say could, rework systems for receiver transmitters, we will certainly not be able to allow the loading of a remote construct and the proximity environment ... etc. So to answer, say, really complex problem.


Static image URL
I didn't saw this thread @Juvenius Drakonius (do not hesitate to tag me on Lua related stuff, even if I will not reply every time obviously, it let me know the subject and let you know that I saw that). 😉

It's an idea, something to consider 🤔 Potentially, if we could add a way to update an image on the "upload image" page of your profile, it could do the same thing. I'll discuss this with the team. No promises, we'll see.

But one point is the validation process of the image, it means it would have to repass by it to be sure the player do not upload a forbidden image.


Industries, dispensers next ?

As you may have read at the end of the devblog, we've outlined the fact that we think the item API approach can be good and would like to get your feedback on it since we could then apply it to other aspects of the game.

So, the aspects affected could potentially be, if the item API formula works: industries, containers, elements in general, and dispensers ...etc.

That's one of our goal behind the item API, so potentially if you feel this approach the good one 😉.

Camera direction function not working ?
 

6 hours ago, Modgud said:

The LUA functions to determine the camera direction of the player, like getMasterPlayerForward() doesn't work in a command/ hover seat.

Don't worry @Modgud,it's not a bug, it looks like you're using the wrong function for what you expect.
Indeed, getMasterPlayerForward returns the front vector of your character, not the camera.

To get the forward vector of the camera, you should use getCameraForward() or getCameraWorldForward () depending of the coordinate system you want to use ;) 
(These links reach the awesome online CODEX made by a community member, it can help you a lot).


An other word
Finally, I'd like to address this word; keep in mind that we'd like to do a lot of things too, and a lot of which come from our players' ideas, but there are multiple issues and constraints; both human in terms of available resources; Lua remains a secondary feature, as well as community; some want to push the dev on this, or want this or that freedom, there are multiple opinions similar to yours and multiple opposed to yours.

Especially on Lua, some would like to not hold back from breaking a good part of the API to improve it, and others are totally against it because it would break their scripts. That's why it's important to tell us what you think about these devblog threads, so that we can know if a majority prefers this or that approach. 

Anyway, thank you all the same for welcoming the evolutions we make on the Lua and for sharing your ideas and desires. 🙂

Link to comment
Share on other sites

15 hours ago, NQ-Ligo said:

Industries, dispensers next ?

As you may have read at the end of the devblog, we've outlined the fact that we think the item API approach can be good and would like to get your feedback on it since we could then apply it to other aspects of the game.

So, the aspects affected could potentially be, if the item API formula works: industries, containers, elements in general, and dispensers ...etc.

That's one of our goal behind the item API, so potentially if you feel this approach the good one 😉.

Dispensers?! O.m.g. now you're getting my hopes up. I'll begin reworking our SVEA shop system using the new item API soon, it should make things a bit smoother.

 

Here's an idea - let us trigger a LUA script and/or a programming board any time an item is removed/added to a container (via industry/player interaction/dispenser usage). This would enable a lot of interesting possibilities. I'm specifically thinking we could get up-to-date stock info out to our screens, without having to resort to hundreds of pressure plates all over the shop. The same functionality could also be added to the dispenser. The trigger via industry units would ofc have to be server-side, but the others could run client-side which makes them easier to implement I assume.

 

Also - reverse dispensers, i.e. let us buy things, would be an awesome thing.

 

And while we're at it:

* The forgotten Dispenser API and other ideas proposed in that thread.

* Can we please make Dispensers MKII a lot smaller than the current version?

* Allow multiple dispensers to link to the same container or container hub.

 

Cheers!

 

/ Yoarii

Link to comment
Share on other sites

45 minutes ago, Yoarii said:

Dispensers?! O.m.g. now you're getting my hopes up. I'll begin reworking our SVEA shop system using the new item API soon, it should make things a bit smoother.

 

Here's an idea - let us trigger a LUA script and/or a programming board any time an item is removed/added to a container (via industry/player interaction/dispenser usage). This would enable a lot of interesting possibilities. I'm specifically thinking we could get up-to-date stock info out to our screens, without having to resort to hundreds of pressure plates all over the shop. The same functionality could also be added to the dispenser. The trigger via industry units would ofc have to be server-side, but the others could run client-side which makes them easier to implement I assume.

 

Also - reverse dispensers, i.e. let us buy things, would be an awesome thing.

 

And while we're at it:

* The forgotten Dispenser API and other ideas proposed in that thread.

* Can we please make Dispensers MKII a lot smaller than the current version?

* Allow multiple dispensers to link to the same container or container hub.

 


HI Yoarii !

I just saw your topic yesterday, so replied on it ;) 

To summarize your post :

  • Trigger controller from a container event : The main problem I see for this, is that this analog signal will start the controller, ok, no problem here, but will not provide any data because it will not trigger a potential event like onAdded for example, so lose interest no? Adding a Lua event providing the interacting player, or the added element ... etc has a strong potential, but the logical signal, not sure. 🤔
  • Reverse dispensers, as answered on your topic The forgotten Dispenser API , it would need a new dev on it to add it. So it may take some time.
  • Adding a smaller dispenser: means a new asset to design and a lower dev but still to do. And logically a limitation on one aspect, because otherwise it will make the "classic" dispenser useless; to be considered.
  • Multiple containers per dispenser : Can be a tricky point, because can lead to an high server cost on container change subscription. Not sure can be done 🤔
     

However, I hope this answers your question. And remember, I can't give any promises, we have a lot of work to do and some things you would like to see, and I would like to see, can't be done for a long time.

Link to comment
Share on other sites

On 4/22/2022 at 4:18 PM, Modgud said:
  Especially an event "transaction made". This alone can push the potential of dispensern.

perhaps watch the mass of the container on a tick. if it decreases by the amount of one payload, then the transaction occurred.

Link to comment
Share on other sites

On 4/26/2022 at 6:14 PM, NQ-Ligo said:


HI Yoarii !

I just saw your topic yesterday, so replied on it ;) 

To summarize your post :

  • Trigger controller from a container event : The main problem I see for this, is that this analog signal will start the controller, ok, no problem here, but will not provide any data because it will not trigger a potential event like onAdded for example, so lose interest no? Adding a Lua event providing the interacting player, or the added element ... etc has a strong potential, but the logical signal, not sure. 🤔
  • Reverse dispensers, as answered on your topic The forgotten Dispenser API , it would need a new dev on it to add it. So it may take some time.
  • Adding a smaller dispenser: means a new asset to design and a lower dev but still to do. And logically a limitation on one aspect, because otherwise it will make the "classic" dispenser useless; to be considered.
  • Multiple containers per dispenser : Can be a tricky point, because can lead to an high server cost on container change subscription. Not sure can be done 🤔
     

However, I hope this answers your question. And remember, I can't give any promises, we have a lot of work to do and some things you would like to see, and I would like to see, can't be done for a long time.

Has NQ considered a physical 'coins' object with a fixed value of 1 coin = 1 quanta? If a reverse dispenser or LUA wallet API is unachievable, we could use physical coins as a workaround to make automated or offline payments to other players by dispensing them in capped amounts from existing dispensers (governed by RDMS and/or control access to those dispensers using doors/detectors/LUA) and take deposits via container.acquireStorage(). This would allow (a) orgs to pay salaries or profit share, (b) operate banks, insurance companies, or stock markets, and (c) set up prizes for user-generated games and puzzles without the risk of arbitrage on a commodity with a floating value. 

Link to comment
Share on other sites

On 4/23/2022 at 4:47 PM, Vilhelm said:

Great new screens but how far are we from serious features such as Territory Warfare? 

 

The Lua community seems to be the only ones happy with what NQ is doing.

They will look after them well until the end.

Unfortunately they bring very little to the game. Seeing one even a negative aspect by automating the little gameplay that could have been at the expense of the players.

Link to comment
Share on other sites

1 hour ago, Megabosslord said:

control access to those dispensers using doors/detectors/LUA)

That is sadly completely unreliable. As you likely know, doors are among the last things to load on a construct.

Link to comment
Share on other sites

On 4/27/2022 at 11:41 AM, Knight-Sevy said:

 

The Lua community seems to be the only ones happy with what NQ is doing.

They will look after them well until the end.

Unfortunately they bring very little to the game. Seeing one even a negative aspect by automating the little gameplay that could have been at the expense of the players.

Why do people keep bring up this concept that Lua somehow has anything to do with any of the other parts of the game? Lua is it's own thing and I doubt the devs behind Lua have many, if any, responsibilities with other parts of the game.

The reason us Lua people are always happy is because we never had any updates or changes for quite some time, and now we're getting them. And I love how you say "they bring very little to the game"... I think you're really salty or something. I don't know how many people use ArchHUD, but almost every ship that is after market has some alternative HUD that makes ship control better. And PVP HUDs that bring much more to the PVP environment, and AR systems to allow for 3D damage control or custom waypoints.

Screen tech is like a foundational part of the game, you see screens literally everywhere. You can make minigames on them, literally. And yet, you say "they bring very little to the game". I have no words for you if you honestly think Lua developers in DU bring little to the game.

EDIT: If you meant "they" as in NQ, I apologize, but if you meant us Lua devs, what I said above remains.

Link to comment
Share on other sites

I have a question. With the replacement of getTime(), which returns the client's local time, with getArkTime() which returns UTC, is everyone seeing the same time of day at a given spot on a planet now? Or (same question) does everyone see the sun in the same place regardless of client time?

Link to comment
Share on other sites

On 5/2/2022 at 5:46 AM, Daphne Jones said:

I have a question. With the replacement of getTime(), which returns the client's local time, with getArkTime() which returns UTC, is everyone seeing the same time of day at a given spot on a planet now? Or (same question) does everyone see the sun in the same place regardless of client time?

I believe the sun has been synced for some time now. In fact, almost 100% sure. I was watching a stream and the person was in the US, and I'm in an EU time, yet the sunlight looked the same on my screen as theirs.

Link to comment
Share on other sites

Thank you for transforms and clip area. I did find difficulty using the clip area because the layer transform moves it. I would like to see the option to keep the clip on a static x,y so I can rotate the layer underneath. Also, rotate and transform are done in any order, if that makes sense? They need to be applied in the order they are written, because of the way transforms work. Rotate before shift, and shift before rotate, produce different results. @NQ-Ligo keep it up my dude!

Link to comment
Share on other sites

On 4/25/2022 at 11:01 PM, NQ-Ligo said:

Imagine, having the ability to get rangefinder or radar data from a building at a distance of 10 SU (for an absurd example), you have to get ALL the buildings around the target, terrain voxels...etc! That's a lot of data to query, load, update, etc.



feels like you were not here on first days of last PTS tests, where radars were detecting the entire universe of constructs
Oups!
thats not more data than we ve been uploading in normal times, and couple thousands of vec3, we are talking here of kilobytes of data not gigabytes
why pretending would need to load anything at that distance, thats absurd

that also works for distant communication, and distant script activation...
why pretexting the area loading, when everything is locally ran

Edited by Jeronimo
Link to comment
Share on other sites

42 minutes ago, Jeronimo said:

feels like you were not here on first days of last PTS tests, where radars were detecting the entire universe of constructs
Oups!
thats not more data than we ve been uploading in normal times, and couple thousands of vec3, we are talking here of kilobytes of data not gigabytes
why pretending would need to load anything at that distance, thats absurd

that also works for distant communication, and distant script activation...
why pretexting the area loading, when everything is locally ran

Hi @Jeronimo!

There is a difference between loading only the positions, and loading all the elements, the construction data, the environment data for any kind of elements you might want to control.


It's not just about positions, but also about things like loading, control, concurrency race, environment, etc.

It would be exactly like having your client at each position of your target build and wanting to get control/data at the same time And that triggered by script. If you have a detection zone, if you have a radar, a telemeter, if you have engines, industries ...etc you have directly more and more data to load, as if you were there.

To close this subject, it's not something we could keep under control, and would be very heavy on many points. It do not mean we do not consider to have higher range emitters, or higher range radar (which are a totally different problematic), just means that we can't keep things loaded constantly for control, or data get for all of your constructs...etc

 

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