Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Alpha

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Dimencia's Achievements

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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...
  10. 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
  11. 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...)
  12. 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
  13. 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
  • Create New...