EasternGamer

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.

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.

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.

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

Literally would make the problem worse in every way.

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.

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.

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

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.

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?

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...

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.

Don't think so since the roadmap put it on the no set release date area... maybe a middle patch?

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.

Already stated that you can use one screen, it just won't display.

What he was referring to, Deckard, was relating to my comment about possibly malicious uses for a camera that would allow you to change such things. But I told him in a PM that you can just put that behind explicit activation and it would prevent it. But should such a thing exist, limits would definitely need to be put in place, especially with a camera position set. I suggested it as a way to increase immersion which we could code on our side rather than waiting for NQ. Doing stuff that can increase immersion would help with a lot of the gameplay at the moment feeling very gamey at times. If you add on top of that, input exposure, you can even do stuff like "leaning" in Lua. It adds a new dimension, it would just need to be properly limited.

Holy wall of text... Dude... literally not a single thing you wrote here is relevant to his discussion. This is about the LUA ADDED in the next update. There is a separate discussion thread for what you posted. To my perspective, this is in line with the update, it's fixing long standing issues, at least temporarily until players find ways around it. After ZarTaen made the sound player, and mentioned the possibility of the exploitation potential, it was a matter of time for them to remove it. Which is a long standing exploit concern. Now, whatever methods they use will basically not be "easy", as much as people claim it will be. I don't even know where to start with making an OCR that can scan my screen, and most people don't. And anyway, it's not on NQ to counter such things. That is on Anti-cheat to counter. And on that note, not specifically referring to what you said really, there is literally nothing stopping you from going as far as to just hook up an external camera and pointing it at your screen to read a generated QR through SVG, to then perform some action. You can't stop it. I wouldn't know how to do it, nor would it be worth my effort, but you also can't seriously expect NQ to somehow prevent something like that. What NQ have done is prevent people like me from doing it. And what NQ are implying here is that doing such things aren't allowed and if caught, I doubt you will get off scot-free. And additionally it's not like exporting data manually has been disallowed, you can send a large amount of data to a screen unit and copy it that way if you like. Also, I would like to petition that NQ Ligo get a Discord account so we can talk to him more directly regarding normal Lua when he's available. He can then more directly address questions that pop up in Discord... but probably like Deckard wouldn't talk much.

Hello, and first off, thank you, thank you, thank you. Not only did you add camera read data, you also are adding sound support. Removal of the log stuff scared me for a second, but then I released it was only those methods that got removed, not the actual logs. I think that is perfectly fine now that you've added support for sound playing. Though, I'm sure many people will come out of the wood work to complain now that it's planned to be removed. However, what I wanted to say was the camera API could also be expanded in future. We only have read data, which is really good, but when someone brought it up in the post the other day, I actually started to realise it could be so much better as well. The idea is to give, at least, very limited control over the camera, or even better, full control over look direction. Here me out on this one. This is what I said before on the general discussion, but I wanted to add an addition detail I realised after I posted this. With the ability to control the camera, you can fix the very annoying issue for AR, and that is that it will always be one frame delayed. The simple reason is, you have control over camera data and the camera data you send will need to be used for the next frame, not the current one, exactly like AR. Thus, AR jerkiness is eliminated because the data is in sync. That is all I wanted to add to my previous post, but maybe someone else here can expand on what I've said with their own thoughts... making cinematic cameras through Lua could really help with RP videos... so yeah... @NQ-Ligo, I hope to see what you say with all of this, if there is some security concerns/exploit concerns... I think camera movement would be difficult to protect, but if you can control it such that it has a range of movement it cannot exceed, it can probably be solved.

AR Demo #1 (Damage Control) Not Available for purchase at this time: (On Main Discord, the video) https://discord.com/channels/184691218184273920/748572194463940759/839963470576222208 AR Demo #2 (Waypointer) Available for free on DU Creators: (On Main Discord, the video) https://discord.com/channels/184691218184273920/748572194463940759/852681427443384381 AR Demo #3 (Virtual Cockpit UI) Not Available at this moment: (On Main Discord, under Lua, the video) https://discord.com/channels/184691218184273920/748595338813898773/929053097475596369 These three currently only function well in first person and even then it required an annoying calibration step each time it gets out of sync. The proposed API means it will no longer need that calibration step and with luck third person will also be seamlessly supported. I'm currently trying to flesh out Demo #3 into a full flight UI system. @UnCheat also made one, but by a different method to me. Anyway, these are just a few of the useful applications. AR is the main one in my most humble opinion, but there are certainly other simpler applications. The camera API, in a nut shell, would basically tell you: where you are looking, and from where you are looking. NQ probably have a good demo to show other uses aside from AR. And yeah, one would hope it gives you the actual camera in every instance, even when doing an emote.

Thank you so much for adding this. A small set of us programmers have really wanted this, and now we'll be getting it. I plan to make full use of it in my open source API as soon as it is released. Finally, I can get third person working, if it is implemented as such. However, to expand on what the person said, which prompted your response, it is a nice idea to give--at least--limited control to the camera. Right now, the camera movements aren't that natural, they're immediate and very gamey, but at least with minimal control we can smooth out movements to be more natural, add things like negating headbob, or add jerking when a ship experiences high Gs. Maybe even allowing us to program basic "cinematic" camera movements for a slow and constant pan, or a smooth one. I'm sure it wouldn't be easy to prevent some smart people from exploiting this, or even easy to implement it at all, but it would certainly allow us to add QoL features you otherwise don't have the resources/priority at this time to do.

So, there was something who came up with an idea in the DU Discord about something called "mass lock". Essentially, the mass of the ship and the playing field, in combat, will reduce the max speed of a ship. Otherwise, max speed isn't affected. Only in combat does it change. So if you have a massive fleet battle with 40 ships, the effective max speed is heavily reduced for high mass ships and less so for smaller ships. The actual impact of such a massive change would be very difficult to judge. It could go really badly, go really well or have no or little change to PVP overall. Just wanted to jot this down.

The point is, comparing DU to HL1 is simply stupid because the one was done before voxel technology even was really a thing. 0.25m voxels are sort of a good medium to keep stuff cheap enough while making sense for a player to actually manipulate. Imagine if you had to do 5 times more work if the res was 0.05m... only a few people would actually want that level of detail.

No MU API yet, was talked about briefly in an announcement as the next thing their adding in Lua, probably the next update, 0.28.

Oh, and don't forget DU has a 5km render distance for ship constructs, and around a 50+ SU render distance for planets. I don't think HL1 can do more than 100 m What would be epic, however, was if you could configure a ship wide voxel scale size down to a certain value. But that would be extremely complex to handle in the backend and balance reasons..

Hmm, yes, it certainly sad... for HL1, it makes me wanna cry how beautiful DU is. The only similarity is that we have 0.25m voxels to work with. There is an absolute limit to the detail we can do... but you have to take a step back and think about this: not everyone has the ability or time to make a beautiful design and will just make a square hallway, no matter how incremental you make the voxel size. Also, I have no idea where you see a similarity in textures... When we get the vertex editor, it will be significantly easier to make things beautiful with no warping, but until then.... don't even dream of comparing HL1 and DU. I tried playing HL1 not long ago and got bored like 30 mins in with how repetitive it was and terribly the graphics aged. Lastly, all games that don't have voxels are fundamentally much easier to make beautiful because they make meshes from the beginning. Voxels add an additional step and layer of complexity to things before making the mesh the game uses to render stuff. The above is ODY's Rocinante. https://du-creators.org/makers/Objective Driveyards/ship/Rocinante