oak echo
Updated to 2.8.1:
shadow holly
The 2 MPUs added by this mod appear to use significantly less power than listed now. 6MW for the R-A Mk2 and 40 for the Bulker, down from 25 and 100.
I swear they used to be fine, and the vanilla ones are unchanged.
oak echo
they're unchanged, and have been that way the entire time. issue stems from the fact that MPU power draw is in part related to MPU speed, and they're currently setup to draw that much power if they had a base speed of 100 kg/s. good catch though, as this is an issue that's been there since the original mod
Updated to 2.8.2:
shadow holly
great, a false memory, now I have to doubt everything 🙃
serene gyro
For some reason the "MA-NTR600-II dual engine" from this mod on my K37 TNTRL does not appear to provide any thrust when in a dive, even though it consumes power, thermal energy, and emits particles. I swapped it out for a vanilla "MA-NMPD42 engine" and the main torch of my ship starts providing thrust again.
While I do not think it is a mod incompatibility issue, just in case it is, the mods I am running are as follows... (Listed as they are labeled in-game in the upper right, and I believe all are fully updated on my side...)
KemoPortraits4K
Industries of Enceladus Compat Port
Hev's More Minerals
Full Mineral Names
Velocity Plus
Funnel Titan
Kitsune Start
Moar RADARs!
Mod Menu 2
NTCED Parts Pack
Stated Claims
Abandoned Technologies
Elon Interstellar
HevLib
If you want me to, I can quickly upload a video unlisted to YouTube so you can see the issue I am having.
oak echo
Hm, not something that happened on my side from a quick test (new K37, buying only the NMPD42 and enough cores to power it), so if you can get a video and submit a report through the bug reports link (just in case it's something that is config specific), then that would be great
serene gyro
Hm, not something that happened on my side from a quick test (new K37, buying on...
Quick question about the bug report thing... When it says "If another mod is a dependency required for the mod to function, (for example, HevLib installed for a mod like IoER or VelocityPlus) include it but make sure to note it as one.", what does that exactly mean? Since IoER depends on HevLib, I presume I select "yes", right?
And the thing below says "List the names of the mods that are affected (if responded no to the previous question, leave a N/A)", would I put something like "HevLib (DEPENDENCY)" there? Should I also put IoER there too, as technically it is a mod affected, even though the previous question only says I should put the other mods that are installed at the same time there, and not the one I am reporting the issue on?
Should I just put something like "IoER, HevLib (DEPENDENCY OF IoER)" as my answer to that, just in case? (my autism is not making this any easier lol)
(P.S. When I am done reporting the bug, should I delete these messages of mine, to reduce clutter here?)
oak echo
A) yup, HevLib is a dependency so it should be listed since there's no way to run the mod without it.
B) I really don't mind how you put it (I'd know it's IoER anyway), but that's more so for cases where it would be issues happening specifically with other mods installed. Since uploading the mods list is something that's done later down the line anyway, I'd be testing with your setup regardless so I'll figure this part out anyway.
C) Sure
Also, don't worry about leaving messages here
serene gyro
Am I right to presume that I put the save file and video later in the bug report form, or should I put the video at least within the the "Please provide the steps to replicate the issue" section, alongside text on how to do it if you have the same save?
oak echo
That's later on, there's a section with instructions on how to provide them
oak echo
hm, seems to be ship config specific considering your own config has it happen but not my own. On the upside, I'm at least able to get it to happen so I can debug it
I think it's just the fact you're running your reactor cold, there's a clear cutoff at which the torch stops working and that seems to be about 3000K. Why that is, I can't say just yet, but it would explain why I wasn't able to have it happen myself
same thing does happen with all thrusters, usually closer to 2000K-2500K, so this might be specific to how the thruster's setup
oak echo
ok, so finally been able to trace the issue. the reason why ~3000K is the lower limit for reactor temperature is because torches by default are not able to run below 80% of their nominal thrust, and it just so happens to be that the NTR600-II is setup in a fashion that makes it susceptible to power loss at much higher temperatures.
Since this is basically an upgrade to the BWM535, I'll be leaving it in as a downside. However, I'll add a note of it in the description for the next update so that it's a bit more clear it can happen
shadow holly
the MAD-CERF civilian lists 6 crew but you can have 8
cargo capacity also seems to be wrong, listed 45k but the files say 35k
also considering it's using an OCP's habitat, shouldnt that translate to a morale bonus?
oak echo
tbh i really don't know why they're listed at 45k (or why crew is at 6), considering that change was made nearly a year ago, but yeah I'll get those fixed. as for why there's no morale bonus, it's just something that comes from the vanilla CERF having a rotating bay for functionality over comfort, considering the fact that the ship is really easy to get into a hard spin
shadow holly
what is the dry mass of a ship based on?
oak echo
raw mass of the ship
pretty much the ship itself and any components that cannot be changed out
which for the CERF is 190t for the ship, and 2.5t for each side of the hatch
shadow holly
im not asking for the cerf, the OCP's are what im looking at
the snap says it's the same as the base version, but it's lighter when you're flying it
by almost 20 tons
oak echo
any specific one?
shadow holly
the snap one specifically
y'know, pacman
im not sure if its just the sensor readout
oak echo
hm, i genuinely don't know why it's set lower than it should. lemmie see if i can find anything in the blame for the file
shadow holly
the deep dish (DD) also seems affected
I figured the DD was lighter since it was hollowed out for the extra pocket, but the description actually has it as heavier
oak echo
hm, so I can't source it to a specific update since it stems from a reorganization of the mod. lemmie see if it exists in the legacy mod first
and i think that's it, they use the exact same values that the original has.
probably means I'd need to go through each ship and double check the masses for them
shadow holly
oof
oak echo
I can at least say the CERFs are fine though as I used those as a baseline for how it's calculated
weird, the SNAP should be about 5,500kg heavier than stock
might be I need to check how it's done on there to double check too
nope, seems to be that the vanilla OCP has some discrepancy from it's raw mass values too, so I might just need to figure out a system to do this in-game
shadow holly
it seems the descriptions being decoupled from the stats is not that great
oak echo
so, from a test with a drained OCP and removing the mass of all installed equipment, I get a difference of 60kg between the predicted mass and the actual mass, so I think this is an issue with the vanilla stats as much as it is an issue with IoE
shadow holly
ye i just did the titan, listed mass is 70 tons off
oak echo
probably can amount it to floating point precision, given that mass is calculated in terms of tonnes not kilos for ship parts
whichever way it is, it's close enough that it'd be shaven off anyway to give it a cleaner number
shadow holly
TBH it only stuck out since it was listed as the same but wasn't. It's not like you can fully strip the ship in game to compare.
oak echo
right, you'd need to drain the propellant and then subtract everything.
Given that it's such a large difference though (~30 tonnes), I'm writing a bug report for it right now anyway
shadow holly
Could the NDDFD effects to be tuned down a bit? Even at low rocket plume settings I feel like I'm witnessing the birth of a universe whenever it goes off.
Actually they don't seem to get affected by the plume settings much, only the frequency of the light bursts gets reduced as opposed to the amount of light.
oak echo
yeah i'll give it a look. since I don't have a good idea as to how thruster plume brightness is calculated (and that ThrusterDriver seems to break for the NDDFD specifically), might be a bit before I get anywhere
shadow holly
The NDDFD can't be tuned down like the ZAP, is this intentional?
oak echo
Yup
shadow holly
This is getting into the realm of metagaming, but I've installed the Tetsuo Ramdrive Consumable Delivery Effi (unrelated, it doesn't list its morale penalty) wondering if it will allow faster transfer of drones to the Anarchist station, which it does.
I assumed it would also apply to kinetic ammo, but either it doesn't since I'd be transferring 1250kgs/s with the destroyer class magazine, or the station itself handles that transfer differently which would be a vanilla thing. So I guess my question is what is the intended interaction?
It might also be cool to have either it or another piece of gear in this slot increase mineral transfer speeds to habitats.
oak echo
the intended interaction is to have the rate limited considering that the selling of consumables use the same system that equipment uses to draw parts, however considering that the station pulls in consumables at a rate of 200 kg/s, nanodrones are going to get a much bigger impact over ammo (unless you're using tiny magazines)
shadow holly
This might be a case for ditching realism or balance for fun. Waiting is not fun.
oak echo
it's already something that can be disabled in HevLib's config. the change was made with modded drone launchers in mind, considering that it's limited for magazines in vanilla it's actually noticable when you can use equipment that can realistically reach or exceed those limits
coral holly
Hi @oak echo. Have you ever considered adding hull mods as a category? It could be a way to add extra impact protection to certain ships, grant EMP shielding to ships that don't have it. You can balance the benefits with extra ship weight.
oak echo
They're on backlog, but are pretty low priority right now. I had ideas closer to reactor-specific shielding as it made more sense from a balance perspective, which stuff like faraday cages could extend from as sidegrades
shadow holly
I need to fill the reactor room with pillows to minimize the jamming from g forces
shadow holly
it's already something that can be disabled in HevLib's config. the change was m...
Coming back to this, I more had in mind uncapping the station side as opposed to the player side. Meaning the station can draw as fast as you can output as opposed to your output being limited to the station's input.
oak echo
Ah ok, that sorta change I'm fine doing, although probably not for this mod specifically considering it's something a lot more suited to a velocity plus feature
It might make things a lot quicker for habitats, although for any ship that isn't the cothon the limiting factor probably would end up being the transfer speed between container and ship
shadow holly
I don't know what the habitat's speeds are like for minerals but you could dump 50 tons of driver ammo in 40 seconds at the pirate base if you could use the full throughput. That would be a sight to behold.
Actually I don't even know what ship's base throughputs even are for minerals, that isn't listed anywhere.
oak echo
Because they don't have them stated. habitats (only place where it's not stated and would matter) transfer at 1000 kg/s, which is a pretty reasonable limit
oak echo
I don't know what the habitat's speeds are like for minerals but you could dump ...
Another thing I was considering adding while I was at it would be a toggle to remove the ammo speed limit, which combined with a modified transfer rate would be pretty OP to have, so probably a toggle to have disabled by default
shadow holly
oh no, i have to stand still for less time, how OP
from what you've said the drones are subject to this too, you'd only get 200 of the 250 kg/s with the transfer speed upgrade
shadow holly
I'd like to suggest renaming the delivery system, the name singlehandedly stretches the OMS
oak echo
Sure, it is technically a bug with vanilla as well considering some languages and equipment, but yeah probably better off doing it here than waiting on that
shadow holly
Looking at it again, it's also cut off in the equipment menu, only reaches to the first letter of "Efficiency". This might be a good measure of maximum length
oak echo
Updated to 2.8.3:
shadow holly
Relating to my other message in velocityplus, the issue is definitely the feed systems. I've mounted 2 tetsuos (500kg/s each) on an OCP and can fire both at full blast with just the standard projectile magazine (100kg/s) and the scarlette (175kg/s in theory, in practice infinite).
Without it one gun stops shooting pretty quick, even with the destroyer magazine, nevermind the wimpy standard one.
shadow holly
Initially I thought this was limited to the ramdrive, but of the 5 consumable vats that change crew morale only 1 of them mentions the effect, the MPI Mounted Ammunition Canister.
oak echo
Honestly, I completely forgot about the morale changes. I'll have that for next update
shadow holly
I hate to add a third issue to the stack, but the NDDFD has no plume at all now
which is technically less bright now I guess
actually it seems to be most if not all modded engines, even thrusters
oak echo
yup, seems to be a difference between engine and release builds. surprised it wasn't caught earlier considering everything except the NDDFD would have had this issue since the last HevLib update
and it gives me zero errors and indication of the actual issue
shadow holly
this game really needs more players
oak echo
absolutely, and more people reporting issues too.
There's a good number of unresolved issues I've had for months (ones I probably should close as well), with people saying there's an issue or a crash with some of my mods, and never following up when I ask them for more info
shadow holly
What is the use-case for the Pin-C50 thrusters? They take a significantly larger amount of power and thermal energy over the AGILEs, less propellant I guess, but the AGILEs already don't use much at all so this isn't really a notable charactaristic. They also do not tune up, meaning the AGILEs outperform them by 30kN at max settings. Since the MTBF of AGILEs is 4 hours vs the 1.67 hours of these, they might actually wear out less at max tune too. They also weigh ~55% more.
I guess what I'm saying is that they are just worse, more expensive AGILEs. Unless I'm missing something.
oak echo
They're supposed to be hyper-efficient thrusters, but they are quite different to how Space had them setup.
Most of that's due to people complaining about the old version of them completely overshadowing both of the Eon RCS with their old model (which they used to have a better reliability than the NDSTR/NDVTT set of RCS). Only thing that probably shouldn't be there would be a thermal draw, considering that it's supposed to be related to the PinM200
shadow holly
I don't know if this is just me but the NDDFD looks no thinner or smaller at all
oak echo
It was specifically to do with the heat distribution. It did feel like a small difference when testing, but I'd need to go back to directly compare
shadow holly
If I intend to override its characteristics, should my mod load before or after?
oak echo
after
shadow holly
quite frankly, looking at it hurts, and it doesnt respond much to the thruster settings, i cant settle for a small reduction
oak echo
reasonable, although it does take a lot from the physical stats of the torch to define the exhaust plume and brightness, and I don't have anything for what specifically would be a drastic enough of a change to fix it
oak echo
would something like this be good enough, or do you think it could be further reduced?
shadow holly
i think the problem is less the size and more how bright it is
no other plume is that bright
it's like a flashbang
altho the size it odd too, why bigger than the ND-NTTR when it's half the strength? the zap's plume isnt that much bigger than other small thrusters, just longer and thinner
oak echo
i think the problem is less the size and more how bright it is
that's the problem though, making it smaller is about the closest i've come to making it dimmer. even changing the parts that directly control brightness from the light emitters to lower than default, it still does end up very bright
oak echo
altho the size it odd too, why bigger than the ND-NTTR when it's half the streng...
probably down to the fact that thrusters got a visual rework well after they were made to prevent issues with colour overflowing the transparency of other thruster plumes. ZAPs used to have a considerably longer plume before the change
oak echo
Ok, this is about the best I'm able to do without changing the thrust or propellant parameters (which do play a heavy part in dictating how bright the plume is), with both the new and old plume size. Smaller size still does get really bright when zoomed in, but disabling postprocessing should remove any of HDR overbright features that cause the sheer brightness of the plume anyway
oak echo
Updated to 2.8.4:
shadow holly
I'm currently looking at the Frakker preprocessor. It lists 20 max ores at once and 2500kW of power per chunk, but it doesn't ... do anything to the chunks? There's no ice melt rate, not in the listed stats nor the files. Am I missing something?
oak echo
It's a small ice rate with no remass recovery. Iirc that part should be noted with the description rather than through stats as this is a unit focused on MPU speed rather than ore processing, and the 20 ore max is pretty much just listed to state that it can do some melting without implying a bottomless number of ores that it can handle
shadow holly
Then why does each chunk cost energy if it doesnt do anything to the chunk? The penalty is in the mpu power multiplier, no?
oak echo
It does do some melting, just nothing significant
shadow holly
it has no self_kgps
oak echo
It doesn't?
shadow holly
no
it also cant be tuned
so there is nothing going on there
it used to have self_kgps = 100.0 about a month ago lol
shadow holly
The shipyard-class nanodrone storage appears to have a delivery rate of 20 as opposed to 100, I can only run 2 harvester class haul drones off it, station-class works fine.
oak echo
I see that it's an issue, but the weird part is that I've only had it happen once during testing so I really couldn't say what's causing it yet. There's been zero issues when registering it as a capacity, as it was something I logged and checked for, so it's definitely saying it's there but not finding it when searching for whatever reason
oak echo
Ok well no wonder it was such a hard thing to trace, ended up being floating point precision being the issue
shadow holly
I'm not sure if this is an actual issue or just the way it's supposed to be, but the Tsukuyomi seems to really struggle with autopilot. Especially slowing down while facing forward, it just wont fire the RCS to slow down at all most of the time. With fly-by-wire sometimes even manual attempts to fire the thrusters lag before happening.
It cant even face left and stop most of the time, to return to E, it just overshoots the turn and fails to stop
Maybe the default tuning is just bad? I'm hoping to jiggle the levers of the autopilot enough for it to work
oak echo
yeah, autopilots just really don't like the layout for whatever reason. I've tried to fix it, which if you could believe have only ever made it worse
shadow holly
lol
setting the rotation priority to 0% seems to have helped, a lot, at least in the sim
The RA DMW cannon turret doesnt show any reliability data (velocityplus). The non turreted one does, so does the vanilla MW turret
shadow holly
I'm not sure if this is an actual issue or just the way it's supposed to be, but...
the reaction wheel is also constantly yellow, this is not a happy ship rotationally speaking
oak echo
yeah, it exceeding 300 RPM is something i'm already aware of. I'm not going to be changing that at any point before the rework as getting to rotational velocities high enough to trigger it kinda are warranted for the warning
empty meteor
The shipyard-class nanodrone storage appears to have a delivery rate of 20 as op...
oh shit thats why? I was wondering why my drone launchers were cycling like mad
shadow holly
Is there an up to date list of the things this mod adds anywhere? I'm seeing the ck-69 for the first time, there's definitely been other gear that isn't listed on the github readme or the nexus release page.
oak echo
Only on the github updater list. I never created a wiki on the repository and the readme is the same as Space's for the most part and I just never bothered to change it
shadow holly
you mean MOD_DETAILS.txt?
oak echo
yes
shadow holly
the fission refit doesnt look like it should in the examine menu
on a side note, finally the solution to the EIME nerfs, no more fusion required
oak echo
Yeah, it needs a complete remodel to have a fitting reactor instead of the K37 one and I have no modelling capabilities, so it'll be staying like that due to there not really being a way to easily graft anything other than the glow
shadow holly
The RA mk2 mpu sets itself to 1 more kg/s than you set when you leave the tuning menu and come back.
oak echo
It's a visual glitch with vanilla, just happens because the way the value is rounded is different when the slider loads compared to when it is changed
might be worth seeing if there's a case where it does happen with vanilla equipment, considering that there's a good chance it does affect something else and make it something worth Koder's time, although considering that MPUs specifically aren't given formatting data it's probably more likely only going to be something that doesn't have it but still can end up with a fraction
shadow holly
The RA DMW turret really does not want to turn forward.
Here it is compared to the vanilla PD at its max targeting range, although it should target farther due to its 800m range. The tooltip actually claims 2000m but that's probably a typo.
Here it is again with the turret is supposedly shares a mount with, absolutely pitiful in comparison.
It's not a limit as to how far it gimbals either, it will happily turn to face the rock if I get really close.
The NDCL-80 does not seem to have this issue, in fact I wanted to swap from it to the DMW turret, but since it cant shoot forward much it's not really an option.
oak echo
Yeah, 2k is a typo as it's supposed to mirror the fixed equipment, which is pretty obvious that it doesn't. Reason it doesn't want to turn forward is because it shares the targeting areas of the PDMWG, similarly to how the NDCL-80 mirrors the NDPT. Only difference is that the DMW turret brings the targeting 40m closer to be able to target rocks close to the ship as that's something the PDMWG isn't really capable of doing
I'm fine moving it further out to match, but I'd be concerned that it would make it even worse at targeting forward on the side turrets since they are angled at 60 degrees
shadow holly
Here's what I'm actually trying to pull, since the turrets rest off to the side there's only one real choice for the slot unless I intend to hump every rock
not that it is much better on smaller ships like the eime
oak echo
I'll give it a look with collisions enabled later on, probably just barely missing the rock at those angles.
shadow holly
Also I've just noticed from that screenshot, but the CERF has RA-K37 as its reactor.
oak echo
Yeah, it's an oversight as i completely forgot that they're not unique too
oak echo
Ok, so the mike turrets kinda just have bad coverage overall.
These are the targeting areas for the DMW turret on the left, and PDWMG on the right.
compared to that of the NDPT/NDCL
oak echo
yeah, it's just got that little extra range. I'll probably just end up moving the DMW targeting area further out and widening the lozenge to match the PDMWG
tbh I didn't even realize the NDPT had the same (minimum) range limitations as the PDMWG, which is probably because it's so efficient it's never an issue
Ok, change has been made internally and it should give them ~40-50% bonus in targeting range too. I'm just going to make a quick guess that there's going to be balancing considerations needed to be made, but we'll see
shadow holly
Ok, so the mike turrets kinda just have bad coverage overall.
These are the ta...
Why does the dwm have an extra circle in its targeting? The other turrets seem to only have the capsule.
oak echo
It's one of Space's changes over vanilla turrets, but I'd presume it's for extra range. Couldn't really say why it was done that way instead of extending the current lozenge or adding a new one
shadow holly
I've been looking into mods that implement a custom autopilot. Does the MA-337-MAX work properly? I don't know how to check for autopilot features through in game testing, but from what I've logged it seems to lack the ARL and AAT from the MA-337 and just has the LIDAR overlay and FBW.
oak echo
I've never used it myself, but just from giving the code a look it's not functional. It's pretty much down to the fact that you'd need to completely replace the code handling AP functionality to have it work as it's embedded entirely within the method. FBW is an exception as it's the only AP feature to have a unique method used to say that it's available
IIRC the BLI autopilot actually does just that, so i would say that unless something changes, it's probably the only way to have a completely functional autopilot
shadow holly
bummer, it is kinda weird that the list of autopilots and their functions are within the function where they get used
shadow holly
This is more of a consistancy thing, but the Rusatom Chunk Cutter mentions "ambient ice melt rate" instead of just "ice melt rate" and is the only one to do so. It along with the Frakker (I've reached the Frakker again lol) also mention "ambient power cost per chunk", power cost format is different on other preprocessors. The voyager fabricator is also the only one to list "additional power cost per chunk" in the simulation tab.
oak echo
tbh i don't remember why it's like that, but since they've changed a bit since they were written i may as well just unify them.
as for the voyager, I kinda just forgot to remove it when i removed any listed MPU power scaling stats
shadow holly
I've noticed a few more:
I also wanted to comment on the Frakker's actual stats, having lost its ice melting ability. If you're not using it on the MSU, stepping down even to just the Nakamura MPU at 50kg/s, you're better off just using the chunk cutter. 50*1.85 = 92.5 vs 50+25+17.5(one chunk worth of ice melt rate, you can have 12) = 92.5. It doesnt help that it weighs 10x as much either. Factoring in the full ice melt rate it may lose out even on the MSU which is the best case scenario.
oak echo
Thanks, guess it was about time before some of the inconsistencies showed up, and probably doesn't help that there's 4 separate manual texts for it either.
As for the Frakker, it does actually process chunks at a rate of 100 kg/s, which is about 3 times higher than what it's supposed to have at 35 kg/s. Reason why, at least according to the history, was due to it being the only unit to not be fixed after the melt rate was changed from using integers to floats, which would've cleared the stat from the scene file actually, seems to be intentional as the frakker was the only unit to be changed on the specific commit, so idk might just be that way but probably will be brought back down
shadow holly
I just assumed the intention was to remove it since yesterday's translation update removed all mentions of power costs and simultaneous processing.
oak echo
That was made because I didn't actually double check it then
the frakker is getting a rebalance anyway, considering the fact it's using 10 times the power that's listed
oak echo
Updated to 2.8.5:
shadow holly
I've noticed a few more:
- Some use "MPU processing speed factor" and others "MP...
here's a few more for when you get around to it:
with the new targeting change the dmw shoots before i'm in range
oh and the reactor is still the k37's 🙃
oak echo
the power per chunk is intentionally mentioning it both in the manual and specifying it in the stats, as that mirrors how vanilla MPUs state power draw
Updated to 2.8.6:
shadow holly
Do preprocessors affect everything in the hold or do they check a specific area around them? Maybe a case-by-case basis? Because some manuals state an area and a size, others state the unit only has to be powered and others have both.
oak echo
Currently it's everything in the hold. They used to have specific processing areas, but they were causing performance issues in some cases and were really finicky on some ships, so I ended up just removing them. I did want to bring them back eventually, but since it involves modelling 7 units for every ship, it's kinda something I've forgotten to do. I might just end up leaving them as-is, but i'm unsure on it just yet
shadow holly
The way the RA-K69V quad engine gimbals seems a little ... screwed up https://i.imgur.com/HTopCPq.mp4
oak echo
Yeah, unfortunately i kinda can't really do much about it considering how the thrusters gimbal and that sprites don't let you set an offset for the rotation. A similar thing happens with the DMW turret when it's damaged too
shadow holly
maybe they should be swapped to vectored thrust instead, their gimbal speed is instant anyway and that way they dont pop outside of the ship when they turn
oak echo
Considering the fact that they're supposed to be 4 K69V RCS strapped to each other, i think I'd rather just leave it like this. Could be retconned as it using a singular servo for it to simplify the mechanism, which would give the same effect
shadow holly
You cant see it in the clip, but the rear engines exit the ship sprite when they turn. The way I see it is that each small thruster turns (which can't be animated) and it simulates vectored thrust. But that's just my take.
oak echo
I wouldn't worry too much about that part, considering that there's vanilla torches that do break through the sprite (namely the NTTR and Cheval), and even then it's probably easier to just have a visual connector show how they move as a single unit
Probably doesn't help that it's the gimbal speed that makes it look bad, which since it's being retconned to move as one might be better to slow it down anywya
oak echo
Since it still happens within a frame, it's not a noticeable difference by any means
shadow holly
it might just be the teleporting effect that makes it look terrible
the thrusters you mentioned are static, even if they look kinda funny they dont whip around and draw attention
oak echo
That's exactly it, 360 deg/s is insanely fast for the angles it's traveling, which even when going side to side should take only a handful of frames at worst
shadow holly
The Wasp seems to have the ability the gimbal any thruster you put in there, don't think I've seen this on another ship. How does this interact with thrusters that already have a gimbal or are vectored?
oak echo
The Peeper has it, as well as KX37 RAM having it on two thrusters, but they have it nowhere near as severe as the Wasp (which has it because it's thruster layout really does not work for fixed thrusters)
For the interaction with gimballed/vectored thrusters, it just adds some extra gimbal.
shadow holly
I've only now noticed the wasp straight up mentions it in the examine screen. The Peeper is a surprise, it doesn't mention changes to the RCS placements anywhere, but I guess you can't move the ball so far up without them.
Still ends up really awkward and front-heavy.
jolly saddle
items in the cargo bay of the Tsuku can block PD lasers mounted in the low stress
as you can see here
the NDCI overlay indicates that it's being blocked
oak echo
yeah, it's unfortunately something that won't be fixed until it becomes vanilla equipment due to what would need changing within it's script. it's something that Koder is aware of though https://discord.com/channels/426287934870781952/1493880914306924604
jolly saddle
ah ok
as a workaround you could change the position that this particular equipment is in? move it closer to the front of the ship?
oak echo
Don't know how i missed this, but yeah i probably could.
twilit wren
So I may be behind the news on this as I have been traveling alot.
What about a BB variant with a larger opening. I think swinging double does that open out to reveal the whole front would be thematically best as that's how break bulk ships open. A bandaid test run could just be a giant excavator beak or the double sliding doors from the ocp variation.
oak echo
I'm down for the idea, just extends the front bay area and cap it off with a large door (or a sliding door like the kitsune, frigate, or CERF)
Sliding would probably be harder considering the horizontal space needed for it, but I'll still give it a try anyway
vivid nimbus
Sometimes long equipment lists seem to push the Minding Virtual Flight Service box below the bottom of the box
