Ripper

Easy, Weapons officer Smith, notices nobody is at the helm. He leaves his station, and takes over the helm. Now, the weapons script is not working, and the piloting script starts working on <player 2>

There isn't just ONE script per ship. Think of each station as a kiosk or ATM machine. Each machine is capable of performing some function. Weapons, piloting, etc.. There doesn't need to be communication between the machines for them to work. Each machine can function on separate clients. Now, There probably are times when communications do need to take place between machines. Maybe make a third "Communications" machine to govern that. Of course, a LOT of this, is dependent upon the ship designer. He needs to have some foresight to build the ship so that there's some redundancy in place. There are definitely unknown hurdles, but a good programmer will work with what he's given.

NovaQuark has not provided details on how sensors work. Everything mentioned in this thread is speculative. Here's my IDEA, and reason for the thread. Allow for "sensor dimming" by adjusting input power to the sensor. This reduces the size of the "Area of Influence". In the previous sensors thread, I suggested the following: ===== Sensor Elements ===== Sensor Elements do NOT have to be omnidirectional. Hemispheres, cones, cubes, and beams are possible. Sensor Elements ARE different than Display Elements Sensor Elements detect all core units or avatars within a defined 3D "Area of Influence" Sensor Elements ONLY need to return the "ObjectID" from the core unit or the player's Avatar. Advanced Sensor Elements can return more information than the ObjectID, depending upon how NQ codes them. ===== Display Elements ===== Display Elements (radar display) will only need to know the ObjectID Display Elements will be hard coded by NQ, to display the XYZ position of known ObjectIDs Advanced Display Elements may take additional attributes such as "Friend or Foe" designation Advanced Display Elements may take additional "Color" attributes Advanced Display Elements may have the ability to provide different icons "on screen" ===== The DPU ===== The DPU can be used for filtering ObjectIDs provided by the sensor to the Display The DPU can be programmed by the player to filter however they like. ===== Flow of Data to the Display ===== Information is passed from the Sensor --> to the DPU --> to the Display ===== Weapon Elements ===== Weapon Elements have their own hard coded sensor Weapon Elements attack ALL ObjectIDs passed to them by a DPU ===== Flow of Data for Weapons ===== Information is passed from a DPU --> to a Weapon Element The DPU obtains that list of ObjectIDs however the player decides, including from a sensor.

Your Right! If the captain doesn't give rights to other users, and logs out, or drops connection, the multiplayer ship would be adrift (with players on it). But that problem is a lack of foresight by the captain. He SHOULD have given permission to key players for just such an emergency. But even on that ship thats adrift, if a player was operating the weapons console, they should still be able to fire because the weapons console script was executing on a players client that was still logged in. Drones wont continue to function unless their control is taken over by another player.

MMMMmmmm BRAINS....

For clarification. Scripts RESIDE in the construct and EXECUTE on the client. That multi-player ship doesn't disappear when you log off. Think of each control unit as a separate machine. The pilot executes the piloting script on their client while the weapons officer executes weapons scripts on their client

Self replication will first be VERY difficult and time consuming, but we all know that is speeds up exponentially. If scripts were executed "server side", you could theoretically create a self replicating robot that would fill the entire server just like a computer worm. In fact, you could just write a worm and have it execute on the server. However, it's already been confirmed that scripts will execute "client side". Given the identical scenario, the player would most likely lock up their computer, and kill their bandwidth (especially since their upload speeds are usually slower than their download speeds). The scripts would also ONLY execute while the person is playing the game. My guess is there will be safeguards in place to prevent this type of abuse entirely.

I think there will be a BIG difference between the build video, and what the final product will be. But, consider a game with a VERY complex build for a ship. It wouldn't be very long before players started packaging components into constructs that could be "bolted on". Who doesn't like bolt ons? So, it may initially be very difficult to build a ship, but after a few months, a player could just buy the modules (or the entire ship) from the marketplace.

Give me the RAW input and RAW output, and let me run with it. I'd like to see maneuvering thrusters work with the inertia of the ship. I'd like the control unit to accept KB, Mouse, and multiple Analog Inputs (sticks and pedals). Other than that, let the gamers make it work.

Consider that AI turret defending your base. Which client does the script run on? What does it do when you log off? Does the script actually run on the attackers PC? What happens when you have two attackers?

The LUA develop states scripts will be attached to a DPU element.

Dupe post

"Scripts" are an inherent part of a construct. They don't reside on your PC. They execute on your PC. They stay in game as long as your construct does.

My guess is the script would work on the PC of the person executing the script. (vague, I know) Here's an example. You build a kiosk that does "something". If a player interacted with that kiosk (regardless of whether you're online), the script would execute on their game client. This would also work for ships, and multiplayer ships with consoles that did different things. None of your constructs will disappear after logging off, and players with RIGHTS to access them, may do so. I'm not sure about the "Train" example. Can the train run on a track unattended? I would think at least one player would need to be riding a train. OR, the inventor has it run under a game client that never logs off.

It's been confirmed via Kickstarter comments that LUA scripting will be client side.

NQ has already indicated that if someone wanted to, they could create a "Mech". This would imply articulated motion. I would also believe wheels and tracks will be created as well.

I can't help but think there NEEDS to be the ability to have server side scripting in addition to client side. Here's an example using the "Trains" thread. A player spends a tremendous amount of time and energy to create a train / tram system. They're going to want to make some credits off their invention. This means selling tickets (granting limited rights) to ride their train. The user would most likely have to use a DPU to perform some basic logic to detect those rights. (what are the odds of creating the train WITHOUT using custom code and a DPU) In order for the Train to work while the player is offline, the solution needs to be scripted server side.

The OP specifically addressed my concept of sensor "areas of influence" A basic sensor would provide the "ObjectIDs" of everything in that area. I DO like the idea of active and passive. I also like the idea of detecting space-time curvature and tachyons. I think ADVANCED sensors could provide additional data such as the object's vector. (This could be computed by the player at the DPU level too) It would be nice to have different "icons" for the sensor display. Different sized dots, arrows, lines,etc.

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?

Jeronimo, I completely agree. And this is pure speculation until we here from NQ. Wicpar, I like where your head is at. Let's hope we have a multitude of sensors. If EM waves are traveling at the speed of light, how do we detect FTL ships?

I'd like to add. YES! You're right! You can use your own algorithym to "pare down" or "cripple" your sensor. But why would you? There may be a reason, but I can't think of it. If my sensor can detect every enemy ship within a given area, why would I not provide that entire list to my weapons?

Please define "it". Because your answers are obviously not clear. Thanks, I've thoroughly read the LUA devblog. A radar display displays the information provided to it. Please provide an AUTHORATATIVE post that says "all sensors are spherical."

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. There are DIFFERENT types of sensors, with DIFFERENT shapes and ranges. Per my OP. So here's how it works. Sensor provides list of ObjectIDs to DPU DPU Filters list of ObjectIDs and specifies Friend or 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

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 (think of this as a hard coded turret sensor). 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 hard coded RADAR element itself. But It would also be nice to specify a color with the ObjectID to indicate friend, foe, faction, or any other player defined preference.

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.