Jump to content

AzureSkye

Alpha Team Vanguard
  • Posts

    155
  • Joined

  • Last visited

Posts posted by AzureSkye

  1. I'm not sure I get what he is proposing... Does he want to link our Forum and Community accounts? I don't get why they are separate in the first place, so sure.

     

    But then I'd like to be able to have a separate page/forum profile for each of my characters. Oh, and one for me as the player behind them. 

  2. @unown006 I'd suggest deleting or editing your post to reduce confusion.

     

    Per the topic: I'd prefer to have something like @CalenLoki's suggestion and have to physically move cargo around if you don't want to do it "by hand". However, looking at how Space Engineers struggles to hand its merge blocks, I don't think we'll see this.

     

    More likely we'll have cargo containers and conveyors. It still requires engineering and usually creates weakspots, but it's a bit simpler programmatically. 

  3. 28 minutes ago, NanoDot said:

    However, history has shown us that "sandbox" games just don't appeal to the vast majority of players. Everyone of us will have their own pet explanation for why that has been the case in the past, and why it will be "different" with DU.

     

    But I don't think it will be any different at all, actually. To thrive in a sandbox, you have to be creative and self-motivated. You cannot sit back and just consume the entertainment provided by the devs. The vast majority of gamers want just that: they want to be entertained and given clear goals to attain. And it mustn't take too much time to get there...

    This is why I'm glad DU is subscription based. It's already heading up a difficult hill. 

  4. Had me worried for a minute that you were going to advocate for artificial benefits. 

     

    I quite like this idea. Especially that power generation should not be a trivial manner. However, I think that the largest ships should be able to carry a factory unit or two. 

     

    1 hour ago, vylqun said:

    In the new content update we learn about market Bots, where resources can be sold for quanta and elements can be bought (probably very limited after crafting is implemented, but maybe some of the most basic elements can still be bought). Those Quanta and elements aren't created from void and the sold resources can't spontaneously vanish. So if someone wants to place market bots in his base, it would make sense to require a trading hub element in the vicinity.

    You are confusing Market Bots with Trading Units. Market Bots do exactly that and make things appear/vanish out of thin air. They are NQ's economic regulation mechanism. 

     

    Trading Units just allow you to automatically buy or sell things. 

  5. Static constructs don't move. If you want to call it anti-gravity, go ahead. 

     

    Dynamic constructs do move. However, they will also have restrictions on what can be placed on them. 

     

    And since it seems we are going to have high impulse/high thrust engines, going straight to your destination, rather than computing a transfer orbit, will be the most common way of reaching a station. 

  6. After the rather poor reception of my propose sleep mechanic and more research into combat, I feel I can offer a unique spin on the idea of Food.

     

    First and foremost: Food should not be required to survive. This is not a Hard Core survival sim (though I wish it were, sometimes).

     

    My proposal is thus:

    • Food will give bonuses/maluses to stats. These bonuses/maluses will be in the single digit percentage ranges and will cover a few skills at a time, with one primary. (+5% shooting, +2% reload, +1% crafting, +1% dodge)
    • Food items can be combined to improve their "taste" and the bonuses given. (For example: Raw Wheat will give a small malus, raw flour will give a malus, but a cake will give a bonus.)
    • All food items will have "taste" profiles and modifiers. The profile determines what "taste" is added when combined, while the modifiers alter the "taste" of the other ingredients. (This will probably be best displayed as a radar plot)
    • All players will have a randomly generated "palate" that slowly and randomly evolves over time. This "palate" determines how much of a bonus is gained from the food. "Tasty" foods give bigger bonuses, "nasty" foods give maluses. It will take years before a "palate" noticeably changes. This will be shown in the UI when a food is selected. (General Bonuses * Palate modifier = Actual bonuses)
    • Bonuses will last for 3-4 hours, with a slight increase during the first hour and then a steady drop off afterwards. Maluses will only last for 30 minutes and quickly decrease.
    • Every food has a "satiety" value. You can only eat so much before you are full. Once you are full, further eating adds Maluses, rather than stacking Bonuses. The more you eat, the longer the bonuses last.
    • Spices will exist that have small "satiety" levels and limited "taste" profiles, but they will have large "taste" modifiers. (Don't like savory foods? Add cayenne pepper! Make it spicy!)
    • Finally, all plants will take months to grow and harvest, however between planting and harvest, the plants will require minimal supervision. They'll require more supervisor the less friendly the climate is to that plant. Harvests will produce a great quantity of food. (Farmer's should be able to explore the universe too!)

     

    The purpose here is many-fold:

    1. To encourage economic activity by creating an intuitive category of good. Most people understand food and how good eating is good for them.
    2. This idea is focused on organizations as the primary producers and consumers. A solo pilot isn't going to mind being a few percentages slower at mining, or reloading, or crafting. But on the industrial scale of large organizations, these foods will be very important to squeeze out every Quantum. Wars have been fought over spices and I see no reason DU can't be the same.
    3. I've always disliked games where plants grew very rapidly. To gather a large stockpile, you were constantly running from plot to plot, planting and then you only have a few hours before you need to go harvest everything. Plants take time and care. Insta-plants aren't fun.
    4. The random element to the food is because a) everyone likes different things, and b ) this way there will be no "best" plant. What's in demand will change with the seasons and the years.

     

    (P.S: Wooo! 100th Post!)

  7. On 4/8/2018 at 6:05 PM, Veld said:

    So like a fillet tool? A bevel tool would also be cool. Most basic CAD tools would be cool thinking about it. Like a hole wizard or an extrude tool for example.

    Honestly, I'm still holding out hope for a solid CAD implementation. Love me some constraints and relationships. 

  8. 8 hours ago, CalenLoki said:

    I've read and watched some NQ statements about CvC combat. And it seems that there will be localised damage (both voxels and elements). Maybe I watched something outdated? What's the most recent article?

    https://www.youtube.com/watch?v=efu_129hI9o around 9:45 to 13:00
    https://board.dualthegame.com/index.php?/topic/841-ask-us-anything-event/&tab=comments#comment-8072

    You, sir, are correct. I was thinking of debris and breaking apart ships. From this: https://www.dualthegame.com/en/news/2018/02/08/in-game-ama-feb-3rd-2018-transcription/

    Quote

    Kulkija: Will there be structural integrity?
    NQ-Sophon: You will have “holes” in the voxel structure when damage is taken, but no ship dislocation, which would be cool but taxing a lot on performance.

     

     

    I'm disappointed that the AvA combat is going to be a lock&fire system, however I understand the load issues when transversing servers. It just makes me very sad, because I love sniping. Hopefully, it's as transparent as they say it will be, and we can mount up miniguns against waves of infantry.

  9. 9 minutes ago, MookMcMook said:

    Are NQ still considering spin or not? I'm not familiar with the term skybox: Do you mean planets are stationary and the spin the sun around them or some thing like that or an entire volume around the planets or some other weirdness?

    https://en.wikipedia.org/wiki/Skybox_(video_games)

     

    That's exactly what I mean. So far, nobody has really found the trick to make voxels rotate without crazy calculations. The theory that always gets suggested is "frames of reference", where you only move a bound section containing the voxels. NQ decided not to bite off more than they could chew. I imagine that they'll give it a shot at a later date.

     

    (P.S: The + next to "Quote" allows you to multi-quote people in one post.)

  10. 1 hour ago, Veld said:

    What we know from our gravity analysis

    • Judging by the velocities and fuel time of the spacecraft in the videos, the delta-v supplied by the specific impulse must be huge. So huge it is plausible to simply make for the moon in a perfectly straight line. It is also important to note the planet, alioth, and its moon a very small in relation to our earth/moon pair and the distance between them is also very small in comparison.
    • When all the engines on a craft are turned off, standard Newtonian mechanics apply to it causing it to orbit around the planet. This is only in this context. For all we know the gravity field of the planet could become ineffective as soon as you start moving your craft around.
    • The sun and the planets do not move, only the planets spin.

    My hypotheses as to what the graph as whole represents, ranked in order of feasibility, is as follows:

    1. Gravity exists with engines on. The anomalous readings represent the vessel after rather significant changes in trajectory at points where velocity was low and high. At the lower velocity closer to the starting point at the moon the vessel made a change in course which required little acceleration because of the small velocity. Conversely, at the higher velocity close to the planet the vessel made a change in course which required a larger acceleration due to its higher velocity.  It can be argued that if the gravity of the two bodies was remotely significant, considering the pilot starts from the one of the poles of the moon, that he would veer way off course. But the ship is scripted so that when the pilot rotates the vessel all of the thrusters act to put it on the new trajectory, thus making larger accelerations. He clearly has a vertical booster and RCS. This would mean he would be accelerating downwards but the booster/RCS could easily compensate for the downward component of his acceleration. This is backed up by pre-alpha footage where you can see a ship’s VTOL thruster and main thruster acting in conjunction with one another. This hypothesis that gravity is acting upon the vessel is also backed up by the faction the gravitational pull is diminishing with displacement. In the video we can see the pilot does a roughly similar ‘jiggle’ before each of the points where the anomalies occur. It is larger at the second jiggle because the gravity is stronger and thus more acceleration is needed to correct the course.

     Conclusion

    • Pretty certain orbital mechanics still apply with engines on. Need to test the hypothesis and make it into a theory.
    • What is likely is a combination of more brake force and capped velocity in space vessels. A sweet spot between the two, so to speak, to make stopping easier but not exploitable
    • Unclear if fuel has mass. Need to test.
    1. This is sci-fi, overpowered engines are standard. It wouldn't be surprising if you could make a straight line to the moon. Though NQ may (hopefully) balance against that.
    2. It doesn't make sense to turn off gravity when a ship is moving, either from a programming perspective or an immersion perspective. While you'll save a few cycles, there are far bigger places that can get slashed first. Namely voxel interaction and manipulation.
    3. Planets don't spin. The sun is a skybox that revolves around the system.
    4. For your hypotheses: They'll probably have Air Brakes and Space Brakes. Space Brakes will only work in space. Air Brakes will only work in atmosphere.
    5. There is 100% going to be a speed cap. It's simply not possible to compute required physics over a certain speed.
    6. I believe NQ has said that fuel has mass and as it is used, you'll lighten up.

    You are going seriously in-depth with so few resources! It's pretty awesome to watch.

  11. @CalenLoki That's a very well written argument, but I worried you are getting into voxel damage territory. IIRC, NQ has said that they cannot afford to simulate voxels being destroyed or blasted off.

     

    Now, I strongly approve of the AP/APHE approach. With (probable) hitscan weapons, each voxel should decrease penetration, based on the armor value of the voxel. This would be countered by the penetration value of the ammo. If penetration value is too high, you go through a ship with little damage (unless your target is behind them). If it's too low, your shot lodges in the armor (potential reducing the armor value? Maybe tol much calculation) Each element along that hitscan should take damage. 

     

    With APHE ammo, the final element would take the brunt of the damage. Plus, some surrounding damage. 

     

    You could also have weapons have special effects, like Sharpnel against avatars, micro EMP to distrupt systems, or even heat damage to overheat the reactor/engines/weapons/whatever. 

     

    Ultimately, I don't see why we would need a lock on system. It'd be helpful for CvC, but AvA or AvC should be free aim. Simpler to account for and more fulfilling. 

     

    Edit: I critique you about voxel damage and then wander in and suggest it! *sigh* Round riddle ship corpses are JUST so appealing. 

     

    Edit 2: Lock on would help with lag compensation... 

  12. 1 hour ago, Veld said:

    I  believe JC used Desmos to make his graph and there is a certain mathematical operator I don't understand here. That little dot between the expressions.

    That's a short form multiplication symbol. 

  13. I quite like this idea, however I'm a strong believer in the "First Sale" doctrine. Once an object is sold, it should be freely modifiable by any further purchasers. 

    To wit: I love the idea of having Deltas, however I hate permissions preventing modifications.

     

    I think Blue Prints only need to have a Master/Copy designation. Masters can produce both Copies and more Masters. Copies can only produce the construct.

     

    Additionally, Deltas should be able to be made from any other Blue Print, but should still be dependent upon the original. The dependency should nest for each Delta made from another Delta. If someone has several Master Deltas, they should be able combine them together to make a new Master Delta. If someone has both the Original Master and Master Deltas, they should be able to combine those together to make a new Master.

×
×
  • Create New...