401–410 of 717 posts
I don't see a workflow for locking assets while they are under modification. This is kind of important for assets? Since we don't really have great merge workflows for meshes/animations/sounds/etc. I also don't see any sort of GUI client? So the whole art team is going to have to get up close and personal with the CLI
Locks: https://epicgames.github.io/lore/faq/#does-lore-support-file... GUI: https://epicgames.github.io/lore/faq/#does-lore-have-a-deskt...
Earlier quoted context omitted.
I dont think the problem is even verbosity here - it really isnt that much text. The issue is what you and the above points out - it is not easy to read. What might help dramatically is a simple modification of text (the verbose stuff could be slightly light grey and the important bits fully highlighted white) or even go full IRC with colored text, bold, etc. Or hell - maybe instead they add a switch that inserts "//…
and why don't we just follow decades of conventions and add a --verbose/-v flag to display all the gobbledegook if you really want to, but hide it by default? As far as I remember, the guidance has always been "only print something if the user needs to know, no output means success." git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.
No news is good news.
Earlier quoted context omitted.
Yeah, like when Blow claimed he could replace PowerPoint in a weekend and ended up implementing a presentation software that had about 2% of what PowerPoint offers. Now there's an argument to be made that many don't need the remaining ones but to claim that you 'replaced PowerPoint' for anyone but yourself is ridiculous. They're good at demos, I give them that.
There's a classic saying along those lines, "everyone is only using 5% of Word. The tricky part is that everyone is using a different 5%"
Earlier quoted context omitted.
> It's probably just something no one has thought of doing. One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality. Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but wh…
Are those three really all the same things? That seems crazy to have all three not consolidated.
Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 10 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local obje…
This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.
Earlier quoted context omitted.
SVN was more straightforward to use, but that straightforwardness lost a lot in terms of fidelity. The fact that it was easy to clone a subdirectory was nice; the fact that branches were just subdirectories also was not nice. The fact that tags were mutable since they were also just subdirectories... the fact that every operation you ever did required going to the server (commit, log, checkout, everything) made it a…
git-svn did wonders when we had the code base on subversion
I ended up using KDE's SVN migration tool, which was extremely featureful and versatile, as it was designed for the case of moving a massive, complex SVN repository into multiple separate Git repositories, filtering files/directories, importing tags/branches/etc. Saved me a ton of time.
My favourite part was at the end when we migrated the biggest, most important repo, a lot of the original SVN commits were imported from CVS, meaning we had a direct CVS-to-SVN-to-Git migration keeping all of the original metadata from the CVS commits (such as it was). The data purist in me rejoiced.
Earlier quoted context omitted.
As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time. See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling…
From the linked article, it was a press release, not just to his employees. > The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.
Turns out it is not really new but only open sourced it now. From the FQA. >Lore, formerly called Unreal Revision Control, is the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators have been using it to version their islands. It is also seeing progressive adoption by internal Epic teams, and is being implemented as the backing store for UEFN’s cook pipeline, where it replaces tradit…
Earlier quoted context omitted.
As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time. See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling…
> and never partnering with ATI again. Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.
1. They kept existing designs, since even Jobs wasn't so crazy as to demand a complete re-architecture of existing laptop models on a whim; plus they probably also had contractual obligations/pre-purchase arrangements
2. They switched to nvidia, but from everything I know they also hated working with nvidia (IIRC Jobs accused nvidia of stealing Pixar tech)
3. AMD is a different company than ATI (technically), and Apple of that era was different than the Steve Jobs temper tantrum era.
But yes, relevant details.