|
Post by jtyotjotjipaefvj on Sept 23, 2017 8:59:42 GMT
Even after logging in it says I don't have rights to access this.
Either way, not maximising EV sounds like a terrible idea if you want to choose a propellant. EV and optimized TWR are really the only things that matter. Maybe propellant density and price too, but they're usually secondary.
|
|
|
Post by jtyotjotjipaefvj on Sept 22, 2017 9:04:52 GMT
Yeah. Then we can finally put those radshield bulkheads to good use. Framerate might be a concern though. Modules ablating instead of disappearing upon being disabled would have some major consequences. No more instant holes in your armour when a turret gets destroyed, a destroyed module still blocking a lot of fire might delay the coring of a ship, ... I know radshields already behave like armor. A laser has to drill a hole through the shield, and after the hole is made, can only make it through that one hole. After it destroys whatever component it was targeting, it changes its target and has to drill a new hole. One of my laser star destroyer drones used this to survive against laser stars for a very long time.
|
|
|
Post by jtyotjotjipaefvj on Sept 22, 2017 8:57:43 GMT
Treating modules the same way as armour should be possible. The game knows the materials the modules are made of. Yeah. Then we can finally put those radshield bulkheads to good use. Framerate might be a concern though. I thought they already worked that way? At least I've made good use of redundancy and lots of spider silk rad shields. They also work correctly when used as laser armor caps placed in front of drones, which is what I did to beat apophys's laser stars. For kinetic weapons, I mostly use KKVs though so it could be that ship to ship collisions are more accurate than bullet to ship ones. I suspect the issue is in the game's handling of low-mass bullets, not the damage model itself. At least I noticed a clear difference between a railgun that shoots a metal rod comprised of a rad shield versus a metal rod that is a bullet. The payload version never ricocheted, whereas the bullets needed to strike very close to a 90 degree angle to avoid ricocheting.
|
|
|
Post by jtyotjotjipaefvj on Sept 21, 2017 17:57:54 GMT
Depending on what the integral looks like it might not be too bad. If you don't care about interreflection, you can integrate illumination of an object for visible light pretty cheaply on the GPU. Since radar is EM radiation too, it might behave in a similar fashion, just with different material parameters.
|
|
|
Post by jtyotjotjipaefvj on Sept 20, 2017 0:53:28 GMT
Is there even any info on why it happens? It could be floating point precision issues for all we know, and there's no way you could work around it with just modding.
|
|
|
Post by jtyotjotjipaefvj on Sept 18, 2017 17:31:56 GMT
100,000 square meters sounds like a pretty big frigate to me. 1 km long, 100m hull diameter? You should probably lose a zero or two from that.
|
|
|
Post by jtyotjotjipaefvj on Sept 16, 2017 13:23:23 GMT
You might not be able to afford a laser that can melt even sensors on missiles hundreds of kilometers away, since you need a wider beam to hit the tiny sensor on the missile. You'd also need to be able to take down hundreds of seeker heads in a fairly short time, otherwise you're just going to thin the salvo a little, not disable it entirely. This means you can't really afford to use capital lasers to melt missiles, since you can buy thousands of missiles at the price of one laser. How accurate your weapon fire is depends for a large part on your sensor resolution. Because momentum wheels can be ridiculously precise, and our lasers have high intensities even at 10 Mm, sensor precision would seem to be the main limitation of laser precision (IRL). Furthermore, electronics are much more temperature-sensitive than metal or ceramic (or even ablative) armour. So a much lower intensity is required. And about economics: the game doesn't take manufacturing costs into account (which would hit missiles the hardest of all weapons), the game doesn't use a persistent fleet (ammo consumption,damage to ships and ships lost doesn't make a difference for the next mission) and non-military uses are not mentioned in the game. And my laser doesn't need to be cost-effective against a missile swarm, my laserstar needs to be cost-effective against an arsenal ship. Not having the juice to run a MPDT will bloat your ship's mass and cost. I don't know of any sensor tech that can make out a tiny sensor hole on the hull of a ship 10k kilometers away though. IR can see the exhaust yes, but not much else.
|
|
|
Post by jtyotjotjipaefvj on Sept 16, 2017 11:40:42 GMT
You might not be able to afford a laser that can melt even sensors on missiles hundreds of kilometers away, since you need a wider beam to hit the tiny sensor on the missile. You'd also need to be able to take down hundreds of seeker heads in a fairly short time, otherwise you're just going to thin the salvo a little, not disable it entirely. This means you can't really afford to use capital lasers to melt missiles, since you can buy thousands of missiles at the price of one laser.
|
|
|
Post by jtyotjotjipaefvj on Sept 16, 2017 1:32:14 GMT
I fixed the discretization of star positions by adding in some procedural noise in the vertex shader. It works all right for large star counts, but tukuro's star chart still looks a bit iffy due to the lower number of stars. It might be fixable with some actually worthwhile random generator. Seeding the generator is a bit of an issue though, since we only have the position and color that changes between stars, and the position being discretized is what we're trying to solve in the first place. Below is a picture of the same star distribution as earlier, but with some jittering added in to break the structure. Here's the modified vertex shader. Replace Stars.vert in Resources\Shaders\ to use it. varying vec4 Color;
float noise(vec2 p, float s)
{
return fract(765.9*cos(324.9*dot(vec3(p,s),vec3(19.7,17.5,1.3))));
}
void main()
{
Color = gl_Color;
vec4 pos = gl_Vertex;
pos.xyz += (vec3(noise(pos.xy*23.1, 72.5 * Color.x), noise(pos.yz*24.1, 96.2 * Color.y), noise(pos.zx*50.2, 13.5 * Color.z)) * 2.0 - vec3(1.0)) * .005;
gl_Position = (TotalTransformMatrix * pos).xyww;
}
|
|
|
Post by jtyotjotjipaefvj on Sept 15, 2017 20:33:15 GMT
I don't have time for moderating, since I have a job.
|
|
|
Post by jtyotjotjipaefvj on Sept 15, 2017 16:28:06 GMT
I tested this with a starchart generated by my own generator that gets a 4000x2000 png as input and applies random jitter to the angle of generated stars, and still the grid pattern remains. My guess would be that the star angles are sent to the shader as 16-bit floats to save on memory usage, which sounds ridiculous given the low amount of data used. I can maybe add in some procedural jittering on the shader side, although that won't look as good as an actual high-precision result. Here's the star grid test image I got from my own generator:
|
|
|
Post by jtyotjotjipaefvj on Sept 15, 2017 13:21:01 GMT
Are there even moderators here? Who would ban them?
|
|
|
Post by jtyotjotjipaefvj on Sept 15, 2017 8:12:34 GMT
Depending on the sphere projection used by the image, converting pixel coordinates to angles is exactly the right thing to do. I'll see what happens if I make my own converter.
|
|
|
Post by jtyotjotjipaefvj on Sept 15, 2017 8:10:16 GMT
Remarkable, that laser satellite spam system, there, though it seems like it'll be expensive to operate. Also, how did you get the braking rockets to do that? I don't think there's any AI setup that can give you that. They're unguided rockets with a precisely set DV budget so that they run out of fuel just as they're stationary. Sadly it's not usable by AI since even on unguided behaviour it doesn't always turn on the engines. Also, since they're drones, you have to manually change the order to homing to get them to go undguided, and drones that run out of dv get disabled even if they still have ammo left. So instead I just give them a move order, which guarantees the engines will run, and manually time the launch order on the satellite launchers. It should work with the current AI models we have but these limitations force it to manual use only.
|
|
|
Post by jtyotjotjipaefvj on Sept 15, 2017 0:44:27 GMT
Hold on, you mentioned your program takes a png as input? So you just project the image onto a sphere, then convert the pixels to stars? In that case the issue is probably your python converter. I'll see if I can cook something up tomorrow.
Can you tell me what format the stars are in? I could maybe make a version in c++, this shouldn't take more than a second to run.
|
|