EasternGamer
-
Posts
141 -
Joined
-
Last visited
Posts posted by EasternGamer
-
-
26 minutes ago, joaocordeiro said:
Can anyone provide a picture or video of this tool?
I dont have DU installed.
It's not in game yet... watch the video provided in the dev blog
-
Skimmed the read, I was wondering if we could "export" a shape. So you can then "import" it by copying a string from somewhere. Could be extremely useful for Lua stuff as you could make something which generates the voxel format of a voxel you make on a screen or similar. And also just nice to have so voxel people can more directly share shapes.
- Metallical, Zireaa and Shaman
-
3
-
Hmm, just a note that information is an uncountable noun, so it doesn't have a plural with an "s", so technically the getConstructInfos(...) is not really right, It should just be getConstructInfo(...).
-
3 hours ago, Zeddrick said:
I just took in this one:
radar.getConstructInfos(<int> cid) : Returns a list of working elements on the given construct if identified.Is that going to give me a full list of elements on the ship (potentially hundreds of them) or just the same information we currently see in the 'info' section of the JSON for an identified target?
Extremely doubt it's anything more than what the JSON says. The update seems to bring function parity to the JSON data.
3 hours ago, Zeddrick said:[...] a radar.getMatchingTransponderTags(constructId) call to allow us to see which of the tags we programmed into our transponder match the target?
This would be cool and useful... especially since we now can set and get tags.
-
Intro
With the recent dev-blogs, I feel like there's been a change in attitude with Lua. Before, we basically never got changes to it or the changes were very minimal/incomplete. (*cough* character orientation *cough*)
But, now that we're adding a bunch of functions to Lua, so much so that it's starting to get cluttered with really long function names, I think a general structure change should occur. A perfect example is camera data.
Structure ChangeThe core unit, control unit and system basically are filled to the brim with functions that don't really related to them, especially system.
So, here I go with what I believe should happen:
The creation of a "Construct" default slot. (No links required)
The creation of a "Player" default slot. (No links required)
The creation of a "Database" default slot. (No links required)The creation of a "Elements" default slot. (No links required)
Construct Slot (moved to)This slot will handle everything to do with the construct, and only the construct. As the first dev-blog has shown, a fair number of things are irrelevant of the core, thus it doesn't quite make sense that we should still access the core for them.
For example, world orientation of the construct is irrelevant to the core, and even ordinary orientation is irrelevant to the core since it is based off the orientation unit, a gyro or core.However, data which is more core-related remains, like direct calculations/measurements that you would imagine the core making (velocity, acceleration etc.).
Player Slot (moved to)
This slot will handle everything to do with the master player, the player who has executed the control unit. As you can guess, a fair number of functions are placed on the unit because of this. But, it sort of makes little sense beyond the fact that the player activated, not to mention to access any player related info, they want to prefix every function with MasterPlayer, a perfect example of how absurdly long it is getting is unit.getMasterPlayerWorldForward(), now tack on camera to it... unit.getMasterPlayerCameraWorldForward(). You get the point.
Database Slot (moved to)
This will consolidate any thing that essentially accesses a database, static or otherwise, for instance getting the player name, position, etc. It will be similar to the Lua version in our files, but be entirely made of native code, instead of Lua. This should help with Database.lua's semi-redundancy and inefficiency, aside from code length contraction.
Elements Slot (moved to)
This will consolidate any general element function that is normally accessed by the core. This will remove the need to basically prefix stuff with getElementDATAById(uid)
Instead, you will simple say getDATAById(uid) or getDATA(uid)Keys
- Bad Name* (Italics, suffixed by one or more light yellow asterisks, name requires a change for consistency reasons)
- ? Dev Blog Addition (Bold, prefixed by "New" emoji)
- moved to (Colour coded, moved to another slot)
- Suggested Addition (Bold, green)
Core- getData()
- getConstructMass()
- getConstructIMass()
- getConstructCrossSection()
- getMaxKinematicsParametersAlongAxis(taglist,crefaxis)
- getConstructWorldPos()
- getConstructId()
- ? getConstructName()
- ? getOrientationUnitId()
- getWorldAirFrictionAngularAcceleration()
- getWorldAirFrictionAcceleration()
- spawnNumberSticker(nb, x, y, z, orientation)
- spawnArrowSticker(x, y, z, orientation)
- deleteSticker(index)
- moveSticker(index, x, y, z)
- rotateSticker(index, angle_x, angle_y, angle_z)
- getElementIdList()
- getElementNameById(uid)
- getElementTypeById(uid)
- getElementHitPointsById(uid)
- getElementMaxHitPointsById(uid)
- getElementMassById(uid)
- getElementPositionById(uid)
- ? getElementForwardById(uid)
- ? getElementUpById(uid)
- ? getElementRightById(uid)
- getElementIndustryStatus(uid)*
- getElementTagsById(uid)
- getSchematicInfo(schematicId)
- getAltitude()
- ? getCurrentPlanetId()
- g()**
- getWorldGravity()***
- getWorldVertical()****
- getAngularVelocity()
- getWorldAngularVelocity()
- getAngularAcceleration()
- getWorldAngularAcceleraton()
- getVelocity()
- getWorldVelocity()
- ? getAbsoluteVelocity()
- ? getWorldAbsoluteVelocity()*****
- getWorldAcceleration()
- getConstructWorldOrientationForward()
- getConstructWorldOrientationRight()
- getConstructWorldOrientationUp()
- getConstructOrientationForward()
- getConstructOrientationRight()
- getConstructOrientationUp()
- getPvPTimer()
- getPlayersOnBoard()******
- getDockedConstructs()*******
- isPlayerBoarded(pid)
- isConstructDocked(pid)
- forceDeboard(pid)
- forceUndock(cid)
- getBoardedPlayerMass(pid)
- getDockedConstructMass(cid)
- getParent()
- getCloseParents()
- getClosestParents()
- ? getParentPosition()
- ? getParentWorldPosition()
- ? getParentForward()
- ? getParentUp()
- ? getParentRight()
- ? getParentWorldForward()
- ? getParentWorldUp()
- ? getParentWorldRight()
- dock(pid)
- undock()
- setDockingMode(mode)
- getDockingMode()
- getCoreStress()
- getMaxCoreStress()
- getCoreStressRatio()
- All Events
*getElementIndustryStatus() -> getElementIndustryStatusById()
**g() -> getLocalConstructGravityIntensity()***getWorldGravity() -> getConstructWorldGravity()
****getWorldVertical() -> getWorldGravity()
*****getWorldAbsoluteVelocity() -> getAbsoluteWorldVelocity() (Swapping the Absolute Prefix with the World prefix sounds better and is probably more consistent)
******getBoardedPlayerIds()
*******getDockedConstructIds()
System
- getActionKeyName(actionName)
- showScreen(bool)
- setScreen(content)
- createWidgetPanel(label)
- destroyWidgetPanel(panelId)
- createWidget(panelId, type)
- destroyWidget(widgetId)
- createData(dataJson)
- destroyData(dataId)
- updateData(dataId, dataJson)
- addDataToWidget(dataId, widgetId)
- removeDataFromWidget(dataId, widgetId)
- getMouseWheel()
- getMouseDeltaX()
- getMouseDeltaY()
- getMousePosX()
- getMousePosY()
- getThrottleInputFromMouseWheel()
- getControlDeviceForwardInput()*
- getControlDeviceYawInput()
- getControlDeviceRightLeftInput()**
- lockView(state)
- isViewLocked()
- freeze(bool)
- isFrozen()
- getTime()
- getActionUpdateDeltaTime()
- getPlayerName(pid)
- getPlayerWorldPos(pid)
- ? getOrganizationName(oid)
- ? getOrganizationTag(oid)
- getWaypointFromPlayerPos()
- setWaypoint(waypointStr)
- getScreenHeight()
- getScreenWidth()
- getFov()
- print(msg)
- logInfo(msg)
- logWarning(msg)
- logError(msg)
- All Events
*getControlDeviceForwardInput ->getControlDevicePitchInput
**getControlDeviceRightLeftInput ->getControlDeviceRollInput
ControlUnit
- exit()
- setTimer(timerTagId, period)
- stopTimer(timerTagId)
- getAtmosphereDensity()
- getClosestPlanetInfluence()
- ? getMasterPlayerPosition()
- ? getMasterPlayerWorldPosition()
- ? getMasterPlayerWorldForward()
- ? getMasterPlayerWorldUp()
- ? getMasterPlayerWorldRight()
- ? getMasterPlayerForward()
- ? getMasterPlayerUp()
- ? getMasterPlayerRight()
- getMasterPlayerId()
- getMasterPlayerMass()
- getMasterPlayerParent()
- ? getMasterPlayerOrgIds()
- setEngineCommand(...)
- setEngineThrust(taglist, thrust)
- setAxisCommandValue(axis, commandValue)
- getAxisCommandValue(axis)
- setupAxisCommandProperties(axis, commandType, targetSpeedRanges)
- setupControlMasterModeProperties(controlMasterModeId, displayName)
- getControlMasterModeId()
- cancelCurrentControlMasterMode()
- isAnyLandingGearExtended()
- extendLandingGears()
- retractLandingGears()
- isMouseControlActivated()
- isMouseDirectControlActivated()
- isMouseVirtualJoystickActivated()
- isAnyHeadlightSwitchedOn()
- switchOnHeadlights()
- switchOffHeadlights()
- isRemoteControlled()
- activateGroundEngineAltitudeStabilization(targetAltitude)*
- getSurfaceEngineAltitudeStabilization()*
- deactivateGroundEngineAltitudeStabilization()*
- computeGroundEngineAltitudeStabilizationCapabilities()*
- getThrottle()
- setSignalIn(plug, state)
- getSignalIn(plug)
- All Events
*I got no idea what to replace those with, but the names are just weird, what's a surface engine, ground engine? Function name is super long.
Construct
- getWorldOrientationForward()
- getWorldOrientationRight()
- getWorldOrientationUp()
- getOrientationForward()
- getOrientationRight()
- getOrientationUp()
- getWorldPos()
- getId()
- ? getName()
- ? getOrientationUnitId()
- getMass()
- getIMass()
- getCrossSection()
- getLocalGravityIntensity()
Elements
- getIdList()
- getNameById(uid)
- getTypeById(uid)
- getHitPointsById(uid)
- getMaxHitPointsById(uid)
- getMassById(uid)
- getPositionById(uid)
- ? getForwardById(uid)
- ? getUpById(uid)
- ? getRightById(uid)
- getIndustryStatusById(uid)
- getTagsById(uid)
- getElementById(uid)
Player
- getId()
- getMass()
- getParent()
- ? getOrgIds()
- lockView(state)
- isViewLocked()
- freeze(bool)
- isFrozen()
-
getFov() - getHorizontalFov(bool)
- getVerticalFov(bool)
- getHeadlampState()
- setHeadlampState(bool)
- isSeated()
- getSeatId()
- getCameraView()
- getCameraWorldForward()
- getCameraWorldUp()
- getCameraWorldRight()
- getCameraWorldPos()
- getCameraLocalForward()
- getCameraLocalUp()
- getCameraLocalRight()
- getCameraLocalPos()
- ? getBodyPosition()
- ? getBodyWorldPosition()
- ? getBodyWorldForward()
- ? getBodyWorldUp()
- ? getBodyWorldRight()
- ? getBodyForward()
- ? getBodyUp()
- ? getBodyRight()
Database
- getPlayerName(pid)
- getPlayerWorldPos(pid)
- ? getOrganizationName(oid)
- ? getOrganizationTag(oid)
- getSchematicInfo(schematicId)
- getPlayerById(pid)
- getMasterPlayer()
- getOrganization(oid)
- getConstruct(cid)
Camera Data Explanation
The camera data is pretty straight forward. I made an code example and explanation before this mess, I'll just paste that here lol.
local player = player --> A tab which virtually represents the "player", it holds player related events and functions. local isSeated = player.isSeated() --> Returns true or false if the player is seated or not. local seatId = player.getSeatId() --> Returns the player seat ID if seated, otherwise nil. local headlampState = player.getHeadlampState() --> Returns the boolean of the avatar headlamp, on or off. player.setHeadlampState(not headlampState) --> Inverts the headlamp state. local camView = player.getCameraView() --> Returns 0 for first-person, 1 for third-person and 2 for fixed third-person. -- Consideration to have is that you can get into third person while using the normal avatar using an emoji. -- Why it is useful is so you can change the HUD you intend on using depending on if you're in those seperate views and if you should listen to mouse input for UI, etc. local camWorldUp = player.getCameraWorldUp() --> Returns the camera up vector in world coodinates. local camWorldForward = player.getCameraWorldForward() --> Returns the camera forward vector in world coodinates. local camWorldRight = player.getCameraWorldRight() --> Returns the camera right vector in world coodinates. local camLocalUp = player.getCameraLocalUp() --> Returns the camera up vector in local coodinates, relative to the build grid. local camLocalForward = player.getCameraLocalForward() --> Returns the camera forward vector in local coodinates, relative to the build grid. local camLocalRight = player.getCameraLocalRight() --> Returns the camera right vector in local coodinates, relative to the build grid. local camLocalPos = player.getCameraLocalPos() --> Returns the camera position in local coordinates relative to the build-grid (construct) center. local camWorldPos = player.getCameraWorldPos() --> Returns the camera position in world coordiantes. --<! Optionally, you could add a relative world position function which is relative to the construct center, but in world coordinates. Though, I feel it would be very niche !>-- --- Lastly, local camHFov = player.getCameraHorizontalFov(true/false) --> Returns the horizontal fov with a boolean parameter to determine if it is returned as a radian or degree format. local camVFov = player.getCameraVerticalFov(true/false) --> Returns the vertical fov with a boolean parameter to determine if it is returned as a radian or degree format.
Final Structure (No Formatting, mainly for glancing to see roughly the impact)
Core
- getData()
- getMaxKinematicsParametersAlongAxis(taglist,crefaxis)
- getWorldAirFrictionAngularAcceleration()
- getWorldAirFrictionAcceleration()
- spawnNumberSticker(nb, x, y, z, orientation)
- spawnArrowSticker(x, y, z, orientation)
- deleteSticker(index)
- moveSticker(index, x, y, z)
- rotateSticker(index, angle_x, angle_y, angle_z)
- getAltitude()
- getCurrentPlanetId()
- getConstructWorldGravity()
- getWorldGravity()
- getAngularVelocity()
- getWorldAngularVelocity()
- getAngularAcceleration()
- getWorldAngularAcceleraton()
- getVelocity()
- getWorldVelocity()
- getAbsoluteVelocity()
- getAbsoluteWorldVelocity()
- getWorldAcceleration()
- getPvPTimer()
- getBoardedPlayerIds()
- getDockedConstructIds()
- isPlayerBoarded(pid)
- isConstructDocked(pid)
- forceDeboard(pid)
- forceUndock(cid)
- getBoardedPlayerMass(pid)
- getDockedConstructMass(cid)
- getParent()
- getCloseParents()
- getClosestParents()
- getParentPosition()
- getParentWorldPosition()
- getParentForward()
- getParentUp()
- getParentRight()
- getParentWorldForward()
- getParentWorldUp()
- getParentWorldRight()
- dock(pid)
- undock()
- setDockingMode(mode)
- getDockingMode()
- getCoreStress()
- getMaxCoreStress()
- getCoreStressRatio()
- All Events
System
- getActionKeyName(actionName)
- showScreen(bool)
- setScreen(content)
- createWidgetPanel(label)
- destroyWidgetPanel(panelId)
- createWidget(panelId, type)
- destroyWidget(widgetId)
- createData(dataJson)
- destroyData(dataId)
- updateData(dataId, dataJson)
- addDataToWidget(dataId, widgetId)
- removeDataFromWidget(dataId, widgetId)
- getMouseWheel()
- getMouseDeltaX()
- getMouseDeltaY()
- getMousePosX()
- getMousePosY()
- getThrottleInputFromMouseWheel()
- getControlDevicePitchInput()
- getControlDeviceYawInput()
- getControlDeviceRollInput()
- getTime()
- getActionUpdateDeltaTime()
- getWaypointFromPlayerPos()
- setWaypoint(waypointStr)
- getScreenHeight()
- getScreenWidth()
- print(msg)
- logInfo(msg)
- logWarning(msg)
- logError(msg)
- All Events
ControlUnit
- exit()
- setTimer(timerTagId, period)
- stopTimer(timerTagId)
- getAtmosphereDensity()
- getClosestPlanetInfluence()
- setEngineCommand(...)
- setEngineThrust(taglist, thrust)
- setAxisCommandValue(axis, commandValue)
- getAxisCommandValue(axis)
- setupAxisCommandProperties(axis, commandType, targetSpeedRanges)
- setupControlMasterModeProperties(controlMasterModeId, displayName)
- getControlMasterModeId()
- cancelCurrentControlMasterMode()
- isAnyLandingGearExtended()
- extendLandingGears()
- retractLandingGears()
- isMouseControlActivated()
- isMouseDirectControlActivated()
- isMouseVirtualJoystickActivated()
- isAnyHeadlightSwitchedOn()
- switchOnHeadlights()
- switchOffHeadlights()
- isRemoteControlled()
- activateGroundEngineAltitudeStabilization(targetAltitude)
- getSurfaceEngineAltitudeStabilization()
- deactivateGroundEngineAltitudeStabilization()
- computeGroundEngineAltitudeStabilizationCapabilities()
- getThrottle()
- setSignalIn(plug, state)
- getSignalIn(plug)
- All Events
Construct
- getWorldOrientationForward()
- getWorldOrientationRight()
- getWorldOrientationUp()
- getOrientationForward()
- getOrientationRight()
- getOrientationUp()
- getWorldPos()
- getId()
- getName()
- getOrientationUnitId()
- getMass()
- getIMass()
- getCrossSection()
- getLocalGravityIntensity()
Elements
- getIdList()
- getNameById(uid)
- getTypeById(uid)
- getHitPointsById(uid)
- getMaxHitPointsById(uid)
- getMassById(uid)
- getPositionById(uid)
- getForwardById(uid)
- getUpById(uid)
- getRightById(uid)
- getIndustryStatusById(uid)
- getTagsById(uid)
- getElementById(uid)
Player
- getId()
- getMass()
- getParent()
- getOrgIds()
- lockView(state)
- isViewLocked()
- freeze(bool)
- isFrozen()
- getHorizontalFov(bool)
- getVerticalFov(bool)
- getHeadlampState()
- setHeadlampState(bool)
- isSeated()
- getSeatId()
- getCameraView()
- getCameraWorldForward()
- getCameraWorldUp()
- getCameraWorldRight()
- getCameraWorldPos()
- getCameraLocalForward()
- getCameraLocalUp()
- getCameraLocalRight()
- getCameraLocalPos()
- getBodyPosition()
- getBodyWorldPosition()
- getBodyWorldForward()
- getBodyWorldUp()
- getBodyWorldRight()
- getBodyForward()
- getBodyUp()
- getBodyRight()
Database
- getPlayerName(pid)
- getPlayerWorldPos(pid)
- getOrganizationName(oid)
- getOrganizationTag(oid)
- getSchematicInfo(schematicId)
- getPlayerById(pid)
- getMasterPlayer()
- getOrganization(oid)
- getConstruct(cid)
Ending Notes
It has taken me literally the entire day doing this, and even then I feel like I've missed a lot because I was literally looking at the entirety of Lua.
I was planning on explaining all the changes and stuff, but my head is about to explode from doing this the entire day so not gonna. Lol.
Tbh, if they implemented even a single one of these slots, I would be happy. I don't expect most of it to change.
I would also, personally, like if these changes came out gradually, if any. I think if camera angles are added though, we must at least get the player slot, or similar global variable because of how long the variable names will end up getting.Obligatory @NQ-Ligo and @NQ-Deckard, I wish you find this helpful, even if you don't add even 1% of it xD
Oh, and oops. Kinda broke the "one idea" rule... it's kinda a super idea though. Hope whoever od -
7 hours ago, JayleBreak said:
I submitted my suggestions at https://upvote.dualuniverse.game/suggestions/150263/support-lua-readwrite-access-to-voxels (do new players even know about the suggestion page?). Even the ability to query a voxel's vertex position would expose a capability that is not otherwise available and essential to building an in-game vertex editor. Of course, if NQ plans on releasing their own, there would be no need for it I guess.
I wonder about this... because I've asked for just getting the number of a particular type of voxel and they basically said an out right no because it's "not that simple". I don't think the voxel tech is something remotely manipulatable by the Lua side of things or even readable... unless they have a way they store each voxel with a unique identifier or something is somehow useable.
It would be very nice, and really really powerful, but I have my doubts it's possible.
I suggest you make a post on the Github page for Deckard to comment on, when he gets time. -
8 minutes ago, AstronIsTaken said:
Simplest scenario:
1. Developer (me or someone working on similar tools) provides either lua code to interested Player or shares preconfigured programming board somewhere in game.
...I second this. I wanted to make a Discord bot for skills and such but I gave up because it would be a massive pain to export skills and make them from the ground up with their given effects.
-
2 hours ago, CptLoRes said:
DU already has a official feature up vote system https://upvote.dualuniverse.game/ that NQ is mostly ignoring.
And considering the fact that NQ is ignoring the official list, I am sorry to say it is unlikely they will care about another one.
Yes, but that is general game design and I decided to reference some already upvoted posts there. I'm not sure why they abandoned it, maybe something to do with JC leaving, but Lua is a little different. We have a Github to bring attention to Lua stuff. So far, some bugs we caught have been fixed and some of the things on the Github have been added.
Now we're allowing NQ Lua team to see what people want the most, and probably by that and how difficult it is to do (or implications of doing it), they will go by it. -
Hello there. In case anyone missed it, I'm running a poll for basically what NQ should probably work on next. Of course, they probably won't go adding a major feature out of the blue, but it should help them know what to prioritize.
Link: https://strawpoll.com/vk4u24pfd
I also linked discussions on each item, so if you haven't already, vote. You might be able to shift some stuff.
Currently 33 voters, I'm sure there are more of you out there. -
18 minutes ago, Doombad said:
Can radars be connected to programming boards or only seats? I don't think so from memory, but may remember wrong.
If not, why not? Connecting to programming boards would open up the option to build radar systems at bases, space stations, and so on. Would be fun.
Seats only.
-
I wonder with all these changes, could we be seeing more getData() data becoming functions, like for example for weapons?
-
2 hours ago, Daphne Jones said:
It would be nice if we could get planet positions and sizes too. Like a function that returns data about the most influential planet/moon atm (by gravity). Yeah, I have a script that has those hard coded too, but that's gonna be f-ing useless when the next system comes in.
The Atlas probably will have that data (I hope). Next dev blog will probably enlighten us more on it.
-
1 hour ago, Sawafa said:
What are time frames when all these Lua changes described in devblogs will be live? Is it weeks/months/anything else?
Question:
DevBlog#2 has Radar functions description. Is this the full list of functions for the Radar? I mean, now Radar has .getData() function, will it be still there when these changes will come to live?
I’d say yes since it’s more or less a generic element function, but @NQ-Ligo can probably confirm it for us.
But I wouldn’t use it if I were you. I would localise the functions you intend on using and iterate over the construct list. radar.getData() causes a massive amount of lag in the game because it’s formatting the entire data set into JSON and then we decode that JSON, causing even more overhead. It’s significantly worse using it so I would definitely avoid it.
I did a test for this btw. That single function caused 20ms of lag, this meant it actually caused the entire frame to wait for that to complete each time, meaning what should have been 30 FPS ended up being 15 FPS. This is in a 2000 core area, true, but it goes to show that it’s stupidly costly lag-wise.
-
1 hour ago, Daphne Jones said:
It's a lot cheaper in C and already being calculated there. Small differences matter when you're doing it every frame.
It is probably honestly not really worth it. Probably the entire calculation ends in 0.03-0.1ms. Absolutely minimal impact if done right.
-
1 hour ago, eviltek2099 said:
if you know then why the restriction?
Probably some pushback with exploit concerns or it's not as clear and cut to expose. Either way, Lua changes are always welcome if they standardize and don't limit, but instead simplify the process or expand what you can do.
If we complain too much, it will send the wrong message to NQ that "players don't want Lua changes", therefore no good Lua updates. We should only complain about things that limit us for no decent reason, like the nerf for transponders. That's my 2 cents.
I look forward to the future of Lua here. And thanks @NQ-Ligo for the response. I see that the dev-blog updated to reflect what I spotted, nice. And thanks for clearing that up with the construct orientation.- Eviltek2099 and UnCheat
-
2
-
Hi there, resident Lua programmer here... I have some questions probably a few others also have as well.
Questions
First Question:Quote- <vec3> core.getConstructOrientationForward() : Returns the forward direction vector of the construct in construct local coordinates.
- <vec3> core.getConstructOrientationUp() : Returns the up direction vector of the construct in construct local coordinates.
- <vec3> core.getConstructOrientationRight() : Returns the right direction vector of the construct in construct local coordinates.
This would imply that it would be a constant based off the image. Did you mistakenly say "direction vector of the construct in construct local coordinates" when it should've been "direction vector of the active orientation unit in construct local coordinates"?
Second Question:Quote- <vec3> core.getConstructWorldOrientationForward() : Returns the forward direction vector of the active orientation unit in world coordinates.
- <vec3> core.getConstructWorldOrientationUp() : Returns the up direction vector of the active orientation unit in world coordinates.
- <vec3> core.getConstructWorldOrientationRight() : Returns the right direction vector of the active orientation unit in world coordinates.
Is there one that is irrelevant of the active orientation unit?
Third Question:Quote- <vec3> unit.getMasterPlayerWorldPosition() : Returns the position of the player currently running the control unit in world coordinates.
The master player data, is this still for body orientation and position, or are we getting the camera data? I suspect it's the former for now since this was depreciating the old functions.
Forth Question:
Was going to ask something else but didn't have anymore to ask lol.
End Remarks
I honestly wouldn't mind a full Lua refresh to make things less cluttered. Like, using three functions to get orientation and these long function names could be slimmed down a lot.
For instance:<vec3,vec3,vec3> core.getConstructWorldOrientation() : Returns the forward, up and right direction vectors of the active orientation unit in world coordinates.
local forward,up,right = core.getConstructWorldOrientation() --Wham! One function.
Lastly, despite me using quaternions, I agree with the removal of them. There needs to be consistency and the three vector orientation system is much easier to understand and is also extremely easy to convert to a rotation matrix. -
Add some examples for that the UI should look like because it sounds a little vague to me. Some script UI's aren't that bad. I know from scripting it's just a limitation on time, implementation and probably performance. I think if you gave some inspiration of what something could look like it would help more. I find designing stuff is the most difficult part when you have to come up with something unique. You need inspiration from something.
-
-
@NQ-Deckard, as I mentioned in the DU Discord, this is sort of what I wanted to say.
Maybe phase two for PVP changes? Or perhaps is this what you already meant when you said by resistances? -
While shields haven't even been introduced into the game, it appears so far that they will appear to only posses resistances to damage types...
As evident here, though I could be wrong.
However, assuming I'm right, they could be even more involved and interesting.
Premise
First off, while no real energy shields exist, often in Sci-Fi, they're purely energy based and that protects incoming attacks either by deflections or absorbing attack at the lose of energy.
Since shields are energy based, they should have "affinities" towards different types of impacts.
Without any actual power system in place yet, shields are most likely going to be have some temporary system for power based off the core or the size of the shield.
With that in mind, shields which are designed for L core ships should only function on L cores. But... an L-core will probably have the strongest shield, so how do you balance L-core shields?
The SuggestionAs said before, shields most likely have a % resistance towards things like thermal, kinetic, electromagnetic and antimatter damage. It's a good start, but it could be better. Let's take a moment to think using Sci-fi logic.
Shields are energy based, thus, impacts which more closely relate to direct energy should be more effective than other attacks. This should in theory mean that lasers are very weak to shields because it is a pure energy vs energy impact. Lasers shoot photons of a specific wavelength and on contact with a surface, heat that surface up, vaporizing it. But shields could instead, through the magic of Sci-fi, absorb that incoming wavelength.
Different size shields would have a different tuned wavelength, which can't be changed.
Different size lasers will have a different wavelength and as such would perform better or even ignore a shield entirely.
Then, for other weapon types, physical projectiles should have more penetrating power or overall shield damage than other forms. Take for example rails.
Rails are meant to penetrate, thus they should do the same, doing moderate damage to shields while still doing damage to the underlying voxel.
Cannons and missiles should fail to penetrate but do more significant damage to the shield itself.
Lastly, as shield HP decreases, the chance of an incoming attack ignoring the shield should increase. i.e., at 10% remaining, one in two shots should ignore the shield and hit the voxel below.
Since that was a little messy to explain, here are two example scenarios.
Example #1 Ship A is an L-core with an L-shield, equipied with L-Lasers. Ship B is an L-core with an L-shield, equiped with M-Lasers. Ship B fires on Ship A, penetrating the shields slightly, causing voxel damage and a little damage to shield HP. Ship A fires on Ship B, no penetation but does more damage to shield HP than Ship B did. ... Ship B's shields will fail first, but Ship A has taken far more voxel damage. ... Ship B wins the fight as they switch to using L-Lasers once the shields are down. Example #2 Ship A is an L-core with an L-shield, equiped with L-Lasers. Ship B is an L-core with an M-shield, equiped with L-Rails. Ship A fires on Ship B, doing good damage to shield HP. Ship B fires on Ship A, doing moderate damage to shield HP and good damage to voxels below. ... Ship A's shield fails first, followed by Ship B's a little bit later. ... Ship B wins as it had received little damage to the underlying voxel while ship B was practically untouched until the shields fell.
-
22 minutes ago, Niemand said:
calm down m8. i did not say any of this
im just happy for an alternative
I was going to say some stuff, but realized it was kinda unnecessary. If you genuinely see Starbase as an alternative rather than the "be-all", then that's the right mindset.
-
50 minutes ago, Niemand said:
17th of june is the day DU will die.
Source please? Oh wait, you don't have one... you're referring to the supposed saviour who will blow Elite Dangerous, Space Engineers, Star Citizen, No Man's Sky and Dual Universe out of the water—Starbase.
I hate to break it to you, but you're expecting a newly released Alpha to literally be better than a game which has had significantly more funding behind it. Not all game studios are equal, but I guarantee your expectations are far too high to claim even remotely Starbase will kill DU.
Not hating on Starbase, but people are planning on jumping ship... to another, smaller ship, overload it and potentially sink it in the process.
-
1 hour ago, Atmosph3rik said:
The thing is, that the only thing that we have to measure a meter by in the game is a voxel. So making the character smaller, also makes a voxel larger, by comparison.
This, while it might seem to be the case, isn't. It isn't how projection works. All that's changing is the camera's position in 3D space, nothing else. You don't zoom in or anything. A voxel looks the same size as it would on any other player's screen if they keep their FOV and resolution the same. The only difference would be the relative angle you look at it from. Nothing else.
-
37 minutes ago, joaocordeiro said:
So you strongly believe that everyone that read the options would choose that option if they slightly disagree with both options?
If yes, how do you explain so many "comments" and only 3 votes on that option?
People generally like to comment. I like to comment. Some people will explain their choice in more depth, others will fight for their choice and argue with those that disagree with them, etc. One person can comment more than once as well. But, to look at it from your perspective, I see what you're getting at. It's like a "luke-warm" poll. Not many people really care what the sky looks like, as long as the game is fun. So they choose without really thinking too much about it.
I like the idea of a dark sky, but my reasons for it are weak and/or completely subjective. However, I probably won't be changing my mind.
The main issue is the DU needs to fix some more apparent lighting issues, like that light bleeds through voxels, where in other games it doesn't, and that your eyes adjust to "darkness" when you're still in a bright room.
But these are all nice-to-haves, and far from necessities.
Call for Demeter-related questions
in General Discussions
Posted
I somewhat disagree with point two. I haven't invested time in scanning, but if NQ made old scans useless, you would have literally thrown away tens of thousands of hours of other people's time who spent the time finding meganodes before. Maybe the best solution would to give a "hint" as to what the tile has, but not the actual values, but no one in NQ would have implemented something like because it's work that is only a temporary compromise.