Dimencia

We'll see, I don't think I agree unless it's full-creative, and even then it's a maybe. I think it will be rare because DU is a time-investment-based race of sorts; any time spent in VR is time you could have been making income in the real world. Even if the VR world gave you everything up to and including creative mode, the people who would hang out there, are people who wouldn't have kept playing in the main world anyway But you do definitely bring up a good point, because there's a very fine and arbitrary line between a sandbox to test lua scripts in, vs a creative mode, and all the arguments against creative do apply to a lua testing environment. If they allow one, why not the other - and if that why not is good enough, then they probably shouldn't allow either one

Also... it should maybe allow people to choose a blueprint to use as their ship, which it builds for that VR session - to ensure players can still do niche things with scripts, instead of only being able to test flight scripts for traditionally-built ships. And if some script maybe needs tags on all its engines, you wouldn't have to re-tag them every time you enter a session if you have a blueprint with those tags (assuming tags are even saved in bps) This would also allow players to 'try out' ships they have blueprints for but can't build yet (a rare situation, so maybe not all that useful) For security reasons, in that case DRM should still apply to control units (until picked up and placed down again), so it couldn't be used to read scripts from a DRM'd bp And, it should also probably allow you to choose a planet, if it doesn't already... I've never toyed with the Challenges tab. But flight scripts need to be tested on each planet, and it is often very expensive and time consuming to do so But... this also sort of ties in to a much larger idea that would solve a lot of problems and meet a long-standing request.... personal 'worlds' via VR, empty instances of the system for each player. Maybe others can visit your personal world, maybe not. Maybe everything is free in your personal world (creative), maybe not. Maybe you can only deploy blueprints for free there, which avoids all the problems that creative makes while still preserving script testing purposes. Maybe your personal world would be persistent, but if not, it'd still be extremely valuable for script testing And if it ends up with any of those maybes, it could become a whole new avenue of gameplay; some people might prefer to just, build insane things in their creative VR world and share it with people. The players who enjoy the main game wouldn't do it, of course, but those who get tired of the main loop would still have a way and a reason to keep playing

Just spitballing a bunch of ideas for Ligo to consider with the new API changes. Some are more viable than others, but my main thought was that there's all these new functions - but we can't use them because they require us to link to things. Ship controllers can never reasonably link to all of any given element type, which is why the engine commands exist, so more things along those line would be great Take them as you will, if anything can't be done then no big deal, but just posting it in case Ligo might see something useful Element.getWorldPosition Core.getElementWorldPositionById Construct.getMaxSpaceBrakes, Construct.getMaxAtmoBrakes Modify System.lockView - Previously it didn't work if not sitting in a seat; but a frozen player should also be able to have their view locked - if it doesn't already work that way with the new API. This is important for custom UIs to work with the new click controls, when not in a seat Construct.getMinimumStallAngles - Returns a vec3 of the smallest of all stall angles for the construct's airfoils along each of its local axes; for example, if someone is using both airfoils and ailerons for pitch, it would show the stall angle of the ailerons along that axis Construct.getMaximumStallAngles Construct.getLiftEfficiency(vec3 axis) - Returns a 0..1 value indicating the average efficiency of all airfoils along that axis, determined by currentLift/maxLift. Can be used to optimize turns toward the highest efficiency, which implies the maximum speed/angle at which it can turn along that axis in the current conditions Might be better as Construct.getEngineEfficiency(taglist, vec3 axis), which could also work on airfoils Construct.getSustenationSpeed Modify Library.getPointOnScreen - take a local position Library.getWorldPointOnScreen Improve efficiency of getPointOnScreen - apparently it is less efficient than our current methods, regarding overloads Construct.getObstructionFactor(engineTagList) - returns the average(or total?) obstruction factor of all engines in the taglist Modify Construct.getCurrentBrake - Ensure it includes obstruction (if it doesn't already, I haven't been able to check). So should any other 'current' engine readings, again, if they don't already Construct.getCurrentThrustAlongAxis Construct.getPitch, getYaw, getRoll - In degs or rads, and possibly return these values relative to the velocity vector when not near a gravity source, since at that point they have no meaning - or relative to galaxy center would work. It would be nice to have a consistent value across all ships, instead of each AP possibly choosing a different way to calculate it Core.getWorldNorth - Returns a vector pointing north from the core for the current planet, normal to gravity, in world coordinates. Currently we can sort of guess this by assuming the north pole is the point on the planet at the highest global Y (or is it Z?), but a tilted planet would mess that up, if there ever were one. 0 when not in planet influence Player.getRaycastObject - Gets some sort of info about what the player is currently looking at. Particularly I'd like it to be able to detect whether or not the player is 'aiming' at another player, for VR shooting games, but construct info (looking at a ship in space), itemIds, and/or local element IDs could all be useful The main goal of detecting player 'hit' is so that these games could involve complex (real) arenas and rely on line of sight, rather than always being able to 'shoot' through walls

Awesome update, the screens are really getting powerful I'm most excited about the Item API, but I hope it gets a few extra things; notably, a field to indicate the blueprint ID for a given item, and a function to retrieve an Item ID from a core Element ID; i.e., a way to see what size that fuel tank is, without linking to it and without having to use its HP to estimate

This is better, but still doesn't address any of the problems (except the low core count), and seems like overkill for what should be a simple fix: Actually limiting players to 4 orgs per player, as intended. None of this is necessary if players can only be in 4 orgs; it would already solve the problem of infinite cores, and then the values of the existing system can be tweaked, instead of remaking the whole thing

The problems, as I see them: The proposed limits are too low. This change ideally shouldn't affect the average player, but only the top 1% who have an excessive amount of constructs - but after the MU updates, most players probably have more than 42 cores already, just to maintain their MUs There is no incentive for a player to give their slots to an org, rather than keeping them (in their own solo org), which makes large community projects less feasible Having org slots and user slots come from the same pool discourages orgs as a whole; a user shouldn't have to sacrifice their solo play capabilities in order to participate in an org, and if nobody donates, orgs won't be able to ... do anything There is abuse potential if users can arbitrarily revoke core slots they've given What this is supposed to solve: Currently, any given player can create an infinite number of constructs, by creating and nesting orgs with only one member - this isn't feasible for a persistent world, or for servers, and doesn't encourage community projects since a solo player could do it on their own What could be done instead: Fix sub-orgs in any way Just fix the 4 orgs per player, to actually only allow 4 orgs per player, even if they created them I was going to come up with a lot of possible solutions but once I hit on that one... It's a longstanding bug, I don't think it was ever intended that players could be in more than 4 orgs, and if that alone was fixed, solo players no longer have infinite constructs. The current system is quite good, encourages users to make and join orgs because everyone benefits from it, and thus encourages community projects. If you can solve the problem of players being able to join unlimited orgs, then the core counts just need to be tuned, not remade

Additional thoughts: Abuse is likely and possible If I happen to know that some org, which is no longer active, will run out of slots, I could donate my own slots to that org. Then whenever I feel that they won't login for 2 weeks, after the grace period, I revoke the slots I gave them and wait for their constructs to become mine, since only I know when they'll become available Or another example, say I'm the only legate in an org that has some slots given by other players. I go on vacation, or don't login to DU, for 2 or more weeks - Anyone aware of my vacation could move their slots to another org, then wait around and steal whatever becomes unclaimed (or just reallocate them to grief, and not steal anything) This is giving random players way too much control over whether or not orgs can actually keep the things they built or not

My primary feedback is that it's unfair to refund only skill points that were already invested in construct management - when, realistically, if this had existed months or years ago, players would likely have already took these skills instead of others that they are now locked into This is a common theme that NQ keeps doing; adding mining units? Reset mining talents! But that doesn't help people that didn't previously have mining talents, but now want them in their new form. Just like resetting construct capacity talents from before, doesn't help anyone who wants the new talents and would have invested in them if they had always been like this Big talent tree changes should involve full talent tree refunds

I don't think the issue is that DBs are too small; after all, you can link multiple up via RAID scripts, and even link up multiple PBs in a similar fashion with a shared control DB, to store data using as many DBs as you'd like. Or store data into engine tags, which have a much larger size limit But most tend to export data instead because it's much easier, which removes all the creative potential of using the in-game components that are capable of similar things There are many ways to handle logging legitimately. You could always just expect players to be able to figure out a fundamental part of the game, and have them keep a screen linked. Or log more succinctly at possible failure points instead of all the time everywhere, and have users screenshot their lua chat. Or log to lua chat only after a failure (xpcall it). Or log minimally into a databank, which the user probably already has connected as part of the script, and setup a button for it to output to a screen if they connect one later. Or if out of slots, provide a companion debug PB, which reads from the shared databank one line at a time and draws logs on a screen. Or use a companion PB which links to whatever couldn't fit, and relay data/commands into/out of a shared databank, so that the main unit has a free slot to use for a screen. But it sounds like the underlying problem is that you are simply logging too much data, so much that it can't be handled by anything other than direct file I/O - which is one of the things this change is meant to help avoid, when excessively large log files can impact performance and fill up a user's drive without their knowledge. If you log less, lua chat as it is should be sufficient Exclusive lock is sort of valid, except it doesn't solve the problem of scripts (hopefully accidentally) filling up the drives of users via logfiles, which is a massive security flaw - spamming and filling the hard drive so would crash DU at least, and probably allow for other attacks depending on how the overflow is handled. You really can't just let random internet users write whatever they want to your hard drive Copy to clipboard from lua chat would be nice as a whole, but not having it is a very minor inconvenience, considering all the immersive, in-world alternatives

This is long overdue imo. While some people might find ways around it, with the functionality 'removed', those people can be banned for their actions. While many may keep their scripts private, the most problematic example of a nefarious script is one that transmits data between players - requiring trust of two or more players, that neither reports the other. Orgs that use these sorts of scripts either have to never recruit people again, or be very careful about it, and even an old veteran who got mad at the game and org could report the org, getting all members banned Risking a ban of an account that you've invested so much time into hardly seems worth it, and as a whole, very few people are willing to use bannable exploits, compared to the number of people willing to use vague grey area tools Also, most workarounds mentioned are very detectable. Anything that uses the lua, such as drawing QR codes or logging via invalid flush calls, is pretty obvious if NQ were to receive a report and check the lua on a player's control units - and might could even be detected automatically in some cases. Otherwise, very few legitimate uses will be impacted. The logfiles themselves will still contain things like market data or MU data by the sound of it. Something like physics data collection, or item/recipe data, can log to a string and into a screen instead, to be copied out on a case by case basis. Logging from lua script to file every tick is no longer possible - but shouldn't be, because that results in some very inflated logfiles that can cause slowdowns for users in some cases, and if done maliciously, could result in filling up a user's entire disk. Logging to a screen or databank would be more appropriate I do agree with Arch, though; this is only one step in the right direction. The logging as a whole needs to be trimmed drastically - they are massive, tend to have many meaningless lines that occur every tick with the same data, and a lot of the things logged can likely provide info that you wouldn't want people to extract from DU. I think the best strategy isn't to make a list of things to remove from the logs; instead, make a list of things that actually should go there, and remove everything else

I stopped playing mostly because there's nothing to do. It was a ton of fun at first, and I got hundreds of hours out of it, and treated it like an MMO; started groups, met cool people, learned the game. It even took months to really learn it and see and do it all, before schematics. But, only months. Even if NQ finishes everything they plan, there's still no replayability, or even reason to play. MMOs generally have some sort of, end-boss, goal, or generally some way to 'beat' the game (usually multiple). Maybe you play because you want to level up and become really good at some skill, but even that isn't there in DU. There's just no reason to play, except to make quanta so you can have quanta. The only real potential reason to play is Orgs and PVP - but PVP isn't really in a playable state, and won't be for a while. It's all just far too slow and time consuming to be enjoyable And then the creative aspect is the other reason, and that one pulls me back every now and then. But I respec'd into industry after 0.23, and don't have the shipbuilding talents, so it's pointless for me to try building them. I've done it before and gotten putdowns from others, but then it comes back overtuned and not efficiently balanced like I want it to be - and usually impossible to really modify, when things like atmo engines love to clip into eachother when you pack them in, and can't be replaced without removing them all But I've setup a new set of talents in queue, and once I get a decent level of bonuses on shipbuilding I'll probably hop back in for a while and have some fun with it. In a month or two...

Damn you people are whiny. This change is awesome. Docking is simplified, not made harder - much better than the maneuver tool jankiness. Though floating 'docked' ships may look a bit odd. The only form of 'boarding' DU has today is where you take an alt and logout on someone's ship when they're not online. Which part of that is fun? It is very nice that NQ has finally cleared that up, so people like Markee aren't constantly being harassed, and until we have AvA there's no downsides. We may see some changes once AvA is in, who knows

Nice work communicating with us, this is exactly what we asked for. Some people are still mad apparently, I'm not sure what it is they want now, but this layout of the planning and design decisions of the team is great. Looking forward to giving more targeted feedback as these new things hit PTS (still waiting for screens...)

We'll see how it goes. I was working on a framework that did much the same thing, tbh it's crazy that we don't have a proper object-oriented UI framework yet. But they may let us specify "class" and "style" tags as parameters, who knows, we'll have to wait and see. If we can get those, we can retain full functionality, though it will take some rewrites. But as a whole the new system should be much cleaner on code size too, HTML strings were un-minifiable, so things like SagaHUD should actually end up with a lot more space after the rewrite

At first glance, I'm not sure this solves the problem. Sure, clients can databind to a state, but the clients still have to be sent the data. It synchronizes the client's UI vs the client's game, but the client's game still has to get the HTML from the server, which is (supposedly) the problem

Wait. Did you... actually print this out and take a picture with your phone? I am impressed. Whether you did or didn't.

You guys get 100kb? I get 49kb... Interestingly, [img=url here ] Makes it show up in preview, but not in the actual post. And if you choose the thing to Insert Other Media and try to give it a link, it won't work in the original post, but works if you edit it

Yeahhh... I like to hope that he listens to his devs. But, that's not the gist that I get

Long quote, trimmed it out but. I understand that they have an obligation to release the game due to Kickstarter, and an obligation to vaguely include the concepts they claimed on the page. They have done so, and will continue doing so, or face legal action (of course). There is no obligation for these gamedevs to listen to non-gamedevs about how to make their game, though, just because those people paid money. Now I do understand the feeling that, NQ is not listening to anyone's feedback, for anything, ever. Because they're totally not. But they're not obligated to, either. They are gamedevs who assumedly have some experience in this field, those of us who are not MMO gamedevs need to extend a bit of trust. If it's frustrating for a kickstarter backer, because something is not implemented the way they wanted, as long as it is implemented, then NQ has fulfilled their obligations. Hopping onto the kickstarter, beta, etc early doesn't make opinions about gamedev any more or less valid. New players are just as useful for getting feedback, if not significantly moreso because they don't have a lot of hangups and old grudges about things NQ has done in the past. So yes, if we want this game to be good? Ignore the old players who are just grumpy old men (I'm one of them most of the time), bring in new players, and see how they like it. The old players in a beta are never going to be happy - an MMO is a huge investment of time and effort, and even a small change will mess something up or invalidate someone's efforts. Eventually all of the old players will be salty about something, or will get bored, and that's that, and NQ is under no obligation to do what those cranky old men want when they start wishing for the good ole days where they didn't have to buy schematics. Any game, especially an MMO, needs a constant influx of new players to provide fresh feedback and to offset the number of players that finished or got bored with the game. Only thing is, I'm pretty sure NQ won't listen to new players either. So, let's just hope they know what they're doing

Well yeah, I also have several hundred hours of playtime. I still don't think anything he said was wrong or inaccurate. I mean, what even are the proposed problems with what he claimed? He says the planets are more alive than ever, well, they are - there are more constructs and signs and org advertisements than ever at the markets. Big orgs with production lines and mining trips? Yep, those definitely still exist, and definitely grew over months. If he is even aware of the die-off (may have been a solo player), it doesn't invalidate any of the claims anyway

How are you supposed to bring people back? They played, they got bored, they quit. They paid their subscriptions while playing, and afterward, sure you could say their money is being used to make a game for other people. But I mean, they paid for the subscription knowing it would expire. There was no guarantee that paying means the dev team will do exactly what they want. And I am quite sure that if the game were rolled back to prior to 0.23, it wouldn't help the player counts, because prior to 0.23 is when most people quit. We got to endgame easily in days, within weeks had a factory producing every item in the game, and within a month we were finished and had experienced all content in the game. In the orgs I was in, there was one or two people upset about schematics - the rest were gone before they ever came out. If the industry and PVP updates weren't enough to bring them back, then what next? Let the game continue to die, not bringing in any new players, while we wait and see if atmo PVP convinced them to come back? Or, just advertise to new players who haven't already experienced the whole game