Jump to content

EasternGamer

Alpha Tester
  • Posts

    126
  • Joined

  • Last visited

Everything posted by EasternGamer

  1. Okay NQ. We should talk a bit about this vlog. As people have basically indicated, it was rather lacking. I think you've missed the point with it a bit. It was nice to know that an outer build grid visibility option could be coming, but the other ones you spoke about were really lacking in detail, so super superficial. However, unlike others here who just simply state that, I'll explain a bit how it should be explained. The main point: People don't like being treated like a bunch of idiots who don't know that more stuff = more lag and we try get 60 FPS with no stuff first before we get 60 FPS with stuff. It was really bland because it didn't actually show any video of you demonstrating a hotspot. If I were going to do the optimized section, I would have taken out my dev tools or whatever tools you have, and shown at Market 6 with a graph of lag and where those "lots of little things" on the graph were and how they contributed to the lag. Then you would cut to the developer giving a briefing on tracking down where the lag spike comes from, maybe adding further benchmarking points in the chain of code and then showing us the result. Then, they come back saying "now that we've fixed it, here is the result" and you show the result and how that lag spike is gone. Maybe even demonstrate that some things are not possible to realistically optimize due to engine limitations, or even display how many triangles the game has to deal with like in those UE dev videos. Of course, you won't post impressive numbers necessarily like they do there, but always explain that certain things are engine limitations, also re-iterating that moving to a different engine was considered but was not worth the additional complications and dev time involved in the transition. Hell, maybe even make a dedicated video to this section. The same with the small weapons, you should have shown some of those "tests" so we can see ourselves. Yeah, that'll open up for criticism, but you should then address that in the video saying that, to simplify and speed up the testing process, we had to make X and Y compromises. Oh yeah, and the audio was really poor.
  2. 2FA isn't particularly an important feature, but some people care about it. So adding it is adding "polish" to the game overall. If you think it wasn't worth their time, then that's your opinion. Some things are easier to do than others and add more polish than most.
  3. I believe the sun has been synced for some time now. In fact, almost 100% sure. I was watching a stream and the person was in the US, and I'm in an EU time, yet the sunlight looked the same on my screen as theirs.
  4. I'd like to have backup codes. I have lost my Discord account before due to my phone getting destroyed in a fire, and the only way I would possibly get it back was through backup codes which I neglected to store anywhere. So the addition of backup codes, something really long and unguessable or something, would be great option. It doesn't always have to be there, but just give me the option
  5. Why do people keep bring up this concept that Lua somehow has anything to do with any of the other parts of the game? Lua is it's own thing and I doubt the devs behind Lua have many, if any, responsibilities with other parts of the game. The reason us Lua people are always happy is because we never had any updates or changes for quite some time, and now we're getting them. And I love how you say "they bring very little to the game"... I think you're really salty or something. I don't know how many people use ArchHUD, but almost every ship that is after market has some alternative HUD that makes ship control better. And PVP HUDs that bring much more to the PVP environment, and AR systems to allow for 3D damage control or custom waypoints. Screen tech is like a foundational part of the game, you see screens literally everywhere. You can make minigames on them, literally. And yet, you say "they bring very little to the game". I have no words for you if you honestly think Lua developers in DU bring little to the game. EDIT: If you meant "they" as in NQ, I apologize, but if you meant us Lua devs, what I said above remains.
  6. NQ's wipe plan is the equivalent of an upper management saying to the game developers that, to fix all issues, you must permanently delete all the current coding base and start fresh with an entirely different game engine. You can use your old code, but it won't change the fact that you wiped out years of planning and implementation... and in a couple of years, it will be in the same buggy state, maybe a bit less buggy but far less feature rich. This is just so NQ can understand that people won't actually enjoy the wipe. Like how new interns will relish at the opportunity to rebuild the clunky old systems and enjoy it for a bit, they will soon feel burned out, while the senior dev team would have probably mostly quit and gone to a different job. It's an atmosphere that is kind of sickening. This isn't like removing a single system and improving it, like a terrain reset, this is removing everything placed and made over hundreds of thousands of hours. I'm sure a few in NQ have a similar sentiment about wiping personally, and a few just want a better place. Like the analogy I made in DU Discord, we, the players, all exist on a beach of sand, where we've made our sandcastles and some have vandalized others. Now two years later, the beach administrator, NQ, doesn't like the vandalism which has almost completely been eroded, but feels it is still not ready, and thus bulldozers everything while we just watch. They take a few pictures before destroying these massive sand structures and give them over... all for us to rebuild it? They added a few new features to the beach, a new hill here and there, but it's all just lifeless sand in the end... The feeling I get, even as a non-builder and Lua coder, is sickening. NQ, if you feel a wipe is absolutely necessary, give us some actual evidence and proof of that. Give us the PTS with all these proposed changes. If you are promising planetary improvements, show us them. You can't promise something a few months before release and wipe with no delivery. Anyway, hope NQ make the right decision.
  7. Let's preface this: I'm a scripter, I own minimal assets in the game, and my main enjoyment comes from scripting. The wipe has a very small affect on me, but that won't change my opinion on how terribly reasoned it is here and terribly unnecessary. Kurock's post says it all. They were so, so clearly biased in that post, it's like they already made their decision, and if our response is lukewarm, it will go through. They ignore major, major points on the pros for the no wipe and partial wipe, and they put the full wipe with the most pros, but they all say the same thing: Simpler. Based on how they did the other pros and cons, all they should have said was: Pros: Simpler for us to do Schematics are what caused so many people to leave, and they have left. Your comment on schematics probably revolved around the idea that removing them would somehow bring those people back. Newsflash, it won't. They have moved on to other games. Personally, I don't own a single subscription game where I would return to subscribing after so much time has passed. BS you say about a wipe is somehow required for removing schematics. They're just an item. Complete BS that you say you can't revamp planets. Even greater BS you say you can't rebalance the economy... do you even look at your in game economy? One update and 10,000 m^3 of honeycomb goes from 100 million to 10 million. That is where it should be. The economy is perfectly, perfectly fine. As Kurock said, leveling the playing field is a temporary concept that will disappear quickly. It's an MMO. You think someone who plays the weekends or once a month will somehow be on the same level as someone who plays several hours a day, every day, who knows the game already? Don't be delusional, please. DU is not like a game where wiping should happen. You've already implemented plenty, and many will say too many updates that make it so wiping is completely unnecessary. HQ tiles, tile tax and construct abandonment over time, just to name the ones that come to mind.. Those are systems that work. DU lives off player content, which is essentially what you're advocating to remove with a wipe. It's like saying: I let you build up my limbs over the last two years so I can crawl, and now walk. Now, I will chop them off for you so you can rebuild them better this time. Your post is not an unbiased opinion on pros and cons. Fix it. It is misleading. Some people who read it will not think critically about what you just wrote. Who the hell thinks no wipe will only satisfy "some" long term builders and traders... are you... actually dumb? A significant majority is a better word there. You wanna know something? Your wishy-washy response mostly advocating for a wipe is why some people don't want to invest time into this. And it is because you even brought up a wipe. You sour the waters and poison the air with having the idea about, even more so by your extremely biased post. You wanna see what I mean by a biased pro/con? Here's a great example: As you can see, depending on where you cut the cake, you can say a lot and steer the narrative, bloating reasons and diminishing others. This is, essentially what NQ have done with their entire post. This is all I have to say in this, post, I've spent enough time writing out the obvious. Kurock said it in a neater package, but felt I should elaborate.
  8. I don't mind the idea of construct mass reducing speed, however, I feel like a stasis weapon's effectiveness should also be tied into the relative masses of the two ships. It would make zero sense for a huge ship 100x the mass of a small fighter to have the same effectiveness. So, you can make a heavier ship with the role of significantly reducing the speed of a single lighter ship, and the lighter ship's stasis weapon would have significantly less effectiveness. This wouldn't make a heavy ship optimal though, since its base speed is already slowed, and it will still be way more expensive to build a heavy ship overall than a lighter one. And seriously, seriously, don't try set hard limits and stats on a stasis weapon. Don't make an L, M, S, XS when you can be based of a relative mass thing. It makes it much more sensible. Skills, of course, can factor in, but limiting it to a specific size of ship class and such is not optimal at all. If you do that, then at least have it so that an L has a maximum factor. I really don't see this as "difficult" to code for. Things like distance and mass are readably available and an equation can be pretty easily made in a few hours, and maybe a week later of testing the values can be fine tuned well. Lastly, will we see any Lua *read* data of the stasis weapon? Like how we can read gun data?
  9. Yes, and no. I'm not from NQ, so I wouldn't know the reason behind the limit being a specific number, but Lua is poorly made in a way that it's an instruction based limit based on Lua instructions, rather than actual time based. I know plenty of ways a script well below CPU overload can lag a client for longer than 5 seconds. As in, only one frame will be sent every 5 seconds. What I'm getting at is it may have been placed there to prevent it, but it doesn't necessarily prevent it if someone is intentionally doing it or unintentionally doing it. I, of course, won't say what will cause such lag on a public forum such as this, but it's not uncommon. Just as an example that won't cause lag but has a different execution time, but the same instruction count, is multiply and addition. A multiply operation at a CPU level is far slower than an addition operation. You can look it up. So is a division slower than a multiplication. It's an interesting thing really. Anyway, yeah, a slider would be great addition. If I want my game to burn, I want it to burn! XD
  10. It's a gameplay issue as well as a technical challenge. If planets moved, it would be more difficult to travel to them. I'm sure some people can make scripts, but the new player joining the game would have no idea what they're doing. Not everyone has a good understanding of planetary mechanics. Not to mention waypoints in global space become useless. It would also require redesigning very core features of the game. A game like this (planetary scale voxel based) would be a possibility only in the far future.
  11. CPU overload refers to an instruction limit being reached. It has nothing to do with your actual PC struggling. It's simply a number NQ have decided to lock down to some arbitrary amount. Damage Control is a complex script. The number of elements factors into the overload and a bunch of other things. Many of my scripts are highly optimized, and execute at 4ms, but will still overload at 5ms. Then other scripts execute at aa cool 24 ms and don't overload. The reason is because not all instructions are equal. Mine can still do more than a 24 ms script, but time and true CPU resources play zero part in any of it. NQ should allow a slider for the player to set their own limit.
  12. Never had this before and I have frequent power cuts in my area. I'm on a UPS now as well and not had this issue. I even have the UPS software installed so it's even directly interfacing with my PC. Oh, and maybe make a ticket so they are aware of the issue instead of posting on the forums. If they have seen the ticket and responded, then all there is to do is wait.
  13. In other words: Throw away 6-8 years of work and start again, only to have the exact same sentence be repeated in 6-8 years time. XD
  14. So no ceiling is good... great feedback. As a single player, you have cost involved in storing and network. You seriously think the server can realistically be profitable if you own 2000 cores? Every time some one doesn't have a ship cached, it has to be downloaded again which costs in networking. My M-core ship alone is like 300MB. If I slap that in a market for a bit have have players download it again and again, that cost piles up. And yeah, I do agree the limit is extremely low at the moment, but don't think NQ will suddenly say "Okay here's 250 cores for everyone". I would like 50 assignable per org with a max 100 assignable total with talents. There, I can get an income off the 50 other total by selling it to other orgs that need it for their projects, or if I'm feeling good, donating some to a few community projects.
  15. Hmm, so I'm gonna throw my hat in the ring here with a suggestion that could be combined with others here, which I didn't really read yet. What if you get 25 or 50 or even a hundred assignable cores, but only you can only assign half of that to your own org. So, if we took the hundred example, you would have 50 cores in your own personal org with a couple of players and another 50 for other orgs that aren't directly owned by you. This means you would have 50 that you could sell to other orgs at a more reasonable price than the current limit. It would also solve most smaller org's issues of lacking players for their projects because they could buy those slots. Or just downscale a bit. Getting people to either donate or sell their constructs could actually be more viable with basically having more assignable but less assignable to a single entity.
  16. You, my friend, are a very expensive player. I can understand this, of course, but if a single player can own 2500 constructs due to the current system, the costs way, way out weigh the amount they pay. The construct limits are almost certainly and purely because they were used to keep the game profitable. However, I do feel that the construct slot amount is quite low. I think 30 assignable or something would be more sensible, with maybe a max amount of 20 assignable per org so you are forced to assign it to more than one org. Almost no one will be assigning it to the current orgs cause why would they xD
  17. Even just entering a vertex coordinate manually would be good enough. It's still a manual process, for sure, but much quicker than dragging stuff around.
  18. I would have liked to have an export/import function for this. You could make a program help with making more mathematically perfect points and paste in the code for that vertex... or maybe just having the ability to type the exact value you want could be a huge help. I don't believe you can do that, right?
  19. There's nothing wrong with the cone game when I play it. You're probably misunderstanding that it searches the radius highlighted when you select the tool. Not the entire hex. So it's actually like the worst tool to use imo. It just vaguely points in the direction of the highest ore concentration in the highlighted area...
  20. On a separate note, I was wondering if it's possible to get if the character's light is on, I wonder if that is a "camera" property, if you get what I mean. Something like system.getHeadlightState() would be good. I bring it up for if someone wants to add shading based off an in game light source, you can model potentially the player's headlight light source, in addition to the sun's. And perhaps even knowing the sun's light direction vector could be interesting as well.
  21. Don't think so since the roadmap put it on the no set release date area... maybe a middle patch?
  22. The camera view is technically in line with what you see in the seat IIRC. It definitely is a pain though, but there are simple ways to counter it to have the HUD "symmetrical" for the player in the seat.
  23. Already stated that you can use one screen, it just won't display.
×
×
  • Create New...