__Mine__

Hey there! Probably about time I posted something, huh. This was long overdue, but I've finally got round to making this... and just in time for the Creeper's 12th birthday, too! How fitting. Here you will find links to all of the Cursed Creepers I have made so far. Click one of the buttons below to go to the respective thread! This list will be updated as more are created. Also introducing... All your favourite Cursed Creepers, now in the style of Mojang's promo art! Direct download links for each Pack below! Just like above, this list will also be updated as more Packs are created. PACK 1 PACK 2 PACK 3 PACK 4 PACK 5 PACK 6 PACK 7 If used, credit is appreciated! Enjoy!

That and the fact it's overused, annoying as hell and should've died 2 years ago but is somehow still going.

Haven't seen you here in a while. In my honest opinion, I feel like the massive amount of limb dislocation really doesn't fit in here. It's the only thing stopping this from looking like a perfectly-recreated in-game screenshot.

Try looking at the log_previous.txt file it mentions. That'll likely show you what's going on.

Herobrine Pig

I don't think this one really fits with the no-bends style, if I'm honest.

And it only took well over a year to finally see someone using them in a render ;u;

This is just three trucks. You can't call it drip if there's no drip, smh my head

Looks pretty good! Just a light nitpick; the thing Tdit's holding is a clapperboard, not a clipboard. Also, perhaps Lime Concrete could've been used as the greenscreen instead of Lime Wool? Less noisy.

Looking at the zoomed-in image the timeline appears to have roughly 6 keyframes every 3 frames, so that's about 2 keyframe sprites per frame on average. The zoomed-out image shows the keyframes stretching from 0 to a little over the 5,000-frame mark. Assuming the average of 2 keyframes per frame, that's roughly 10,000 keyframes. Not too surprising that the FPS is going to drop when it has to render 10,000 sprites on your screen. Far more than "a bunch", I'd say. Don't get me wrong, I'm not disagreeing in regards to this being a problem; it definitely is. I'm just not sure how it could be fixed. After all, the program needs to display something to let the user know there's a keyframe belonging to object X at frame Y that, when clicked, allows you to edit it. Displaying thousands of those will, inevitably, cause an FPS drop. The only decent solution I can really think of would be to perhaps "cluster" the keyframes if they get too close together while zoomed out? That would definitely reduce the amount of sprites being rendered on-screen... but I have no idea how that could be implemented properly without causing any odd behaviour (which keyframe would take priority for selection if you clicked on a cluster, for example). Other possible solutions could be to either limit how far the user can zoom out or limit how many keyframes are rendered on-screen at any one time, but of course they're somewhat less ideal, especially that last one.

That is what's known as Z-fighting, which is caused by two surfaces occupying the same space. Given that the texture of your model is a single flat colour, this Z-fighting is currently only visible on the outlines and therefore will not be visible when exporting the model to MI. However, if you plan on adding a texture to the model I'd strongly suggest making sure no parts overlap like this, as Z-fighting is generally undesirable.

It appears your PC is unable to handle rendering a video at 1080p resolution (1,920 x 1,080). Try rendering at 720p resolution (1,280 x 720) instead.

That's due to the program needing to display thousands of sprites to display all those keyframes. When you zoom in, less of them will be visible, obviously resulting in higher FPS. There needs to be some way to display the keyframes to the user, so I'm not sure how this could be fixed. Nimi has already told you that your ultra-high-end PC is ineffective in terms of performance because of the limitations of GameMaker. I'd recommend taking this particular complaint to YoYo Games instead, since AFAIK there's not much - if anything - that Nimi can do about this.

That is the most cursed Chest I've ever seen. Awesome!

If a post has more than 25 of a single Reaction (enough to make it so it's more than one page long), that reaction's tab in "See who reacted to this" ends up also displaying the other reactions, making it functionally identical to the "All" tab. To reproduce: Go to a topic which has multiple different Reactions and more than 25 of a single Reaction, like this one or this one. Click on the post's Upvoted icon to see who upvoted the topic. The "Upvote" tab in "See who reacted to this" will pop up. Click to navigate to the tab's next page. The tab will now display all of the Reactions, instead of only the Upvotes. Note: Occasionally, the tab may display all of the Reactions immediately without Step 3 needing to be performed. Also, this works for any Reaction that has more than 25 of it on a post, so the "Love" Reactions in the second linked topic above will also work for the purpose of reproducing this bug. Additionally, having multiple different reactions on the post isn't actually required for this bug to occur; it's just more visibly apparent if it does lol It's obviously not a serious forums-breaking issue, but it seems to me like unintended behaviour nonetheless.

That first render looks amazing! The DOF could use a little tweaking, but otherwise it almost looks just like an in-game screenshot. Nice!

Alternatively, you could've simply said nothing and moved on with your day instead of mass-downvoting people who were clearly joking and bumping a two-month-old topic.

Simply put, adding the ability to toggle the secondary view on/off by pressing a key, instead of having to click the icon. Saves a couple of seconds of time at best, but it'd certainly help improve the workflow for animators.

It's almost as if timezones exist. If you see something posted on the 31st of March, it's safe to assume it was posted on April Fool's Day in their country, especially if the context of the post looks obviously jokey. You're completely correct, quite a few people here are extremely toxic... however, this isn't the place to discuss this.

This is uncomfortably accurate.

By the look of it, Mine-imator seems to be unable to write to the location you installed it in. Prehaps you could try re-installing Mine-imator to a different location?

When clicking Undo after parenting multiple parts in certain ways, one or more of the selected parts will disappear from the parts list. To Reproduce: Create three parts, all unparented. For simplicity, I'll name them "Part A", "Part B" and "Part C". Select Part B and Part C, then parent them to Part A. Press Ctrl+Z or click the Undo button to undo the previous action. Part C will disappear. It's worth noting that trying to add another new part and naming it "Part C" will give you a "Parts cannot have the same name" warning. Additionally, if you try saving and reloading the model, thinking it'll make the vanished part come back... it'll actually be permanently deleted. And worse, if the part that disappeared happened to contain any shapes and/or additional parts, they will also be completely deleted along with the part itself when saving and reloading the model. This obviously presents a pretty big problem, especially in models containing a lot of parts with complex shapes; worst-case scenario, this bug could potentially wipe out hours of work without the creator even knowing until they reload their model.

If this means what I think it means (block dimensions of the schematic in {X,Z,Y}), you're trying to import a schematic that contains over 56 million blocks. This might've been too much for the program to handle all at once, hence the crash. I'd recommend splitting your schematic into smaller-sized pieces, then importing them all one at a time.