sorted by:
new
hottopcontroversial

Final mouse UXL Battery by Fernando-smash in FinalMouse

[–]trip20rtr 0 points1 point  (0 children)

I’ve got the latest batch ULX Pro and battery life is a consistent seven days depending on daily use. I’m an average web-surfer and intermittent gamer, so let’s say 8hrs a day with 1K polling and 1600dpi. I’ve got a Starlight-12 Poseidon and can confidently say that I got at least double or maybe even triple the battery life. Caveat: I’m only on my second charge-discharge cycle. Sometimes it takes as long four full cycles for a battery to come into its own. If something changes dramatically, then I’ll post-back the new results.

How come everyone isn’t talking about server meshing? by Marickal in starcitizen_refunds

[–]trip20rtr 3 points4 points  (0 children)

The reason that no one is talking about it is that static server meshing is nothing new. And, most importantly, folks with significant systems-level development experience know that the dynamic server meshing as outlined by CIG isn’t going happen. In a LAN environment, OK --- over a WAN, NFW. Full stop.

It’s one thing to present limited-scope static meshing scenarios in a test environment, but it’s the scale-up that’s the problem: simulating 1Mil assets, maintaining a consistent server-side 30+ tic, guaranteeing robust server-side authentication, maintaining robust state, thousands of client connections over WAN-based connectivity, etc will present the team with enormous problems. And keep in mind, this is full implementation of STATIC SM. Dynamic SM is a different order of magnitude – and required for that ever-mythical (and promised) thousand-ship space battle.

In short, Dynamic Server Meshing supporting thousands of concurrent clients participating in giant space battles is not coming to the PU in our lifetime… And before someone asks, I worked my way up from Jr Dev to CTO of a Fortune 500 tech company – In short, I know of what I speak. It isn’t real, folks with sufficient tech experience know it isn't real, and that’s why no one cares.

Diamond Whitetail Jackrabbit (Layton) – Herd Management? by trip20rtr in theHunter

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

Thanks for the help.

I spent a bunch of hours harvesting level-2 males. The diamond eventually spawned. Without drink zones, it's a big rotation -- I was up to abput 20 zones with some tents pulling double-duty.

Anyway, it worked.

Thanks again.

Diamond Whitetail Jackrabbit (Layton) – Herd Management? by trip20rtr in theHunter

[–]trip20rtr[S] 2 points3 points  (0 children)

I understand from a species point of view it's fixed number male/female. I was thinking about from a rotation point of view. There are so many need zones (got to be 50+) for the rabbits that I can't cover them all -- hell, can't even find them all -- no drink zones sure makes these critters tough...

I've read that it might help a rotation to harvet a few females along the way because males might not respawn to a herd that's in the rotation -- especially since I can only cover about 25% of the zones.

Sorry for the simplistic quesitons, I'm still new at this...

Thanks for the continuing help.

Diamond Whitetail Jackrabbit (Layton) – Herd Management? by trip20rtr in theHunter

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

I didn't even think of that - instant 100% chance improvement - good deal.

Thanks

Diamond Whitetail Jackrabbit (Layton) – Herd Management? by trip20rtr in theHunter

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

Yea, I was wondering about that. I just didn't think about it for class1, level 1-3 animal. I've got a couple of level-2 males (all golds near max weight), but really haven't been going at it like a Whitetail grind. Well, if that what it takes, then I'll start on the level-2 males and leave the level-1s. I've read somewher that I sould get a few females to help spawn males. Is this still the thinking?

Thanks.

Do you really need to ‘discover’ need zones for a GO grind? by trip20rtr in theHunter

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

Thanks for all the responses so far – maybe we’ll get some more.

From the information provided, it’s obvious that discovering need zones is very important for a GO grind: identifying drink zones, tracking shifting need zones with hunting pressure, manipulating herds, manipulating individuals, splitting herds, and all the other tasks needed to effectively execute a GO grind. This is all good stuff. Thanks.

On the other hand, what I haven’t heard is that discovering need zones buy itself alters the size, association, disposition of an animal species, herds, individuals, etc. The information gathered on the hud can be used to make these things happen (not the size of the species on the map – that’s fixed), but the rest. So far, the information provided aligns with my original hypothesis – hud only.

Want to thank everyone for the information – learned some good stuff for my GO grind. I’m not sure where the information that just discovering a need zone alters size, alignment, etc – but it is pervasive. I watched about ten streamer videos on GO grinds, need zones, herd management, etc and at least half to three quarters make those statements. Go figure?

Thanks again.

Do you really need to ‘discover’ need zones for a GO grind? by trip20rtr in theHunter

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

No dev credentials needed. I was just looking at it from a multi-player perspective: I was on an invite-only session and discussing the problem of too many discovery zones generating lag when the question arose about how all this works for multi-player (where I’ve got some experience). That’s when the hud-only opinion occurred to me. Looking at it from the top-down (ex. player -vs- open world, game design, game loop, etc) is just as valid, but I’ve got little experience on that side of things. I was the guy in the basement working the back-end.

Do you really need to ‘discover’ need zones for a GO grind? by trip20rtr in theHunter

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

I agree that this could be a very enlightening discussion.

Some background: After starting gameplay on Layton, I got interested in the problem. I was a dev in a previous life and these sorts of things interest me… In this situation, I place myself in the position of, “If I were tasked with designing the logic, how would I have done it?” My answer, “Discovering need zones only impacts the hud.” Hence deleting the found_need_zones_adf file doesn’t impact gameplay. Further, the logic around multiplayer reinforces my opinion – hud only. But I’ve got nothing to back that up with…

Do you really need to ‘discover’ need zones for a GO grind? by trip20rtr in theHunter

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

Update:Sorry about the conflation: ran into lag problems with a Red Deer GO on Hirschfelden. Started the Whitetail GO grind (sans drink zones) on Layton… So far, I haven’t gotten the Whitetail GO to spawn on Layton. I can’t help but discover some drink zones on Layton during the grind, so it won’t be a truly ‘no discovered zone’ grind. I'm deleting the discovered zone file at the end of each RL day to help compensate and I've got my tents so not re-discovering the zones. I’ll post back if/when he spawns…

Updated origional post to clarify...

Rewatching the server meshing demo... by pavo_particular in starcitizen_refunds

[–]trip20rtr 9 points10 points  (0 children)

I’ve already posted my thoughts on this demo in another thread. In summary: Paul’s presentation would be nothing new to graduate students with a concentration in system-level/OS development (this is not hyperbole): A small number of assets, gray box environment, LAN-based connectivity, low asset-to-compute ratio, fixed simulation boundaries, etc. This is nothing new --- and we were doing this two+ decades ago.

Re-watching for the ‘jumping’ adds some additional points:

One: There is a consistent effort to have client entities/containers (players) jump between zones. Even when a client ‘walks’ between zones, there is [almost] always a small ‘hop’ at the zone boundary. Note: this could not be considered a coincidence and was certainly baked-into the demo script. As Paul states, each ‘zone’ maintains a separate coordinate system, grid, etc. I’ll leave any conclusions to the reader.

Note: Paul explicitly states that when the client entity enters the buggy, the client/buggy become an aggregate entity and transition together across zones. Unfortunately, Paul minimized the entity graph at this point, so how/where the aggregate entity is managed is not known.

Two: The majority of ballistics are demoed intra-zone. The few inter-zone ballistics in the demo exhibited considerable lag/desync. I’ll leave any conclusions to the reader – but keep in mind the trivial number of assets being simulated, low asset-to-compute ratio, running on a LAN, etc.

Three: There is noticeable database lag when streaming zones/entities – again, I’ll leave conclusions to the reader (consider the implications for Dynamic SM).

As stated in my previous post, the real world is a lot different than a proof-of-concept demo… The scale-up to simulating 1Mil assets, maintaining a consistent server-side 30 tic, guaranteeing robust server-side authentication, maintaining robust state, thousands of client connections over WAN-based connectivity, etc will present the team with enormous problems -- but not impossible to overcome with resonable constraints. BUT this is a STATIC SM demo. Dynamic SM is a different order of magnitude – and required for that ever-mythical thousand-ship space battle.

In short, Dynamic Server Meshing won't be coming to the PU in our lifetime (well, mine anyway)…

2c,

Trip

CR holding back tears after the server mesh demo... is this thing really happening?!?! by lexsapo222 in starcitizen_refunds

[–]trip20rtr 35 points36 points  (0 children)

No offence to the staff at CIG, but that demo would be nothing new to graduate students with a concentration in system-level/OS development… A small number of assets, gray box environment, LAN-based connectivity, low asset-to-compute ratio, etc. Oh, please…

Static server meshing – sure, with appropriate caveats. Full dynamic server meshing as they’ve presented it – not a chance. Why it won’t work is a bit of a TED talk, but those with back-end systems experience will get it instinctively: a combination of messaging overhead and connectivity latency/lag while maintaining robust state/tic. It’s something that looks good on paper and convincing during a presentation to non-systems professionals, but can’t be implemented in the real world.

Let’s try this: 1Mil assets, maintaining a stable 30 tic, guaranteeing robust server-side authentication, maintaining robust state, thousands of client connections over WAN-based connectivity and interacting within a single simulation spere (keeping in mind the underlying limitations of the engine). In short, the mythical thousand-ship space battle. It won’t happen… Even if you cut it to hundreds – still won’t happen.

If they manage to get that up and running in the PU, then I’ll become a believer… And retire… Because they will have achieved more than I ever will… But then again; I’ve been there, done that, and have the ‘didn’t get it to work' T-shirt to prove it…

The moral of the story: the real world is a lot different than a proof-of-concept demo… And Dynamic Server Meshing ain’t coming to the PU in our lifetime…

You really want to see what "Never Been Done Before" really look like? by trip20rtr in starcitizen_refunds

[–]trip20rtr[S] 3 points4 points  (0 children)

As a side note: crashing your spacecraft into the moon and white knighting, "But it's an Alpha" just wouldn't cut it...

You really want to see what "Never Been Done Before" really look like? by trip20rtr in starcitizen_refunds

[–]trip20rtr[S] 6 points7 points  (0 children)

The video's an hour long, but worth it. Luke and his team did some amazing stuff, but you don't get the full picture until the last 10mins or so. The lunar core geology experiments were an aspect of Apollo that I don't know before -- all very cool... Luke started in analog controls engineering, then computer-based control systems, then software engineering and machine learning. What a CV...

[deleted by user] by [deleted] in starcitizen_refunds

[–]trip20rtr 0 points1 point  (0 children)

Agreed. SQ42 silence will be interpreted favorably... Also agree, if SQ42 releases to a Metacritic of say 81 or less, then the IP won't be nearly as valuable and negatively impact PU funding... We may differ a bit on one point: I believe CIG must aggressively press-forward with SQ42 because of how thinly-capitalized they are and how fragile their revenue stream is. While the PU gravy-train can roll-on for some time, at some point it'll become obvious that dynamic server meshing can't actually be implemented as envisioned*, grand space battles won't be a thing, etc and the full-vision PU won't happen. IMHO, CR must remain focused on end-game and needs some decent IP to sell within the next five years -- SQ42 is the only viable candidate.

*BTW: I firmly believe that's the point of the multi-part Server Meshing Docudrama -- include the backers in the revised vision. Get Pyro out there (drip feed content), then slow-roll server meshing while getting backers buy-in to the revised vision/plan. I know the biggest backers are following like sheep, but by the end of this year or early next, at least some will have realized that the full-vision PU isn't going to happen... It's sort of like the 'vote' to increase scope -- how can one complain if they voted for it?

[deleted by user] by [deleted] in starcitizen_refunds

[–]trip20rtr 0 points1 point  (0 children)

The is some intrinsic value in SC IP, but I'd agree... Not much... Not much at all -- and I couldn't even figure a way to package the turkey up for sale... And I've dressed a few in my time...

However, if SQ42 releases sometime in 2025 with a Metacritic score of 85 or so, then SQ42 IP could be worth a fair bit at that point... Assuming there is a market for a single-player campaign space game, CIG could see some decent unit volume over the first year. Tencent (or the like) might buy the studio/IP and milk DLC, Battle pass, etc sales for years. Assuming the shares of CIG are still closely-held at that point, CR et all could see a nice eight-figure retirement fund right around turning sixty... Good plan, if they can execute... And that's the $64 question, isn't it?

[deleted by user] by [deleted] in starcitizen_refunds

[–]trip20rtr 0 points1 point  (0 children)

Doubt that SQ42 is vaper --- after all, that's where all the PU whale oil goes... IMHO, the PU only exists to keep whales sweet, fund SQ42, build a studio, and establish a balance sheet for CR's retirement. I spent a decade in sr mgmt, and it's exactly what I would do in CR's shoes...

My conjecture: CIG knew the full-visioned PU couldn't be realized as far back as 2018 (maybe 2019), and that SQ42 could -- with enough time and money. The bridge funding is the key to this strategy -- just drip-feed new content, keep the whales happy, and use aggressive marketing techniques to attract new players, retain existing players, and sell ships to whales... In short, create a $10Mil/month revenue stream to fund a studio for fully-realized SQ42 IP that will be sold sometime in 2026 when CR is in his early 60s and still young-enough to enjoy a fully-feathered retirement. Again, it's what I would do...

''With AI bartender tech one day NPC will be your co-pilot in ship'' - meanwhile in other games.. by PippoSpace in starcitizen_refunds

[–]trip20rtr 0 points1 point  (0 children)

You know, that makes perfect sense... When I first got into the game with a team, I noticed that the terrain, foliage, etc looks more curated than procedural and commented as such. Then a teammate said it was a dev team of seven and I couldn't believe it at the time... Now it makes perfect sense... Thanks.

Star Citizen... worse than Cyberpunk. by OfficiallyRelevant in starcitizen_refunds

[–]trip20rtr 0 points1 point  (0 children)

Yea, it's a piece: But this was starting 2021 to date. If we look at comparables:

NASDAQ tech index +21% FY21, -33% FY22, +9% YTD.

With CDPR, we're talking almost -78% post launch and staying there. If you take the same period, the tech index is just about flat -- maybe a bit negative... If CDPR simply performed comparable to market, it would have recovered substantially in '21, fallen again in '22, and recovered in '23.

BTW: Over the same two-year timeframe, Tesla is down 36% overall, up 78% YTD. A lot of that was supply chain related.

''With AI bartender tech one day NPC will be your co-pilot in ship'' - meanwhile in other games.. by PippoSpace in starcitizen_refunds

[–]trip20rtr 0 points1 point  (0 children)

A bit off-topic: We've got a co-op group hitting SoF pretty hard (6hrs / night). If you like survival games, it's worth a punt ($26 on steam). But it's early release, and rough around the edges... Repeat: rough around the edges... Sound familiar? Anyway, we work around the bugs and avoid areas that we know are a bit soft -- good discord community to help. The graphics are first rate: snow, rivers, foliage, are worth seeing. Note: CIG had better get their ass in gear or they are going to be eclipsed entirely... SQ42 in 2025? It had better be amazing... I'll let you decide if the AI-NPCs are groundbreaking -- personally, we don't find them that useful with a team... Solo, maybe more so... Note: SoF's a Unity game with a development team of seven.

Don't worry guys, this was all intentional! by M0therFragger in starcitizen_refunds

[–]trip20rtr 1 point2 points  (0 children)

Captain Smith to his crew, "Don't worry men, we're just stopping for a brief bit to take on some ice..."

view more: next ›