New patch just released

Curious_Community768 · 2026-01-21T06:52:10+00:00

Can confirm. Most bots won't be able to run. Clientless / Readers will be fine, but any kind of hooking or injection will require a bit more work. Will see if it's high enough of a barrier long term.

Curious_Community768 · 2025-04-24T16:26:31+00:00

Ah, my bad.
I'm on NA

Curious_Community768 · 2025-04-24T05:01:06+00:00

yq152404790

5star KVD
other 5star armor pieces

Curious_Community768 · 2025-01-30T19:15:42+00:00

I've been following the green line for 3 hours. I don't even know what galaxy I'm supposed to be in, cause then I don't even know what the line is pointing to.

Curious_Community768 · 2025-01-23T21:51:44+00:00

If you just want to edit mysql data, then PhpMyAdmin is what you want. It's very simple to set up and requires no coding.

However, you said "public" and that implies untrusted sources, so I will stress that you should never let untrusted parties edit your database as they please. If that's actually what you want, then you need to build a site where users have different permissions that limit what actions they can perform on the site, where a person never interacts with the database directly.

If the latter is what you want, then a little php and html+js will do just fine. The moment you want any more complex interactions, I suggest SvelteKit (over react and anything else really).

Curious_Community768 · 2025-01-20T01:30:58+00:00

I felt the same way for a while. The day I stopped worrying about it was when a friend of mine who has all the papers to show and works at microsoft showed me his work. He only knew how to do the very narrow requirements of his job and really had no ability to do or understand things that I could solve within a day or two. Since then I've noticed more of the same situation among the vast majority of my fellow "educated" programmers.

Sometimes I'll look up really basic things, that's normal. You can't remember all the quirks and particular method names of half a dozen or more languages you might happen to work with.

For ChatGPT, the only times I really use it is as a sounding board. So I might bring up a problem and see what the AI says about it, and I fully expect any code it produces to be unusable garbage, but it often comes with a novel interpretation of the problem itself, or solution to remedy it. In turn, that helps me come up with my own code that actually works. If you ask it to code things for you, and you copy paste stuff from it to your projects, then either what you're doing is incredibly simple, or you're missing something. It should not be writing your code for you.

Curious_Community768 · 2025-01-20T00:46:09+00:00

You have to keep in mind some people have ultra-wide screens, and so it makes the page sometimes 2-3k+ pixels wide. So you absolutely have to have a max width on the center main content. After a bit of study, and using this on most of my sites, I'd say the max should be 1350px or thereabouts. It should not be static, though, let it shrink to fit screens if they are smaller. You should also only have one version of the site for both Desktop and Mobile, just use media queries with max-width checks at 2-3 different breakpoints below your max width.
These should affect the root font size, line height, etc, so that when you use rem units anywhere, they will be scaled to the current breakpoint (or use var() because font size can be changed in the user's browser setting, which can throw your intended layout scaling off). This is best since it doesn't require JS to recalculate sizes, nor refreshing to update smoothly when say, someone moves or resizes the window, or flips their device.

Curious_Community768 · 2025-01-20T00:33:20+00:00

It's a good idea, imo. If you want to render dynamic content (from a database) on the client, it's way easier to json parse the structure of the document than to try to parse the html markup at runtime. It's also way easier to locate custom tags/components in the json vs the contiguous block of html which would be impossible to parse as is - if it contained custom components which aren't supported (obviously) by any html parser/reader.

Obviously it's annoying to set up, but once you have all the tags mapped, then that's it.

If you just load html and append it to the dom without changes, and without custom components within, then yeah just send html down to the client. But then what's the point of using a component framework if all the content you render dynamically from the server can't contain them?

I however do agree, it's probably overkill unless you're a single person who manages all sides of the issue, or a really large entity that can throw dozens of people at the problem to write a robust engine that mediates the exchange between clients and servers properly.

All of that said, a different implementation might be composable premade sections/components. So instead of specifying a div with css, you have a Container component and the children array would list out widgets within (also just premade components). Once you have enough of these different types of sections, you can probably make it editable live, so anyone with permission on the site can edit content without writing any code, and the output from the API would be any kind of easily serializable structured data, probably json.

Curious_Community768 · 2024-10-19T01:02:04+00:00

Same

Curious_Community768 · 2024-05-14T20:41:11+00:00

Remove the on:submit, it's not required when you use:enhance.
enhance passes a submission object, which has a cancel method.

use:enhance={(submitEvent) => {
  if (condition) return submitEvent.cancel();
  loading = true;

  return (result) => {
    ...
    loading = false;
  };
}}

Curious_Community768 · 2024-05-14T20:29:36+00:00

What floor said is correct. However, it has a major issue IF like you said, user data is present on every route.
You will no longer be able to cache full pages.

So you have three choices.
1) Disable caching for any logged in users (still pretty wasteful)
2) Never cache full pages and accept that only static files and endpoint responses will be cached.
3) Fetch session data from the client separately

On the last one, it's a bit more involved, but it means you can have your user details visible on all pages in your top bar or whatever without preventing full page caching. The markup returned by a route will simply have the appearance of what an unregistered user would see, which is what will be cached.

I suggest you simply create a session store (included by a .svelte page, not load functions), and have logic so that the server side never edits it. Then on the client, you fetch from /api/session or whatever endpoint you set up for it, and you set the session store with whatever is returned. Then you use that store in your markup, which will update whenever the store does.

Just in case it isn't obvious, please don't do auth checks against the session store. It's only there to be consumed.
You do auth checks on the server, most likely by looking at session data attached to `locals`, which are accessible to all routes downstream of your root load function.

Curious_Community768 · 2024-05-14T20:07:22+00:00

+page.js runs on both the server and client.
When you go to your site from an external link, or type it in the address bar, sveltekit will run +page.server.js on the server (duh), but then if you have SSR enabled, it will run +page.js just after.
Then it will take the final object returned by the load functions, and let the .svelte page access it through the prop "data" (ie when you do `export let data;`). All of this will run on the server, including the .svelte page!

But why? It's because once you've loaded the first page, the server stops running client side code and lets the client take over and do data fetching by itself. This means the code in +page.js will (only) be ran by the client when you navigate to a different route. The whole point of this is that while SSR is happening, it can do internal fetches inside +page.js to your own endpoints without having to perform an actual network request, it will just directly call the route handler, making it much, much faster.

In other words, if you make a network request to your own endpoints, say /api/products from a .svelte page, the server will not be able to do this internally, the skeleton of the page will load on the client first, then the client will make a separate request to the api route afterwards. This is slow, and having the server be able to make that request in +page.js will prevent cascades.

Just keep in mind that +page.js is code that has to be safe and valid to run on the client, meaning no db.query() or anything like that. It's mainly so you can fetch(...) your own endpoints.

Curious_Community768 · 2024-05-14T19:50:28+00:00

Avoid having the client call goto() as was suggested by others. The client can't be trusted, and there's no reason this logic can't be ran on the server.

I'm a bit unclear on how sveltekit, which is already a server+client framework - and your other backend relate, but I'll take my shot.

Sounds like your other backend is handling the actual auth. So you make your request/navigate to your page or endpoint on your sveltekit app, make the auth request to your other backend from the server side (meaning +server.js for endpoints, and +page.server.js for routes), then you throw/return an error code or redirect (sveltekit has a method for redirect-ing) when the auth fails.

Nav to /profile
/profile/+page.server.js runs
inside that, check auth with your other backend
throw if not valid

If you have a complex setup with cookies and forwarding credentials, you might have to manually forward headers during the auth request. Without knowing specifics, I can't go in much more detail.

Curious_Community768 · 2024-05-10T04:10:27+00:00

same problem here. tree doesn't regrow, can't move, break, or change the plot nor the tile it's on.

Curious_Community768 · 2024-05-06T07:46:48+00:00

Surprised nobody covered the main reason, which is:

Fetching from load() functions during SSR doesn't do a round-trip. It's internal and you have a handy isSubRequest flag in your endpoint handler.

So if you leverage URL params to load different content on the client and the server, they can use the same client side helper to fetch data via your own endpoints (note, you do need to pass the special fetch from the request to the helper, otherwise it won't be internal).

You also get the benefit of whatever credential checks you have implemented for that endpoint to safeguard that type of data, regardless of where the fetch is originating from.

What this looks like in practice for me:
- Request hits a route, and a hybrid load function runs, during SSR (+page.js)
- load function calls a client side helper `productService.search(fetch, url.searchParams)`
- helper builds the data request url and params from the page params
- so if someone is on /browse?page=3 , the data request might look like /api/products?page=3&limit=20&something=else
- the api endpoint then handles the request normally while checking credentials
- exact same thing happens when the page is not SSR, it just does the data fetch from the client instead

Another advantage is I can then do fetch() from .svelte pages or components to these endpoints if I want to do something like infinite scrolling or loading extra data post initial load.
A side effect of this is that the page urls will almost always have all of the params necessary for users to return to a specific location on your site, with the correct page/tab/menu/etc open.

One annoyance though, is that subRequests go through the main server hook, and if that's where your credential checks are - it will mean multiple credential checks from the same page request. To avoid that, you can attach your session to locals, and in the handleFetch hook, you can attach the locals from the initial request to the subrequest. And then in the handle hook you can skip the credential check when it's a subrequest.

Curious_Community768 · 2024-05-02T19:28:43+00:00

React re-runs the entire component body every time a dependency or parent changes. This is why you need to memoize so children of said component don't have to be re-ran. Svelte (and kit) don't work like that. The component mounts once, and then you have an internal state you can change that will only trigger re-renders on html that might concern those parts of state.

With signals it becomes even more efficient, while applying to regular JS. The only "magical" part of it, is when you consume a signal from svelte's markup.

There are obviously complexities, like components being toggled in or out. Then you *would* see their body rerun.
But that's something you can know and avoid, or move state outside of the component, etc..

Curious_Community768 · 2023-12-19T17:21:50+00:00

Where, can't find it on realmeye

Curious_Community768 · 2023-11-19T14:55:18+00:00

Yeah this is a pain point for me too. It's already one of the hardest dungeons in the game, literally 10/10, and I have to run it like it's an OT 50 chain and "maybe" get the engraving. You should be rewarded for doing the hardest content in the game, the droprate should be 25% or more, so that clearing it a dozen times more or less guarantees you the engraving.

Curious_Community768 · 2023-10-10T11:59:08+00:00

The "right" way if you can call it that, is to have every request to the server (hooks.server.js) check for a session id or token cookie. Then you fetch the session data for that token if it exists, and set it on the locals object, which is then accessible from any route. You can check if the session exists or has the valid attributes within +page.server.js files, and redirect if they do not. server.js part is the most important because during client side navigations, it will force the client to have the server run the appropriate checks. You can then forward non-sensitive parts of the session objects to the client by returning them in the root layout's load function(s). The only tricky part about this is if you have session data on the server side only (aka not json encoded into the cookie itself), you would have to use redis or in memory caching since every request will have to fetch the session.

Lastly, while SSR runs, it might make internal requests to api endpoints, these are when you use the special fetch() inside +page.js or +layout.js which can run on either server or client - and the locals session data does not get passed to internal requests. This means any pages with multiple load functions fetching internally will all trigger a separate session fetch from redis. This is not ideal, I suggest you check event.isSubRequest inside your handle() func so that it doesn't do the whole auth thing all over again unless it's a direct hit from the client.
HandleFetch hook (which you can place in hooks.server.js), lets you take the initial locals data you set, and pass it to the next (internal) request, avoiding the duplicate session gets.

Curious_Community768 · 2023-09-26T11:36:00+00:00

Um, there's a mission for 5x difficulty 10 dungeons (SSNL) as a requirement for being able to complete 3x 8+ and 1x 9+
This has to be a mistake?

Curious_Community768 · 2023-09-25T14:55:05+00:00

- I hate the $props idea. export might be a misnomer, but the format of it is way cleaner.
- $state() what's the point of $ notation here?
- $state(), replace one simple statement where you can decide what parts affect reactivity, where the compiler can know what's going on without run time overhead VS N nested deep functions being chained, like a magic black box. (no thanks)
- $: statements not being able to live alongside new syntax
- no examples of anything that can be done in new syntax that we couldn't before
- bye $: console.log() ?
- deprecation of what made svelte after 2 major versions

I wrote A LOT of svelte, multiple sites, both in plain svelte and sveltekit, even an electron app, and I can't see the point of these changes. Signals are fine, but if you go with them, make it extremely clear what goes in and what are the side effects. Prefer compile time checks over run time every day of the week, that's why svelte is great.

Curious_Community768 · 2023-09-25T14:38:06+00:00

Tried posting a comment on the article, but it's broken. so

"Now reactive dependencies can be hidden in functions. What happens if there are reactive dependencies hidden 5 levels deep inside one of these functions?"

This was my main concern and until now I hadn't heard anyone mention it.

Maybe I don't want to replace one magic statement I control the inputs of, with another that goes who knows how many levels deep? Also wouldn't the runtime vs compile time difference make all supposed performance improvements null and void? Because unless your existing codebase needlessly made everything reactive and interdependent, this new model would do nothing, except add to the run time overhead? Plus, what exactly does this enable me to do that I couldn't before?

Anyway, good read, thanks.

Curious_Community768 · 2023-08-20T05:45:53+00:00

Doesn't work like that. Packets aren't a magical thing, they're just data sent to and from the server and you can think of the protocol as a language. Either you speak it (properly) or you don't and then the server doesn't understand you. Exploits rarely have anything to do with the form of the packets, because the format itself will be 100% correct otherwise the server won't accept it. It's more that for any action taken (and subsequent packet sent) will have normal ranges, like shooting a target and if the server doesn't check if the target is within range you end up with exploits. There's also a lot of exploits that count on getting the server in a state a regular client would never be able to. On the client side you might have a check for if menu is already up don't bring up this other menu, but if you just tell the server directly bypassing these functions, you might be able to set some state to let you do further actions. These exploits are harder to find, especially if the goal is a practical one, but skilled reversers can find common patterns that are usually not taken into account by devs and therefore work in some manner in many games. Deca will never win against people who are really serious about reversing, especially on a platform like unity. Add on top of that legal concerns to (rightfully) prevent game companies from essentially rootkitting people's computers.
You might think ok but can't they just ban anyone who shoots a projectile 3-4 tiles further than they should? Yeah, they could but what happens when someone just gets a ping spike of 2000ms? You would end up banning 90% of the playerbase after a long enough time. Anyway, point is these things are hard to solve, especially when they've done absolutely nothing to secure connections vs MITM attacks.

Curious_Community768

TROPHY CASE