Thats funny because I felt like it was a port because of the horrible control scheme. You cant move slower, so you have to tap keys to move slowly, but tapping keys does dashes, exactly the opposite what you would want. Dig around some conf files to fix it. Crouch button is c, but it doesnt work during dialogue, even if you rebind the dialogue skip button that is also c by default.
Personal preference I suppose. There are a lot of urls where the text of the url (or large parts of it) conveys no meaning. In that case it breaks up the comment without adding value. Sometimes you see people use a footnote format here because even the short url is in the way.
Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest.
For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux.
In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer.
I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested.
The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy.
In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
> For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it.
Apollo is for GraphQL. I'm not sure why you'd try to use it's internal caching system to add local application stuff. Note that using Apollo does not stop you from continuing to use Redux.
> The Query component can be fine for simple use cases, but it still ties your API calls directly to your component.
The convenient thing about the Query and Mutation components being in your markup is the access to the loading and error states within that context. With Mutation, I often end up just passing the mutate callback to an event handler method. There's always direct access to the client when you want to make normal procedural API calls.
The Apollo caching system hasn’t been all roses; it can be pretty easy to wipe out parts of a cached entity you were needing on a view with the response to a mutation on a different view if you’re inconsistent with query and mutation response structure. But I find it convenient after getting the hang of its pitfalls.
Very cool. Everyone knew about liero in my childhood. I wish someone did this for wings2, a legendary cave flier from the same era. I owe my interest in programming to the amazing lua scripting API. One summer holiday I helped create a community weapon pack with my friends. Although it was completely imbalanced it was great fun along the normal online play, which was more competetive and skill based. For several years we had a small community of around 20 people playing but sadly it died of in my teens. I wish I had a way to contact all those guys and setup a discord server for the occasional game.
I think it's normal to assume averages when comparing things.
I would be interested in some experiments of average developers learning average plumbing vs average plumbers learning average development. I'd wager theres an order of magnitude difference in the results(time spent, quality etc).
because environments everywhere have adapted to a rhythm of temperature that will no longer exist due to global warming. a good definition of damage is "harmful change."
Get rid of dailies and status checks from stakeholders and you dont need this tool in the first place.
But if you can't then it's a nice little project to make ones life a bit less miserable.