Oran_Gootan

"Playing at the same time with two or more accounts is forbidden (having several accounts is fine as long as you only play with only one at a time)."

Please reconsider this. People who want to multibox will not stop because you simply say their not allowed. It just raises the barrier to entry for people who want to. This game involves a lot of waiting around if it's for industry or slowboating and allowing people to do fun things on an alt allows them and others they play with to have more fun playing the game.

+1 to all this!

Well NQ, to be honest, yes these steps you made are totally necessary, BUT the DLLs gave us features you still didn't gave us and that are absolutely required.
 
These are for example:
- external requests for receiving and sending data to our own apis (VERY IMPORTANT)
- a json encoding/deconding that is not stupidly slow
- communication between programming boards
- and more
 
The coder community in this game is big and needs more specialized features to make this game as great as it deserves to be. But if you restrict everything and give us nothing back, I don't know how long coders will stick to the game.
 
I am actually quiet disappointed how coders get ignored and handled like 2nd class people.

Dear Community Members,
 
We have some very exciting news to share. Many of you who have been here for a long time probably already know Yamamushi. As one of the co-founders of the official community Discord and an early Kickstarter backer, Yamamushi has been around as a very active and well known community member for almost 4 years now. 
 
We are excited to have him joining the team. With him coming on board, a few important things are going to change and we wanted to be transparent about this with you all.  We have always valued neutrality for our employees and we try to avoid any conflict of interests. Like all other employees he is bound to some important communication restrictions. Yamamushi must discontinue being a community figure while he is employed with Novaquark. This means stepping down as a moderator on Discord and our public forums, while retaining some limited administrative rights (precisely to maintain the DU Bot). He is also bound by an internal NDA contract and won’t be able to share everything as a Novaquark employee. For those who are friends with him, we ask you to avoid attempting to get behind-the-scene information from him, regarding the game or the company. 
 
He won’t be able to communicate or play anymore as Yamamushi, but his love for the community is strong and he will continue to follow the community from the Dev side. He will also not be permitted to be a part of a player-run organization. We know this can be hard to face for such an integral part of our community and this has been a hard decision that may feel frustrating (at least it is for us and for him) but a necessary step to avoid any suspicion of favorizing any group of players in the community.
 
We would also like to take this opportunity to explain what are our internal rules when a member of our community becomes a Novaquark employee:
 
His/her personal accounts are suspended for the time he/she is a Novaquark employee.
  He/she is given an anonymous player account so he/she could still continue to play the game, however, some specific rules apply to such an account:
  a. The Novaquark employee behind should not reveal his/her real identity and/or he’s part of the company. 
  b. He/she shouldn’t join a player-run organization with this account either, for neutrality reasons.
  He/she is given a NQ account, mostly to test things, and occasionally to communicate with the community in-game (if such opportunity arises). Nothing done on this account (coming usually with more powers/rights than a player account) will be transferred on any personal account.
  Thank you for taking the time to read this, please join us in welcoming Yamamushi to the team here!
 
Best Regards,
The Novaquark Team.

What you're suggesting goes beyond the bounds of cartesian space into abstract theoretical involving multidimensional spacetime. This seems to me a bit more difficult to implement and also quite a bit more monotonous, and it diverges from the incredible single shard galaxy nq has created which involves distributing computation to specific blocks of cartesian space. I'm not sure that this space can be bent without fundamentally altering the backend.
 
Consider a superluminal pursuit in the "factor seven" plane. The superluminal performance of these vessels on this plane would be no different than the performance at any plane or at sublight. If the pursuing vessel were to jump to the factor eight plane the two ships would not even be in the same spacetime, so would not be able to interact with eachother. 
 
What I am suggesting is a simple, readily computable velocity measurement  based on the performance of the vessel in question and six input signals without having to change the mathematical representation of the universe or doing an actual space-warp.  The big question with implementation isn't whether we can do crazy scifi math but simply whether or not the backend can support superluminal velocity. 

The most commonly accepted theoretical method for FTL travel is called the Alcubierre Drive, which propose to build an engine that can warp space. This involves creating a 'warp bubble' which consists of an unexpanded region in the center, a squished region in the front and a stretched region in the rear. 
 
To simply slap on a module that make your ship go is not good enough. To make FTL ship design interesting/compelling a designer should have to calibrate the field geometry such that 
 
 the ship fits in the bubble  the bubble is streamlined  the engine has sufficient power to maintain the bubble radius  
Desirable attributes of FTL drive for shipbuilders to balance:
 
Startup time - This is the time your ship takes to initiate FTL from cold start Speed - This is the maximum velocity your ship can achieve without overloading your FTL drive Acceleration- How fast your ship can speed up and slow down.Energy usage How much energy it takes to maintain velocity. Structural integrity - The ability of your ship to accelerate in a given direction without flying apart. Power - The amount of your ship dedicated to supporting your FTL system Control systems - A well designed control system will operate your engine efficiently and safely, without exploding   Interactive FTL capability will add value to ships and increase competition for engineering design and control systems. The FTL design of a vessel would have to be engineered and calibrated by a specialist, and each design would have to be unique. 
 
Equations of warp bubble can be described by the FTL drive component with simple made up math which is loosely based on current ftl research but has nothing to do with reality:
 
The field is composed of an expansion ellipsoid and a contraction ellipsoid
 
Velocity =Vector(D, sqrt(E*C)*FD)  
where D is the angle between the FTL drive and the point furthest from the warp drive on the contraction ellipsoid.
where FD field divergence is the maximum distance between the two ellipsoids in meters
where E energy is a constant based on the total energy supplied to the drive
where C is the speed of light in a vacuum
 
If I place my ellipsoids farther apart I will travel faster. If I place them closer together I will slow down.
Changing the field geometry such that the field is offset in a direction other than forward would allow your ship to drift, strafe, and warp sideways and pull off all sorts of maneuvers. The offset and the sizes of the ellipsoids comprising the warp field will determine the velocity and direction of travel. To withstand a change in direction the ship must have sufficient cross-sectional strength/weight ratio in the direction of the change in acceleration. 
 
The drive is controlled by the positioning of the ellipses. The first set of inputs, X0,Y0,Z0 control the energy diverted to projecting the bubbles in each direction, determining the size of the bubbles. The second set of inputs , X1,Y1,Z1 controls the position of the forward bubble relative to the drive. Field divergence and velocity is given by the  second set of inputs.
 
 
To turn the drive off, cut the power. If the power level is insufficient to create a bubble which your ship fits inside your ship will not enter warp. 
 
If the field strength is not sufficient to maintain the bubble radius the ship will be crippled by the shearing force.
 
Energy usage will be given by the total volume of the bubble divided by the aspect ratio of the bubble, direction of travel to max radius perpendicular to the direction of travel multiplied by the field divergence.
 
 
Protip: Use the same mechanic except with a single ellipsoid when you implement shield bubbles to save work.
 
 
This will lead to the following situation:
 
    The captain tells the engineer to outrun the other ship
    The engineer is concerned because you run the risk of overheating the engines
    The captain doesn't care and just wants to go faster
    Either the ship explodes or everything works out ok depending on both the engineers competence and the designers competence
 
A staple situation of modern space drama which would only appear in a cutscene in any other game.
 

What you're suggesting goes beyond the bounds of cartesian space into abstract theoretical involving multidimensional spacetime. This seems to me a bit more difficult to implement and also quite a bit more monotonous, and it diverges from the incredible single shard galaxy nq has created which involves distributing computation to specific blocks of cartesian space. I'm not sure that this space can be bent without fundamentally altering the backend.
 
Consider a superluminal pursuit in the "factor seven" plane. The superluminal performance of these vessels on this plane would be no different than the performance at any plane or at sublight. If the pursuing vessel were to jump to the factor eight plane the two ships would not even be in the same spacetime, so would not be able to interact with eachother. 
 
What I am suggesting is a simple, readily computable velocity measurement  based on the performance of the vessel in question and six input signals without having to change the mathematical representation of the universe or doing an actual space-warp.  The big question with implementation isn't whether we can do crazy scifi math but simply whether or not the backend can support superluminal velocity. 

I spent some time as a UI developer and intend to in the near future, and one aspect of this video had me slightly wary: 

My concern is with the responsiveness of UI elements. It's been proven by studies (and anyone that has used any bad UI for an extensive amount of time will tell you) that added delays of over 100ms between interaction and response leads to user-input frustration. As displayed at 0:07 pressing b opens a menu, however it does so slowly, sacrificing usability for an entirely aesthetic animation. At the very first time you use something slow but pretty you'll think it looks good, but after the 10th time you'll notice it could be faster, and the 100th you'll be frustrated. Same goes for the options highlighting at 0:28. 
I'm not saying that everything in the game is like this, but simply giving a warning that UI development with little regard to responsiveness will give a bad user experience. So please head this and make sure you aren't intentionally adding delays of over 100ms just because it might look pretty. Making a user interface have a responsive design is critical to how users perceive it. Thanks for your time.