Ripper

At least starting out. My bet is once the initial game is built, you're going to see a lot more content. Heck! I'm wondering how much of that can be done vai scripting.

Pacific time is 8 hours behind GMT. Where do you live?

I wrote that wiki. So, don't read too much into it. There hasn't been any clarification on whether a stargate will be "multi-gate". I just rephrased a post from Nyzaltar. I'll remove the word "two", until we know for sure.

Latest twit is the show starts at 11:30.

I hadn't considered this. Nyzaltar said there would be a difference between planetary atmospheres and empty space "atmosphere". Will every planet have a planetary atmosphere? Will they be identical? Will some be toxic? I don't see the difference between a toxic atmosphere and empty space "atmosphere" - Both will kill you

I thought I'd go ahead and repost the information about E3. JC Baillie will be on stage on Monday, June 13th at 12:00 Pacific Time, and you can watch the stream on http://www.pcgamingshow.com

Theres no difference between one construct or another. So the shielding of your base will use the same technology as that of your ship.

If they can get the sandbox off the ground. and then possibly some wildlife.. Once they iron out the kinks and have a good revenue stream, I could see them adding a civilization in a corner of the universe for us to find.

Saffi brought up an interesting idea in another thread regarding mass. We know the physics model won't be completely newtonian. If they associate a " ship tonnage" value to the core unit, which would consist of the mass of all the elements attached to the core. This value could be represented by a sized blip. If you add in emissions as "modifiers" as well as distance from target, you could change the size of the blip. ("blip radius" = tonnage * "EM sig" - distance)

I'd be interested in how NQ implements sensors. If it's just a coordinate system, then there's not much to cloaking. But think about ship emissions. Visible light EM signature Heat signature Cross section (radar signature) I honestly doubt all of these features will be implemented, but it would be cool to be forced to cut all of these signatures in order to smuggle something past someone.

Excellent Post!

No problem. I'm just trying to see things from a granular level. BTW... Nyzaltar said fuel WOULD be a factor with FTL travel between star systems. Oh, and I appreciate the effort you put into that post.

Maybe this is too complex. What is required to be plugged into a thruster DPU slot for it to function? Does it need power from a battery or reactor? Does it need fuel? Does it need to be attached to a control unit? Does it need to be attached to a cooling unit? What is its "health" and how does this affect performance (loss of thrust, more fuel, power, or heat)?

You are a bad man....

Thanks Nora. Nice list.

Does EVERY thread have to be about elements? This thread was SUPPOSED to be about the game logic.

Yeah, At the moment, I'm speculating upon the actual game variables. There are plenty of threads on building different constructs and different elements. This thread is more about figuring out WHAT we have available at our disposal to script with.

Klatu is correct. The LUA devblog indicates we can create "Components", that contain our scripts. I would imagine a component is like an electronic device with an embedded operating system.

I would be disappointed to find out weapons don't overheat. Oxygen is interesting. Some sort of life support. You're right about vectors (thrust and controls) Some sort of nav display would also be needed, but I would think thats an element not a depletable resource or variable.

I've been thinking about variables that are required for space travel. For any vehicular travel for that matter. Here's what I currently have: Power Fuel Data Heat Ammunition Health Mass I'm also interested in any other suggestions that I may not have though of. So lets go over each of these. Power - specifically electrical power will need to be provided by a battery, reactor, or generator of some sort. Fuel - We already know fuel is a thing. Nyzaltar has indicated it would be used when traveling between star systems. Data - We know DPUs are in use. The question here is how are elements connected, and is there a bandwidth cap. Heat - Heat is a problem in space. Its not easy to get rid of in a vacuum. Possibly some sort of radiator or disposable heat sink Ammunition - A given, whether its a laser pulling electrical power, or a rail gun with physical rounds. Health - Every item will have some sort of health whether its something like glass, or heavy armor Mass - We know that some sort of newtonian physics will be used, but a foundational element of that is Mass. I would expect a larger ship to be harder to accelerate than a single seated fighter. Does anyone have any other suggestions? Nyzaltar, is it too early to get confirmation of these variables? Thanks

I would think mesh based elements could be repaired, unless they're entirely destroyed. This wouldn't require a blueprint, just the drone detecting the damage state. In fact, all voxel elements could be repaired unless completely destroyed, without the blueprint. But, repairs of destroyed voxels would require knowledge of the original construct.

I would think repair drones would need a copy of the blueprint in order for them to know what to fix. These types of details would be specific to the ship, and would need to be hard coded into the drone. Therefore, a builder would need to supply the drones with the ship. It IS interesting, and replacement drones would need to be purchased from the builder. Thereby, generating another stream of revenue.

I'm interested in the possibilities

Nyzaltar has said that there will be both jetpacks for atmospheric and MMU (Manned Maneuvering Units) for space based maneuvering. As far as moving without a MMU, nothing has been said.

Hey Zen, I know you're excited about this game, and its easy to project the problems of other game developers onto it. It appears that the majority of forum members are aware of the other projects and the challenges they're experiencing, so I'm sure NQ is aware as well. The "Project Charter" will have all of the features and goals that were initially stated. You and I may not ever see it, but we can get a good idea of what is in it by reviewing the details of the Kickstarter campaign. Scope crepe comes in, when you don't have a good project manager. There will certainly be revisions and addendums to the charter. Some may be critical, and delay the initial release, but a good PM will make those "additional features", future expansions. But your suggestion shouldn't be dismissed outright. At the moment, we're "Pre-Alpha" so things a pretty fluid. Feel free to make recommendations. They can easily be added to the project before Kickstarter. As for the economic viability... JC Baillie is an entrepreneur. He already owns other companies. I'm confident he's aware of the demand for the project he's developing. He's already heavily invested in this project, and I'm confident his business model has been heavily researched. Zen, Here's a question to you... Since all the other "sandbox games" have a scriptable interface, why should DU hamstring itself by not providing a common feature? I would expect not providing a common feature in your product, would turn off more customers than it will generate.