Yoarii

NQ, There was one question the community wanted answered, and you failed to deliver on that yet again. At this point "we hear you" is not enough. An actual answer is long past due. The community - your customers - are suffering. Please, let us know what will happen going forward, in a detailed manner, so we can plan accordingly.

It is ten. Last changed in Panacea.

It is now Friday of "next week", where is the pod cast? Looking forward to hearing all about the decision on the wipe!

Excellent idea.

That first pod must exhaustively address the wipe question to the exclusion of all else.

Yes, wiping talent points on any account (beta-key or paid) is a definitive "I'm gone" too. How can it possibly be a good thing to hold a knife to the throat of the entire player base? How do they expect players to want to invest time and effort into something that may get deleted? Yes, any MMO have a limited life span, but this is so demotivating. It's not like new players don't become aware that there's a wipe hanging over our heads considering the discussion comes up over and over in general chat. I love (some parts of) the game and the community, but I am utterly disappointed in NQ.

Please NQ, end the suffering and announce your decision. There's nothing but bad PR resulting from this limbo.

Lets tweak it slightly: - Use left side of the icon for warp destination, right side for destination. That way, when they overlap they form a whole. When they don't, it is clearly evident they are in different spots. - Allow us to hold shift when setting warp dest to also set destination to the same place.

Equip your harvest tool and they will light up.

The Athena patch broke shadows, see images here: https://imgur.com/a/g2MrWdo * The vertical shadow artefacts on the wall in the first image were not there pre-Athena. The wall is a 1:7 slope. * The second image shows a 1:2 slope, again with artefacts that were not there pre-patch. * Disabling shadows removes these artefacts, images are taken with "medium" shadows. * Adding additional voxels on the thinnest parts makes the artefacts disappear. I'll reference this post in a ticket too, I just wanted to get this out there in case someone else have the same issue.

Epic.

Maybe allow LUA access to the list of beacons/planets currently in the users' map? Maybe add a game setting, disabled by default, that allows the player to grant access to it? If the setting is disabled, just return a tuple of {false, "::pos{0,0,0,0,0}"}

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

Nice thinking!

Lets be constructive and find solutions instead of adding limitations. First of all, how often would a dispenser be updated? The intention is not to play the 0.01 quanta game as on the market where there is a five minute limit on order updated if I remember correctly. So lets add a per-dispenser limit of 5 minutes for updates (per API so that setting the price doesn't prevent changing batch content etc). Or even better - as Endstar suggested - a UI for all dispensers, at least on a per-construct basis, that allows importing/exporting a Json document that we can work with outside the game. You could even set a limit on the import function to 5 minutes or whatever is suitable. Oh, it's that tag. I had forgotten it existed. Isn't that a number though, does it accept any string?

@NQ-Ligo Until dispensers allow the buyer (and later the seller in reverse dispensers) the ability to select the number batches to buy/sell, we're still forced to have at least two dispensers to sell both single/smaller amounts and larger amounts. As to the number of server-requests/server load - I don't think that point is valid. With the per-dispenser API we'll just work around it by having a programming board per dispenser (just like we have now for each screen) that configures the dispenser on command from a central programming board. Same number of calls to the server, just from different programming boards, with whatever added load that means. Allowing it to be done from a single programming board would not only significantly reduce the number of elements needed, thus reducing both server and client load, it would also allow for a much more pleasant developer experience. Side question: Since all constructs have a core, why is it not made available via something like system.getCore() instead of manually linking it? Ah, so these are not RDMS tags? What are they then? Just some arbitrary tag to attach some data to a dispenser?

Thank you for engaging with us, @NQ-Ligo That sums it up pretty well, but wouldn't it be better to implement this in a similar way to industry machines, i.e. setDispenserPrice(id-of-dispenser, price, notify)? For such important things like prices etc. in dispensers, I think it would make sense to not have to rely on communication via emitters/receivers to distribute this information; having a single board to mange all dispensers in a construct would be very beneficial. I'm ofc talking from my own experience where we have an entire wall of programming boards, emitters/receivers (~400 or so) for each individual dispenser/screen pair. With this API implemented via the core (or an object we get via core.getDispenserController()) and the new item API I think I can completely remove the communication part which would remove something like 800 elements from our shop. Another thought - setTag and getTag() shouldn't they be on all elements, not specific to the dispenser? Also, there can be multiple tags on an element so they need to take/return a list of tags.

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

As long as it allows us to import/export all data points so we can use out-of-game tools to manage prices etc. etc.

Now that is a really good question. NQ, can you please make up your mind and lets us know? Nothing good will come out of delaying an announcement any longer.

It all been said already, just adding my voice AGAINST a wipe. And absolutely #donttouchmytalentpoints

NQ - will there be an alternative payment processor to Xsolla on/before release?

Both of those items can be made in the nano crafter.

Lets take it one step further and remove the RDMS for surface harvesting of the small gravel on claimed tiles, just respawn them if they don't do that anymore. Not having rights to pickup the small rocks is just plain silly.

So how to claim land is now removed from the FTUE?