Return to “Suggestions”

Post

Re: A Reinterpretation of Research

#91
Here are some of my thoughts on drones.

Drones excel when they have one task which they are assigned. Drones with one task assigned do not need to keep in direct contact with a relay ship or station. These tasks include but are not limited to:

Finding ore and displaying richness percentage at a given point of an asteroid (LT video example)
Transporting cargo from one location to another
Relaying position and movement within a given region of space
Attacking a given target
Attaching to a vessel to act as a homing beacon

Drones can have multiple tasks but give up their ability to be autonomous in doing so. Therefore drones with multiple tasks must always be within direct contact with a relay ship or station. If the relay ship or station is destroyed or moved out of range the drones lose their “perceived intelligence” and will stop all operations. These tasks include but are not limited to:

Drones with multiple weapons
Drones which can attack other ships and can also mine
Drones controlling multiple drones
Image
Post

Re: A Reinterpretation of Research

#92
alternative idea for the people who complain about drones needing "pilots" to function.

"drone minds"

basic idea for drone minds is Gazz' idea on them.

"launched drones are dumb and cant be reprogrammed"

when the drone mind is on board drones cant be reprogrammed in flight and only understand simple orders.

when the drone mind is on board of a carrier ship and the drone itself is remote controlled it can be reprogrammed in flight, but is limited to simple orders and to comms range.

then remote piloted drones, using "full" worker brains, normal pilots, are possible, they have the full range of commands and have better "per mass" statistics than locally piloted ships
but all the drawbacks of remote controlled ships, range and hackability.

and of course full ships.


drone minds are limited in intelligence and cant do anything without direct order, but can be produced and need less space than pilots
Post

Re: A Reinterpretation of Research

#93
a bit simplified approach on the computers stuff:

Ditch the grid based programs and use a nesting tree instead for placing program(parts).

Instead of the grid would be "bubbles" within bubbles (and so forth).
Every piece can directly communicate with other pieces in the same bubble without other orientation/placement limitations.
So anything thats on the same nesting level can communicate.

The bubbles would denote the nesting level and would function as firewalls/program delimiters and would protect other programs inside it from intrusion (with varying degrees of protection)

Communication from the inside to the outside of a bubble would work through "receptors" which could be typed to make it easier to see what does what (sensor data vs engine controls etc)

The bubbles would also make it easier to manage bought software, as there are defined structures which mark individual programs.

Maybe some DRM measures could be included in the game the same way, you only get a ready made blob that you can use and the firewall around it doesnt let you analyse/modify its contents but only supplies the interfaces to use the program.
:think:

This would also work in the other direction, rent out some computer space and supply interfaces to the inside but nothing else.
:think:
Post

Re: A Reinterpretation of Research

#94
another approach on drone cores:

what if they were limited in the amount of hardware they could control?

normal ships are controlled by general purpose computers which run software to control the connected equipment.
relatively big, relatively inefficient, but flexible and can be scaled indefinitely.


drones can be done a different way, due to their small size they have to use more efficient control devices.
but the small size also gives them the advantage they need to be workable at all

the cores are highly specialised ASIC based control circuits which are much more effective in their tasks than a general purpose computer running software.
but are limited in that they arent adaptable, they have a limited amount of hardcoded control "software" packages that cant be changed or adapted after production.

this causes the drone cores to only be able to control very limited amounts of equipment which have to be predefined too,
so a drone has to be developed as "monolithic" block where nothing can be changed after the design phase.

a drone has to be designed using the mechanics i outlined at lenght in this thread and then the computer core has to be built as fixed unit before the already defined drone can be assembled.
(mechanics in this thread for drones: design yes, changing things after construction no)
so drones are built from the same parts using the same mechanics as ships, but they cant change those parts after the design phase

they are also limited in how they can perform jobs (due to their hardwiring), only prebuilt behaviours can be triggered and will then be executed (however limited we want to make drones compared to ships)

:think:
Post

Re: A Reinterpretation of Research

#95
Shields could have a special "mode" when they have 0 continous input and only their caps are being fed.

they would enter "reactive" mode where they only activate when needed, as for example a bullet would strike.

the rest of the time the shield generator would be off for all purposes.


this mode would enable passage of ships through a shield perimeter without completely shutting down the defenses.
so a carrier could open up its shields to launch/retrieve its parasite ships without dropping them completely.

although this ability comes at a cost, as the power+power change to protection ratio strongly drops for high changes in power allocation (read: the cap has to step in) and shields needing some power to reinitiate at all from a downed state the not-actually-down defense is very energy intensive to maintain and would provide much less protection for the same effort.

though this drawback would buy the advantages of free traversability of the shield bubble and very low power draw when not under attack.


passive mode could actually be the default "power down" mode for shields

Online Now

Users browsing this forum: No registered users and 16 guests

cron