Jump to content

Jeronimo

Alpha Team Vanguard
  • Posts

    407
  • Joined

  • Last visited

Posts posted by Jeronimo

  1. What Shynras says is coherent there shouldnt be any game curency, because too limited, but player made trading might naturally starts with any kind of matter, skill, creations, then derive to something that most people will be looking for but not limited to.

     

    If it is limited to only gold, a matter that is naturally gatherable, we will certainly see chinese coming, devoring planets and start spamming chats for real money

  2. The problem with that video is that its not voxels its a 3d scan of an area taken as tiny points of data and then converted into a 3d mesh and then streamed from some data source to the graphics card.

     

    its 100% 3D pixels, how they call them

    = Voxels

    watch carefully from minute 2.00

  3. 25cm is a heck of a lot smaller than most voxel building games. Add that in with dual contouring/ surface-to-surface feature and I think you underestimate peoples creativity if you don't think they can make furniture with that.

     

    DU's voxel system is ambitious enough as is. Wait another 20 years and we might get a game with voxels at the atomic scale :P

     

    20 years you said? later or before?

    voxels are far beyond you might thought

     

  4. In the kickstart promotion video, at 0.50min, JC mentioning that "you can build anything you want, space ships, cities, orbital stations, there is no limit in size"

     

    Jc mentioning here the infinity big, from voxels of 25cm

     

    What about the infinity small? or at least smaller than 25cm?

     

     

    NQ is missing something in the building part, 25cm voxels will not allow to build a chair, a table, a lamp, a frame, or any decoration objects, to put in (and in fact the only things you can build) empty space ships, empty cities, and empty orbital stations

     

    Its like, think big, look at it from far, and forget about details

     

     

    The content of DU is pretty well thought in global, at the scale of civilisations organisations, but what about in details, at the scale of one player?

     

    What will one player see ingame?

    Very detailed textured mesh based elements stuck on very contrasting flat voxel builds?

     

     

    NQ shouldnt forget who will pay and play, who they are targeting when they talk to builders and coders, to lot of people who spend their days on 3d modeling softwares pushing the latest technologies, day by day, making scenes more and more realistic that you cant make anymore the difference.

     

    I m talking about gamers who are also architects, interior designers, industrial designers, graphic designers, CG artists, animators, developpers, coders etc...

     

    Is DU going to be the game for gamers who grew up with 1m3 blocks in minecraft, who got maturity now to play with 0.25m3 voxels?

     

    NO right?!

    DU isnt based on java and still have a bit more than 2 years of development

     

     

    And i think the community should keep in mind to push further and further the possibilties of the building tool of DU to make it the greatest sandbox of all times

     

  5. The client will obviously have MORE data than we have on screen. This way, it will show the positions of objects outside of our vision. I would assume this would include every object up to deep space scanner radius. The network code may support more than that, but I think it would be a waste of bandwidth to send the position of everyone. Who cares about the bloke two star systems away?

     

    But how does NQ protect that information from being exploited?

    maybe just by checking all game files before game starts, to be sure the client isnt modified

  6. That idea is great, but please note that sensors are not using magic to detect, they use EM waves, and those can be absorbed and/or reflected and/or detected.

    In the case of detection, pure passive scanners (like cameras basically) can be used to prevent detection, but those give quite lower resolution or ark of detection.

    You can detect active scanners with active and passive scanners, because those light up in the direction they detect in.

    then nq will need to implement deflector, absorbator, reflector elements... that would be interesting

  7. Please define "it".  Because your answers are obviously not clear.

     

    Thanks, I've thoroughly read the LUA devblog.

     

    Ok, your topic is interesting, so i m not going to talk about anything else than the sensor element provided by NQ

     

    I m not 100% sure of what will offer this element, but it might be very simple, and only do detection within a spheric range, and transmit a list of IDs and coordinates to your DPU that is in the middle between this sensor and an other element such as a firing barrel, and the whole thing together would make a turret.

     

    In the DPU, you will be given opportunity to filter the detected list of IDs by adding some LUA code lines

    It will be up to you to design that filter, and giving it a shape of cone or donut by writing down the desired expression

     

    example: (very simplified filtering script)

     

    {if (detected xyz) < (donut shape expression xyz)

    detected xyz = TRUE ;

     

    then

    send message to barrel element = look at xyz;

     

    then

    send message to barrel element = fire;

     

    else 

    detected xyz = FALSE ;}

     

     

    but to be honest i would suggest to use a more simple volume than a cone or a donut, but more spheric or cubic shapes

    would simplify a lot its expression

     

    So as conclusion, your topic is already a possibility given by LUA, which NQ wants us to improve

    Thats why i said if you make it you ll be rich, because all the graphics you posted have a volumetric expression with xyz, but freaking complicated

  8. You're confusing a LOT of premade Elements provided by NovaQuark.

     

    1.  A radar display is NOT a radar sensor

    2.  A radar display IS a premade element provided by NovaQuark

    3.  A sensor IS a premade element provided by NovaQuark

    4.  A sensor "senses" objects within its field of influence

    5.  The ONLY element YOU can program is the DPU.

     

    I have no need to define a "cone" and detect whats within it.

     

    So here's how it works.

    Sensor provides list of ObjectIDs to DPU

    DPU Filters list of ObjectIDs and specifies Friend of Foe (and any other filter defined by player)

    DPU sends entire list to RADAR_Display

    DPU sends FOE list to Turret

    RADAR_Display Displays ALL information handed to it (and hopefully can color code)

    Turret uses its OWN sensor to "see what it can see" and what's in range

    Turret cross references its object list with the FOE_List

    Turret Fires

     

     

    1. I was replying to your dream of what sensors should look like:

    And my answer was very clear, its not NQ that will do it, but yourself by working on it a little bit

     

    2. I advice you to have a newer look at interaction between elements and dpu in the devpost about LUA

     

    3. I will remember never purchasse anything that you scripted

  9. There's no geometry involved for the end user OR the LUA programmer.

     

    A turret only needs to know the target is within its area of influence.  The Turret element has the code to actually target and fire upon the ship.

     

    A RADAR display ONLY needs to know a list of "ObjectID's".  All the geometry would be performed within the RADAR element itself.

     

     

    Yes its simple, but the radar itself may sens every ID's within its range, a spheric range, and it will be your job to filter desired ID's, by comparing their coordinates with your algorithm

     

    If you take off this part from the LUA then there is no use of it

     

    And wrong, there is geometry in the LUA, since ID's coordinates are in 3 dimensions, X,Y and Z

    So for your example you just google the expression of a cone, write it down in your filters, and collect a list of TRUE and FALSE and assume firing on the TRUE or FALSE list

  10. I was under the impression the planet was scaled down for presentation purposes. I agree it should have something too it.

     

    I havent played much SE since planets but it seemed they had a good feel to it. climbing in altitude was a challenge. (well for me playing 30 min on the new system)

     

    Not sure where i read or listen to JC saying the planets size will be scaled to the one the demonstrated, about 100km diameter

    But nothing mentioning its atmosphere

  11. Here's MY understanding of "Tabbed Targeting":

     

    The servers provide XYZ positioning data for all objects.  (my guess is that means Core Units or Avatars)

    The client uses that information.

    The sensors would be client side.  If an object is detected within the "Area" of the sensor, it would be acted upon.

    The sensor doesn't need to provide positioning, because the client already has it.

    The sensor just returns "ObjectID".  (which simply means ShipID TRUE or AvatarID DETECTED)

     

    The DPU then acts upon the information.  It may display it's XYZ coords. on RADAR, open a door, or activate a turret.  The actionable data is "hashed" in a manner completely defined by the player's DPU.

     

    You may script yourself your sensor, and cull all wanted or unwanted sensed targets within an algorithm

     

    That a quite tricky geometry + math algorithm calculation, but once its done and you understood how it works, you might get rich selling it

  12. After beeing stunned by last presentation video there are still some little gameplay details that bother.

     

    The planets atmosphere thickness is for me (at the present moment of the demonstrations) a lot too thin, and seeing mountains top reaching the space, or a ship quiting the surface of a planet in 10 seconds, breaks the height realism and the inimaginable infinity of the voide. 

     

    I "personnally" think the atmosphere thickness is a very exiting moment when you get through it, from both sides

     

    Either from a planet where you switch from the palpable to the intangible

    Or from that little cockpit in what we could have spend weeks without seeing a moskito, to the real ground and its beauty, with that moment where your ship is shacking as hell and flames blinding you.

     

    For now, impatiently waiting how this experience will be dealt with

  13. I would like to see invisible(or small enough) and very elementary active elements such as:

    - invisible hindges, rotation axes

    - invisible translation rails

    - invisible sensors

    - invisible particules box

    - ship piloting seat without cockpit

    - engines reduced to mechanic parts without hull

    - cockpit ui elements separatly

    etc...

     

    all those to be able to customize better the look of my creations, not be constrained into a variation of possibilities

  14. I didnt mean that you change thr bump texture of that specific voxel (one instance every 25cm) but you draw vectors over the surface of the whole object, with arbitary start and end points independent from the voxel grid.

     

    a "sticker" system so to say with a bit of extra stuff to make it easier for everyone

     

     

    i hope it would be something like that otherwise will be difficult to paint our logos on our ships

  15. Most Voxel Engines support this localised bump-mapping of voxels. The problem is most of them don't supporrt altering one side of the voxels into a bump texture, they have to apply the bump-map in the entirety of the voxel itself.

     

     

    But given NovaQuark's ingenuity, I would not be surprised they'll add some weird ass bump-mapping tool that some "Sculptor" class can unlock to make wall-carvings by painting each voxel seperately.

     

    true, but you wont really mind if 5 faces are into the wall

  16. directly painting bump maps could be a bit heavy storage and streaming wise for the game.

     

    maybe a decal based system with some limited PCG for long stripes of something?

     

     

    premade infinitely stacking stripes of rivets, indents, bumps, seams, etc

    which you can apply to a grid 

     

    to be honest before the very recent video, i imagined could paint smaller pixels than 25*25cm, imagined it more like a grafiti spray tool

     

    but what you say is pretty consistant, adding with what captain said, just have to wait if they plan 25*25cm preset bump map, with only one rivet in the middle, so every 25cm you could put one

  17. Okay, since I clearly can't speak your way of lignuistic pattern, are you meaning you want to create a "brick wall" bumpmap for the game?

     

     

    Like, set up a 10x25 voxels wall, then apply a bumpmap to make it look like as if bricks make up the wall? Cause that is already a thing in most voxel games. A paint tool is for painting a voxel's color differently. What you are suggesting is simply a bumpmap preset ofr the voxels to have a certain look about them and it can be tied to a builder's skil ltree to have access to "prettier" bumpmaps.

     

    i am talking about player painted objects, that wont come with a default texture map, since you ll paint on it what ever you feel to, like paint a scratch, a rusty piece, a screw, a logo etc...

     

    Over painting the default texture will make object flat, unless as you mention, you bind to the whole object the same preset bump map, which might not always give the desired effect 

     

    That is the main prupose of the topic, an alternative to this preset bump map that was available already in sandbox games 10 years ago

     

    Example of level of details you cannot achieve with your solution, neither with the building tool:

     

    StandardShaderNormalMapAircraftSurface.p

  18.  

     

    In other news, I suggest a revolutionary tool. 

     

    Diagonal lines.

     

     

     

    There's no need for bumpmaps, a paint tool simply will change one of the six squares existing on a voxel's surface to alter their color. The material properties can remain intact. This can applied to morphed voxels, like parallel rectangulars in a slope.

     

     

     

    The voxels base size ll be 1m and 25cm, which are pretty big when you are trying to get into details, this because server side, it wouldnt support too many smaller scale voxels.

     

    The bump map is an alternative, but client side, to increase rendered details on any objects

     

    Think about it

×
×
  • Create New...