P4rty_Boy

Just an idea here; not the most elegant solution, but it could help keep compatibilty while enjoying the benefits of 1.4 Instead of replacing functions such as unit.hasDRM with a boolean version, why not simply add a new function like unit.hasDRMBool that is optimized for lua 1.4. Have a deprecated version of unit.hasDRM that do something like function hasDRM(param) return (hasDRMBool(param) == true) and 1 or 0 end For the whole list of function that will be impacted. That would give time to people to prepare, change their script & ensure it works before removing the old deprecated functions in a couple of months. Just an idea. I must admit, I am a bit scared to long on day 1 of 1.4 and not being able to fly anywhere

getInstructionCount and getInstructionLimit functions -> This is realy great, thank you! BTW, would it be a major hassle to add the line where we stopped when we get CPU OVERLOAD? Often time, we get that in special conditions where we end up with a infinite loop on the lua side, but they are not easy always to catch. At least, if we knew in which part of teh code we were looping, that would be great. Anyhow, thanks for the update, keep up the good work!

No we are not choking on this, because almost everybody that tried to do something ambitious or hard, understand the name of the game. Of course you try to make a universe & not wipe it. Since this is an extremely hard undertaking, there is chances of failure. And when the failures are large enough, then the only solution is to fix the mistake & reset the world. Hopefully, this is the last time - we all hope for this, including the devs. They are not reseting for fun, they are reseting because it is a necessity in order to keep the game fun for enough people, that they make enough money to not go bankrupt (that would be worst than a reset, isn'it?). So hopefully, the reset will make the game even funnier, with busy markets & a fresh batch of new players. Try to focus on that. Like everyone else I was also a bit bitter of losing everything I built, and all my mining time, etc. But at one point, you need to let go, or you will never be happy about anything. Embrace the fresh start! Happyness is a choice. Hope to help you to re-ignite the flame. Anticipation is a great feeling!

While you wipe - Why not correct another mistake; Haven IS the moon sanctuary was meant to be. You added it as another moon, further away, and left sanctuary to no real purpose. Why not fix that by the same token -> We only need haven at sanctuary's location, no? We cannot even colonize or mine sanctuary.... it really feel like out of place now, taking a great starting moon location, right inbetween Alioth & moon 4.

Hi there! Thanks for the annoncement! And thank you for your continuous effort in making the game better! In the annoncement, I would have loved if you would have explained a bit more what were the goals you were aiming at with this system. To me, the current schematics system kind of acheive this goal already (with some tweeks). So from the annoucement, what you want to acheive with this new system is: We wanted to make schematics more accessible and easier to use while retaining a portion of their limiting effect. We have made them more scalable across the board and made the system easier to balance and adjust from our end. I do think that removing the need for schematics for basic items & part is a great improvement, and goes toward making the system more accessible. For the easier part, I am not sure. It seems harder to me & even add grinding to it, which is not fun. Already, IMHO, mining unit calibration is a pain in the butt. So having to feed all my industry with an extra item (consummable schematics), makes it way harder than before. I've read that you are considering a global pool for the whole factory. Which would be better than schematics per industry. I like the idea of people being able to produce schematics & selling them on the market. That goes toward the MMO element, and is a good way for industrialists to trickled some money back to the new players. It adds to the industrialist burden tough. But having regular trip to markets is a great way to also add transport missions. For the scalability & balancing, yes I do agree that it gives NQ more control, but you still had this control with schematics. I would not see any problem with fluctuating schematic prices in game. But I guess thecontrol you are trying to introduce, is not on the factory inital setup, but on on its daily operation, which is understandable. All in all, I think there is a lot of positive in that change, but please try to limit the grind for industrialists (other than the need to buy on markets). Also, if you guys are trying to limit the factory size for performance reasons, please open a thread, I have tons of suggestions on how to achieve that with smaller changes (being a big industrialist myself) - but I hope this change is NOT meant to achieve that goal.

I think that would be a great idea too. A source of revenues for player that does not have much mining unit at the beggining of the game. Also it would also go toward the goal of having more trade.

Well fair enough, but the point I want to bring is: Each feature you push/ask for is something else being pushed later on or dropped. You cannot have your cake and eat it too. At this stage of the game, I would rather have them work on stuff that is part of the normal game loop, and which could be impoved, rather than stuff thay maybe, will serve again one day. Here is a forum, a channel from the plyers to them, the developers. If you ask them to work on something that will not be used or maybe never be reused, and they listen to you, well we are losing something else that could be fixed instead. Let's try to be a team here & help the dev find our where their time spent working on the game will result in the biggest bang for the buck. And as a player, I did my talent selection, and I don't see the point on improving that interface, until next time they plan a talent reset - which should be, hopefully, never.

Info for those who are switching Lua.... getElementIndustryInfoById() returns information, including a state, which can be interpreted like this: 1= STATUS_STOPPED 2=STATUS_RUNNING 3=STATUS_MISSING_INPUT 4=STATUS_OUTPUT_FULL 5=STATUS_NO_OUTPUT 6=STATUS_PENDING Sometimes industries goes into Server error, and I did not encountered that state yet. Also note that getSchematic() returns a table with tier & id, instead of the equiavlent JSON of level & name

@NQ-WandererHey there! I'm in the middle of my Lua overhaul to work with Mercury. So far so good. Thanks for switching to tables instead of JSON, it makes my code way cleaner. The API additions, the slots for the player, and so on are great additions, thank you! I do have questions about the container updateContent() call, if you could clarify. The doc says, 1 call every 30 seconds. Is it; 1 call every 30 seconds, per container? If that's the case, that would mean that I would be allowed to update instantly, 10 differents containers on a single programming board. If that's not the case, connecting a programming board to 10 differents containers would require 5 minutes to know the content of all of them. Is it; 1 call every 30 seconds, per programming board, which means that I can have 10 containers, with 10 programming boards, and then I can see the content right away? Is it; 1 call every 30 seconds for each player? If I start a programming board looking into a container, and a friend start the same programming board 5 seconds later, will he be able to see the content of the container? Is it; 1 call every 30 seconds per construct? Thanks in advance!

To be honest, spending 88.8M points should not happen. Why ask NQ staff to spend time on an API intended to spend efficently 88M points that will never be used again in the released game? I'd rather have them put time on tools we will use every day and part of the game. Remember we are still in a beta. Just my 2 cents here.

FYI if you do a dumb replacement of receiver.setChannels by receiver.setChannelList, you get a game crash. Took me a while to figure out since I kind of swapped all deprecated functions, and when I started my programming board, I was getting a game crash with no indication why. I just forgot that setChannelList receive an array, and setChannels a string. I'll fill a bug report.

+1

Ideas to reduce LUA requests on the servers: - Add in the core, a construct version number. a Lot of lua code, start by scanning all elements in a construct, then doing its thing. 99% of the time, the construct haven't been modified inbetween 2 executions, so all Luas could just skip the scanning part by comparing the edition number (this number chould only be changed when you edit the construct by adding/removing/renaming an element). - For space station/industrialist, i do need to query containers volume & names and do a correlation with my industries, because the output element count returned by industries is not reliable. This bug has been reported since years now, and still not fixed. So fixing current lua bugs would be a great plus before going in to a new revamp. - Having a fast element & recipe API would also be great - glad to see the direction you guys are taking with the item API. Right now a lot of my lua in term of sizes, are tables with all the elements. - Very happy with the inclusion of the core as a default slot; a lot of my code was complicated for nothing, because it was not possible for me to have a connection for all my prog boards to the core. - A way to query the current FPS, so script can scale down computing/display on already strugging computers.

Please a CTRL-F in the editor!!!! And block-select tabulation

Before rolling out this change, would you consider implementing Tools to help player transit to that update? With this new constraint, we will need to dismantles constructs, and/or merge constructs that were on separate cores - because of older contraints (like the parenting before it was fixed). It is a lot of boring work, for no plus value for the players (other than conforming to Panacea). You can help make that transition less painfull by: - Add tools to disassemble a construct in the current container, instead of removing everything 1 by 1 - Increase the copy-paste volume size if possible - Enable copy-paste of elements - A tool to offset everything in the building zone - A way to align constructs, especially when using blueprints - Would you consider a tool to "upgrade" i.e. replace a core with a larger one? - Would you consider XL cores or cores with different shapes? A lot of our constructs are just tarmacs, ramps, parking space, voxel libraries, etc. They barely contains elements. Because of the small core, a lot of us endup with a box-style base. We used other smaller cores to build outside the base itself, just for aesthetic - and mitigate the box-like base. With more room, we can still keep the same base, but integrate the aestetic extras inside the same core. With all these tools, we could rearrange things around, and reduce the core counts (which is the intended goal). Please notice, that a lot of times, we are stuck with a higher core count because of previous game limitations. Example: We created parking space very far away from each other, with multiple core inbetween because of the bad parenting (that is now fixed - thank you).