Search the Community

Hello Dualiers, The plan right now is (according to what i have seen and heard) to have a stats based locking targeting system. it is extremely cheap. too cheap. the problem with it is that the battle becomes more of a dice roll, as can be seen in eve online. You target point blank on a battleship (miss) wtf... these kinds of things are frustrating. there are tons of ways to contour the problem with kinetic weapons and their delay, the easiest way to reduce performance drain is to handle them like a shell + their movement, it calculates then an intersection on that 4D-ish object (it is in practice flattened into 3D) every frame, not more expensive than having a player. then you can put a limit in the form of reloading time, real battleship shells take 10-20 seconds to reload in best of cases. besides that, lasers are practically free, but do less damage, and have tendency to overheat so you have to stop them quite often if not reducing their lifespan considerably, and use a lot of energy. you get the idea of the gameplay implications. this system would allow to handle all weaponry shots in one container, thus reducing development costs and code base pollution risks. this is mostly important if we want to make weapons interact between planets and space, as punching a hole in a vessel in space would be ludicrous from the planets surface. and what about 1000mm planet-space cannons, do these not ark? in addition to that this system would allow for massive increase in need of good targeting scripts or canoneers (there would be visual aid for players (can be cheaply calculated with raymarching, but it is relative t the memory architecture you chose for the physics mesh, if there is a phase where it is static in the loop, it may be worth it to do it asynchronously in a separate thread if it is the case) eve online opted for that system because it uses 1 second ticks, i don't think you work like that, and if it is the case there is no advantage to it except a relatively small amount of computations, as you would have to determine the voxel to break anyway... and what about people who want a fast fighter with Gatlings? locking would be so unsatisfying, especially if you target a starbase... but anyway, this is my opinion and my vision of locking may be wrong. hope you find this idea interresting . just remember, my point is control vs simplicity (pro control).

I have a specific, but sort of general, question about sensor granularity when it comes to DPU events and functions. What level of granularity can we expect from various sensor systems for things like developing an AI-based targetting system? For example, in the Lua DevBlog, the radar was mentioned with an enemyAt(x, y, z) event and the inclinometer would have our ship's getPitch() / getRoll() functions. Let's say I am building a targetting AI for a laser-based weapon. I would simply use the current enemyAt(x, y, z) position for the target location as it would be very unlikely to combat at or near light speed. But if my ship is using a projectile weapons system with a bit of delay before reaching the target, I would need to program the AI to use the enemy position plus their current direction of movement and velocity, combined my my ship's current direction velocity to compensate and lead the gun appropriately to hit the target if they maintain their current speed and vector. So, will things like getEnemySpeed(id) and getEnemyVector(id) functions be available from the sensor systems? Or will the gun DPU system have basic targeting and appropriate aim leading code already implemented for AI and human firing? On another note, would there be a mechanism for rayCast targetting from a gun? ie. Checking in the direction the gun is pointing to find the collision position and ensure it isn't a point on my own ship, or a friendly ship before firing? Sorry for all the technical questioning, but thanks for listening!