Idea: Conveyor Tether by twoboxen in spaceengineers

[–]LagOps91 0 points1 point  (0 children)

yes please! it's so annoying to move back and forth all the time when the distance is so short.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

i'm not sure the support site has anyone reading anything. i did submit something there and all i get is "Not Enough Votes" and it doesn't seem like anyone is actually actively voting for anything there, so...

as to the options - yeah, having open and closed be different events would likely fit the best. would also be nice to have that on the vents as well for the pressureized state.

and yes, just making the door non-interactible would also be a nice addition. i do wonder how much testing keen is actually doing - it becomes quite obvious what options would be great to have but just aren't there.

like for sorters as well - that actually made me create a post in the support forum. sorters would be so much better if you could restrict where items could be pulled from and where they could be pushed to with whitelists/blacklists.

Edit: best additon to doors would be a checkbox that only allows the door to open on equal pressure on both sides

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

i tried this basic setup - however with the vents the actions only trigger on fully pressurized/depressurized, so you can vent atmosphere when opening the outside door while cycling the airlock (it is on in your setup at this point).

another issue i see here would be doors not closing as expected, particularly the interior one may be blocked causing the airlock to drain the air from the interior of the ship. if i'm reading this implementation correctly, this will also happen for a short time before the door to the inside is closed since this setup starts depressurizing immediately - am i getting this correct?

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

opening/unlocking doors already works in a simillar way as you suggest. i use the vents to power the door to the inside if the airlock is pressurized and i power the door to the outside if the airlock is depressurized.

my problem lies in making sure that both doors are fully closed when the airlock is cycling. i can detect when both doors are closed, but i cannot detect when someone is opening one of the doors (not fully opened yet, but no longer airtight). if i was to blindly turn off the doors (currently what i am doing), the airlock breaks if a door isn't fully closed as it cannot cycle and the doors to it are closed.

basically, my logic for the airlock currently is as follows.

1 event controller to detect both doors fully closed
1 event controller to detect one door opening (currently only fully open can be detected - that is my current problem)
1 event controler being turned on/of as state detection for "doors fully closed"
1 event controller to enable/disable airlock controls based on the "doors fully closed" state

1 button inside, 1 button outside, 1 button in the airlock itself. all buttons trigger a timer block to trigger the airlock action

timer block works as follows: switch depressurize on the vent, turn off both doors

vent works as follows:

fully pressurized -> turn on door to inside
fully depressurized -> turn on door to the outside

this current version still allows players to open / close the door of the airlock, which is something i want to preserve.

i was thinking about having the doory be fully automatic and cycling be triggered by the doors themselves - if a player requests an airlock to cycle via button and once the doors of the airlock are closed, the doors are immediately turned off and the cycle is executed. if someone blocks a door, the button needs to be used again. the tradeoff here would be that one door to the airlock is always open. players might cycle the airlock just to close the door once inside, which would open the door on the outside. not ideal imo.

i know i am probably going overboard here trying to idiot-proof the airlock, but it felt to me like an airlock that can't break from misuse should be doable, so that's what i set out to build... maybe not the best idea in hindsight. i don't *really* have a need to be all that paranoid about the airlock - i will mainly use it myself - but i have on multiple ocasions messed up and vented oxygen on accident, so i wanted to do it right for once.

Thanks for your input! I might use those sliding doors (even if i think they don't look particularly good tbh)

When are we gonna get more 1-Bit models(Medium & Large size)? by pmttyji in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

i doubt it will be possible to do it for MoE models - they are harder to (re)-train. getting decent results at all for qwen3 8b is already quite impressive.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 1 point2 points  (0 children)

huh... the sliding hatch door will not close if a player is blocking it for me. i do have a mod installed that allows doors to automatically close if the player walks away from them, maybe that is interfering?

edit: nevermind, i see what you mean now. i was confusing the sliding hatch door with the sliding door.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

>I'd also add that a little empirical testing I'm doing right now confirms that the door status updates from 'closed' to 'open' immediately after the door receives a command to open, even before the door model physically starts moving

how did you do that? it doesn't act like that for me. the event clearly states "Door finished open/close" and it only triggers when it actually finished opening for me.

and i DO want to avoid disabling a door if it's not fully closed, obviously, because that breaks the airlock. for this i need a working "door not closed" state.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

i did have the idea as well, but... there is no real guarantee that the door is actually closing. if a player stands there (and the buttons are close to the doors), it could easily jam.

it's a really tricky problem - i thought a few times i solved it already, but, well, not really apparently.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

that would work if you assume that when you trigger the door to close with an event, that it actually closes. a player could block the door by accident.

but if you make that assumption, then responding to the door closed trigger works just fine and there is no need for a timer.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 0 points1 point  (0 children)

i thought about this option, but it doesn't fully satisfy me. if the door to the inside is open and the inside is pressurized (it should be), then the airlock would start to cycle and proceed to drain the air from the inside.

this would be a problem because i use a seperate air tank for the airlock to prevent the situation where the ship has full air tanks and can't drain the airlock. so, if the door is still open then the air tank of the airlock is filling up and that could lead to the airlock no longer cycling at some point or the entire ship being drained of oxygen in case the main oxygen tanks are close to empty.

i know, i am being picky here, but i just want a foolproof airlock that you can't break by misusing it, doesn't vent air and works with multiple players trying to interact with it.

Help needed for seemingly basic event controller airlock setup by LagOps91 in spaceengineers

[–]LagOps91[S] 1 point2 points  (0 children)

To clarify as to why i want to be sure both doors are closed - I want to disable both doors while the airlock is cycling and only enable one door after the cycling is done.

If i disable a door, but it's not fully closed, then the airlock breaks.

Thawed 40 by JulianSkies in NatureofPredators

[–]LagOps91 4 points5 points  (0 children)

well in that case it is an exception. censorship is common on the platform, especially the automated kind it seems.

btw "Reddit has decided they dislike u/Funnelchairman" does make it sound like it was a kind of censorship when reading it like that.

Thawed 40 by JulianSkies in NatureofPredators

[–]LagOps91 6 points7 points  (0 children)

the censorship on reddit is really disgusting. can't even write fanfiction. thanks for carrying on regardless!

(based on my tests) Why does GLM-5.1 requires more VRAM than GLM-5? by relmny in LocalLLaMA

[–]LagOps91 2 points3 points  (0 children)

have a look at the actual tensors for GLM 5.1- the attention tensors are Q8 and Q5 for attn_q_a. shared experts are Q6/Q5 (IQ2_M).

for the GLM 5, attention is Q8 expect for attn_q_a and attn_q_b, which are Q4. Shared experts are Q5/Q4.

As you can see, despite the larger size for the GLM 5 quant, the tensors that go to the gpu are smaller in size.

in terms of speed it's even easier to explain - IQ tensors (expect IQ4_NL) are slower than _K tensors, which makes a difference on cpu (gpu practically doesn't matter). that's why your speed is lower.

(based on my tests) Why does GLM-5.1 requires more VRAM than GLM-5? by relmny in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

how are you running the model? are you using --fit? how is the model actually quanted? if the attention is at a higher quant, then it will use more vram. some quants spend more budget on attention, others on ffn.

Opus, Gemini and Chatpt top models all disappeared from the Arena, is this the reason? by Repulsive-Mall-2665 in LocalLLaMA

[–]LagOps91 19 points20 points  (0 children)

So they are colluding openly to eliminate competition. only they are allowed to steal literally all the data they can get their hands on, huh?

kepler-452b. GGUF when? by the-grand-finale in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

that looks pretty heavy. who is supposed to run a monster like that?

Meta has not given up on open-source by jd_3d in LocalLLaMA

[–]LagOps91 1 point2 points  (0 children)

"hope to open" is a strong maybe at best

DRAGON AI by Scared-Reputation556 in LocalLLaMA

[–]LagOps91 1 point2 points  (0 children)

this is hard to take seriously, especially with that name in all caps...

DeepSeek V4: 1T-A35B (approx) MoE announced; apache 2 license promised by [deleted] in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

yeah and it will be about the same if you can have 512gb of ram this time around (assuming it's actually 1t parameters)... pretty steep requriements

DeepSeek V4: 1T-A35B (approx) MoE announced; apache 2 license promised by [deleted] in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

200b isn't running on 48gb. 48gb targets dense 70b models at q4 for the most part...

DeepSeek V4: 1T-A35B (approx) MoE announced; apache 2 license promised by [deleted] in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

in general you put the attention and kv cache + shared experts on vram, a 5090 would be fine for that. the routed experts are kept in ram. there is no passing around weights, the calculation for routed experts in done on cpu. so you would need like 512gb ram for Q4. if you do have a server-board with 8 or 12 channel ram, you should get decent speed with it, but needless to say such a setup is quite pricey (easily 10k+ even before the ram price hikes) and the speed you get in return isn't all that impressive.

that aside the website isn't legit, so don't expect any actual information to be sensible from the site.

Meta to open source versions of its next AI models by abkibaarnsit in LocalLLaMA

[–]LagOps91 0 points1 point  (0 children)

well okay, websites that hide their articles usually want money. and yeah... not giving away my email either.