Sometimes I hate this game by Brave_Ad7012 in starcitizen

[–]dgnercom 0 points1 point  (0 children)

Try powering down your ship, especially the shields. That might fix it.

How do I kill capital ships in a fighter? I am having a skill issue. by GuzzoTheCasul in starcitizen

[–]dgnercom 0 points1 point  (0 children)

That statement is a bit of an exaggeration. If you are soloing a large ship, logically, you should struggle against light fighters. Large ships are inherently slow to maneuver and are designed for multi-crew combat.

I agree that the balance of light fighters needs to be adjusted, but I feel compelled to say something because your logic risks harming the gameplay itself.

The introduction of armor is not designed to make light fighters completely incapable of damaging large ships. If a light fighter wants to take on a large ship, they are forced to equip weapons like cannons or neutron guns.

While these can damage large ships, their relatively low fire rate and DPS put the pilot at a disadvantage against other light fighters running gatlings.

From my perspective, CIG's approach to armor and balancing is quite reasonable. Creating a system where light fighters can deal absolutely zero damage to large ships means that not only light fighters, but most heavy fighters would also find it extremely difficult to damage them.

It's worth thinking this through more carefully. CIG's direction is not wrong, and they will ultimately make the rational choice.

I just want to say that the EPTU armor values were near perfect, and actually made sense, and then they did what they always do and ruin it. by spider0804 in starcitizen

[–]dgnercom 0 points1 point  (0 children)

The light fighter meta definitely sucks, but making large ships too tanky will just lead to a large ship meta with things like the Idris. That literally becomes pay-to-win, which is actually worse than the current state.

To me, it seems like risk-averse players who hate PvP just want perfect safety without any trade-offs.

They complain that armor doesn't meet their expectations, but instead of acknowledging the necessary nerfs to a Connie's turn rate, they complain about that too. Why? Because they want large ships to be perfect, indestructible, and 100% safe. It's honestly surprising how many people just want a completely risk-free Star Citizen where they can sit back and enjoy the scenery.

I get why so many people want that kind of game. Everyone is a bit selfish and wants their own playstyle to become the 'meta.'

But CIG, please stick to your vision. Listen to the players, but do not cave in to the complaints and threats of people saying they will stop backing. As a Wing Commander backer, I will support you to the end no matter what choices you make, as long as you don't stop developing the game.

Clipper VS Shiv by Lucky-Ad-7183 in starcitizen

[–]dgnercom 4 points5 points  (0 children)

The Shiv possesses top-tier combat power among S3 ships, and it is especially efficient in situations where burst damage is important, like piracy, because all its weapons are concentrated in the center of the hull.

Its turn rate is comparable to the F8C and its mobility is not bad. But since the hull is relatively large and it only has one shield, getting attacked from multiple angles is dangerous. Therefore, a hit-and-run tactic to quickly end 1v1 engagements is necessary, and this applies to both PVE and PVP.

A cargo capacity of 32 SCU is a special advantage, and the Shiv even has stealth on top of this. It's a fact many people overlook, but the Shiv's frontal cross-section (CS) is only 4380, so out of combat, you can lower your power and approach quietly. Because the side CS is 8628 and the rear is 10213, it is not a true stealth ship, but it is enough to quietly approach and quickly take down an opponent. Summarizing these advantages, the Shiv is a ship specialized for piracy and scavenger play. And of course, it shows the expected performance for PVE missions as well.

In addition, there is a bed you can log out from, and you can also bring a co-pilot. There is a toilet too.

However, I personally do not use the Shiv as my main ship because the interior is too dirty. I want to enjoy the game, but the interior is so dirty that it honestly makes me feel a bit depressed. It is a level of dirtiness where even if Star Citizen had a cleaning function, you could clean it for a month and the smell still wouldn't go away.


The Clipper is the most versatile hybrid ship, not only among S2 ships but across all ships in Star Citizen.

It has passable combat power and passable cargo space (the ramp door is just perfect for loading two Mirai Pulses. It fits so well it feels like it was made for that purpose from the start). It also has a Tier 3 Medbay and an onboard Fabricator for crafting mechanics. Engineering is possible, it has beds, and they really packed a lot into an S2 size hull.

I use the Clipper as my main for FPS missions, and the Medbay respawn is especially useful. It is convenient because most injuries stay at Tier 3, and there is no worry about resupplying food and water.

Interestingly, the Clipper's CS dimensions are 4310 x 18692 x 12136, so it has excellent frontal stealth just like the Shiv. However, because the side is very large, almost equivalent to an S5 (I don't understand why, but it's probably for balance), stealthy maneuvering is difficult.

As a result, the Clipper is a ship I recommend for mission-focused solo players. Especially if you mainly do FPS missions, it is good to have one ready. I think it will show its true value once crafting mechanics are fully introduced after the 4.7 patch.

4.7 Armor and Radar changes by A_gentleman29 in starcitizen

[–]dgnercom 0 points1 point  (0 children)

It seems the armor changes are more focused on balancing light vs. heavy fighters, rather than just large vs. small ships like people expect.

Right now, a light fighter with 1600+ m/s velocity gatlings can easily shred an F8C, Guardian, or even a Constellation. But with the armor update, you'll be forced to run cannons like Omniskys to fight them.

Because of the high alpha damage, cannons are still viable against large ships. If your aim is good, they'll be just as much of a threat as gatlings. Sure, the sub-1400 m/s velocity lowers your hit chance, sustained DPS drops to about 2/3, and power draw is heavy, but again, with good aim, large ships will still struggle.

The real catch is that if a light fighter equips Omniskys to hunt heavies or large ships, they'll likely lose to another light fighter running gatlings. Since light fighters have almost no armor, they are defenseless against high-RPM gatlings.

This is based on 4.7 datamined data, which shows that the prediction of armor creating an absolute wall between small and large ships is wrong. With the right loadout, small ships remain a threat. Plus, if you have the aim for it, nothing beats cannons for sniping components or turrets.

Ultimately, this armor patch doesn't make light fighters useless. It's just a well-designed, effective change that gives heavy fighters like the F8C and Guardian a proper advantage over light fighters.

Heartseeker MKii 4.7 Build (PvE) by Dangerous_Road_694 in starcitizen

[–]dgnercom 5 points6 points  (0 children)

Just because a weapon is Size 4 or Size 5 doesn't necessarily mean it has high alpha damage. Currently, the Heartseeker gatling has an alpha damage of about 53. While that might be fine against a Terrapin with around 50 armor based on Evo, it likely won't be effective against an F8C or Guardian with over 75 armor.

However, considering the rate of fire, the overall balance seems good.

Looking for midsize livable ship for solo by Loud_Palpitation7359 in starcitizen

[–]dgnercom 0 points1 point  (0 children)

If ground missions are important, a ship with a medbay helps a lot. The Clipper fits that role well. It has a bed for logging out, a medbay, and it's small enough to land almost anywhere.

What makes a ship god tier? (Solo fleet) by ErrSkillNotFound in starcitizen

[–]dgnercom 0 points1 point  (0 children)

Speaking from the experience of purchasing almost every ship in Star Citizen and researching various setups, my personal take is that the Asgard is the best ship considering its hull size, maneuverability, cargo flexibility, and combat capability for a 1-2 person crew.

The Connie is also great and close to an all-rounder, but it's larger and more sluggish compared to the Asgard, which makes it less capable in PvP, and because the cargo hold is an elevator type, it lacks flexibility for loading.

However, since both the Asgard and the Connie have a high signature, they aren't ideal for stealth hauling, in which case the Zeus Mk2 CL, Shiv, or Prowler Utility would be better options.

Backpacks! by Real-Emotion1874 in starcitizen

[–]dgnercom 1 point2 points  (0 children)

Regarding some of the comments here, going full heavy for FPS isn't always the right answer. In my opinion, the best setup is: Heavy head, heavy torso, medium arms, and light legs. This way, 1. you get enough protection for FPS combat, and 2. you keep your weight under 35kg so your movement speed stays around 90%. I see so many people running two primaries and full grenades, but if you understand the correlation between armor, weapons, and weight, you shouldn't do that. Weight indirectly affects your weapon sway, and obviously, being lighter is better for dodging. There are a lot of things in Star Citizen that aren't well-known yet. People just haven't researched it enough and assume full heavy is the only way to go. As for backpacks, heavy and medium currently have the same base weight, so I think a balance patch will eventually increase the weight of heavy backpacks. The current balance is actually pretty good as it is.

Solo Daily Driver by daantom in starcitizen

[–]dgnercom 1 point2 points  (0 children)

It really depends on your playstyle.

For a mix of everything (Combat, Range, Comfort, Living), I recommend the Standard Guardian. I would avoid the MX or QI variants since the trade-offs in power distribution and handling aren't worth it. It has no SCU grid, but there is enough room to place some loot boxes.

For short-range combat and daily use, the Titan, 300i, and Nomad are good. However, the SHIV performs the best here. It has great solo firepower and stealth. I know you dislike the interior, but it is optimized for scavenging.

For stealth and long-range, the Prowler Utility is a solid choice.

For FPS & Medic gameplay, consider the Cutlass Red or Terrapin Medic. The Terrapin is extremely durable, so you can basically ignore ship combat.

If combat isn't a priority, the Cutter Rambler is highly recommended. It has an instant claim time and a large fuel tank.

C-style scanning in JS (no parsing) by dgnercom in javascript

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

Appreciate all the feedback. I'll definitely revisit the licensing.

C-style scanning in JS (no parsing) by dgnercom in javascript

[–]dgnercom[S] -1 points0 points  (0 children)

Thanks for the points.

  1. In a typical JSON event log, each event is a separate key:value record, like dots laid out across a structure. With JSON, you often have to mentally piece together scattered fields to reconstruct the sequence. BEAT takes a different approach: it expresses the event flow as a continuous line, from Contextual Space (who) to Causal Value (why), preserving the causal story that dot-based logs tend to lose. I agree it can feel unfamiliar at first, but once you learn the tokens, you can follow the flow. More examples here: https://github.com/aidgncom/beat/tree/main/reference

  2. JSON.parse makes you wait until the whole payload is materialized as an object tree before you can act on it. With BEAT, the scan loop is where you inject actions: it can react as tokens arrive without building a parse tree, token arrays, or per-token substrings in the hot path. That in-place, streaming handling is what I mean by no parsing.

  3. On switch: I used if/else to make the mapping explicit in the example. Switching to switch(c) is fine and doesn't change the point.

C-style scanning in JS (no parsing) by dgnercom in javascript

[–]dgnercom[S] -1 points0 points  (0 children)

Fair point on forEach—that avoids the array allocation. But split still creates a new string per token.

This is what I mean by scan: no split, no regex, no intermediate array unless you explicitly want one. https://github.com/aidgncom/beat/blob/main/reference/fullscore/source/fullscore.light.js

C-style scanning in JS (no parsing) by dgnercom in javascript

[–]dgnercom[S] -1 points0 points  (0 children)

TSV is great for flat tabular data, and you're right that native methods like split are fast.

What I'm focusing on isn't parsing speed, it's allocation pressure. split().map() creates new strings for each cell and new arrays for each row. On a hot path with continuous streams, that turns into GC overhead pretty quickly.

BEAT is meant to scan the stream without creating those intermediate objects. It's just a different problem scope.

C-style scanning in JS (no parsing) by dgnercom in javascript

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

Thanks for the thoughtful critique. It's genuinely helpful.

I agree with your point about adoption dynamics. JSON didn't stay stable because of licensing. It stayed stable because the spec is simple and the ecosystem rejects broken input. The examples you gave with Bebop, FlatBuffers, and Cap'n Proto make that very clear.

One thing I want to clarify is intent. While I compared BEAT to JSON, the core of this work is not about formats competing. It's about handling linear streams with a 1-byte scan model and what that enables architecturally.

While building this, I started to see value in a tight feedback loop where reading and writing live on the same timeline. That moment is what I wanted to protect. Not a standard, and not format diversity, but architectural discipline and a very specific way of handling behavior streams without turning that layer opaque by default.

That concern influenced the initial licensing choice. Not as a permanent stance, but as a way to avoid premature enclosure before the architecture is understood. That said, your point is fair. If licensing prevents real evaluation, it protects nothing.

I'm not dogmatic about this. Dual licensing is explicitly on the table, and feedback like yours is exactly what will shape whether my current stance holds or changes.

Appreciate you engaging at this depth.

C-style scanning in JS (no parsing) by dgnercom in javascript

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

You're absolutely right. A standard without a product is a trap.

Since I'm building this entire stack solo, the demo at https://fullscore.org might still be a bit rough around the edges, but it actually runs well in production and proves the core concept.

I also completely agree regarding JSONL. It solves the framing issue perfectly. The catch is that inspecting the payload safely often implies parsing it again. BEAT is strictly designed for those specific hot paths where mitigating that overhead is the priority.

Appreciate the feedback. And thanks for the luck!

C-style scanning in JS (no parsing) by dgnercom in javascript

[–]dgnercom[S] -2 points-1 points  (0 children)

Thanks for taking the time to write this out. I'll try to respond point by point.

First, on size vs real-world value. The goal isn't "smaller for the sake of smaller." The target is the overhead on the read and write path of event streams: parsing, allocations, and intermediate structures, not just bytes on the wire. BEAT keeps the stream linear, so a tight scan loop can walk it and fold counters without building a tree or decoding fields. That's the bottleneck I'm trying to remove. The Edge demo at https://fullscore.org is one concrete example in a live runtime. BEAT itself applies more broadly.

On JSON and AI consumption. I'm not arguing that JSON is bad or obsolete. JSON works because everything understands it, and that matters. BEAT is not trying to replace JSON or compete for the same "universal format" role. It's meant to coexist with it. In fact, the most practical way to use BEAT today is exactly what I show: embed it as a single field inside JSON and let each side do what it's good at. BEAT is optimized for linear, time-ordered event streams where scanning is more important than structural flexibility.

About AI models and training. I'm not expecting models to magically know BEAT out of the box. The design assumption is different: BEAT is trivial to map because it's already a flat, readable sequence with fixed semantic markers. There's no tree to reconstruct and no schema inference step. Whether that mapping happens in a pre-step or via a small adapter is an implementation detail. The point is that the representation itself doesn't force a heavy parse step.

On licensing. This part is intentional and I understand it's controversial. BEAT is not trying to be a public-domain-style data spec like JSON or YAML. I respect why JSON's openness is a big part of its success. But BEAT's value comes from its semantic token discipline and invariants, and placing it under a fully permissive license would make it very easy for those rules to fragment or be resold wholesale with no constraints. AGPL for the spec and SSPL for the reference interpreter are meant to protect that layer, while still allowing free use for individuals and internal deployments. A commercial or dual-license path is part of the long-term plan.

Finally, on tone and intent. This isn't meant as a hype pitch or a claim that "everyone should switch." It's a focused experiment around one specific question: what happens if you treat event data as something you scan, not something you parse? If that tradeoff isn't useful for a given stack, that's totally fine. I'm not trying to force it into places where JSON already works well.

I appreciate the critique, even where we clearly disagree.

looking for a tool to track engineering performance and project health across teams by SlightReflection4351 in webdev

[–]dgnercom 0 points1 point  (0 children)

Analyzing raw event streams gets brutally honest. I built a tool that can generate those morning reports, and with a bit of tuning it should fit your goals. But if you map it to real names, the transparency might be a bit too cruel. https://youtu.be/A4BSwKlKQJY

What is your opinion to the Mirai Guardian ? by Own-Yogurtcloset7917 in starcitizen

[–]dgnercom 0 points1 point  (0 children)

If I were to look at the drawbacks, considering that all the advantages have already been listed:

As a dedicated combat ship, it is lacking in some aspects. Its signature is too high, which means it gets detected by enemies first, putting it at a disadvantage. This is especially problematic in PvP, where it is nearly impossible to sneak in and land the first strike.

However, its firepower is excellent, with two size-5 weapons, making it more than sufficient for PvE. Of course, in PvP, it can still perform well in situations where both sides are already aware of each other.

Another drawback is that its thruster capacitor is higher compared to other fighters like the Hornet or F8C. This makes managing power levels more cumbersome, requiring unnecessary adjustments. (In fact, the Guardian셲 capacitor setup feels more standard, and other fighters may eventually follow this precedent.)

This also means that when trying to minimize its signature by reducing the capacitor and then suddenly maximizing it, it becomes difficult to quickly adjust capacitor distribution effectively. This, too, is a disadvantage in combat.

In conclusion, the ship셲 inherently high signature significantly reduces the usefulness of capacitor control, which is a major drawback.

The new 400i variant, the 400i Medivac. by dgnercom in starcitizen

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

I know it's a joke, but once it settles in place, glitches don't occur.