wareya

Supposedly, someone decrypted the ROM, and sent files to particular parties (via irc? cen included).

That said, I'm done here. You won't see me unless something spectacular happens.

Post edited by Shadow Fire.

That aside:

Watch the 3DS hacking scene. I'm pretty sure something is about to happen w/r/t encryption. At the VERY least, once they realize someone's got decrypted OoT 3DS files SOMEWHERE, they're going to kick into a frenzy.

ZEV was a mesh-only map file editor that rendered light coordinates as RGB vertex color values (like old UOT versions) and had keyboard based vertex edit control. It was written in FreeBASIC. It's basically an absolute downgrade to everything else.

EDIT:

That said, it was the third or so dedicated model editor, so it at least has historic relevance.

Anybody remember ZEV?

No?

Good.

Congrats on the fix, xdan.

It's smaller and I don't have to worry about widely tapered corners.

I'm glad they're remastering the game. FFX's original assets are awful. They didn't really figure out how to make textures for detailed 3D games until FF11/12. That said, I'm a little annoyed at the new shape of Tidus's face. The cheeks are too pompous, and he doesn't look enough like any of his concept art anymore. Oh well, here's hoping once it's emulated of released on PC there's mods for it, or they adjust it to trade off more between "looks japanese" and "looks like his concept art".

"seems legit"

It would make sense just to have the unique ones override the generic ones.

http://www.reddit.com/r/Games/comments/1gww9l/armikrog_developers_confirmed_as_official/

ctf+f bigot

The title instantly reminded me of this:

http://www.youtube.com/watch?v=Wx3by7ZaaZA

Since you obviously have zero respect for me I'm going to do a stupid POC of the random algorithm to show you that I'm not full of shit.

from random import shuffle# Let's say we have 1272 chests in the game (realistically, this is aggressive -- the real value is probably in the 100s)array = range(1272)def find():    # Let's shuffle our array of chest contents    shuffle(array)    # For arbitrary numbers, let's say that items #'d 142, 439, 23, 549, 283, 1, 532, and 489 all have to be in places under 100    # Realistically, this is pretty aggressive; the probability of any one sort being right in this case is roughly 0.08^8    #  Yes, that's extremely low, and yes, I am completely aware that this is how absurd bogus sorts are    # Replacing this simple "under y" function with a per value lookup is trivial.        under1h = [142, 439, 23, 549, 283, 1, 532, 489]        while(1):        condensed = array[:100]        good = True        for i in under1h:            if not i in condensed:                shuffle(array)                good = False                break        if(good):            returnprint "Let's start!"find()# Our chests are now in sorted order.

This is a cruddy python implementation, which is likely an order of magnitude or two slower than the C equivalent.

>No, it is you who does not understand the pitfalls with the solution you proposed.

I obviously do since I covered them in my second response. Yes, the speed slows down worse than exponentially as the dataset grows. I'm pretty sure that's what the big O thing I posted means.

>For one, the set of items that must be in a single location does not exist in the set of items are to be randomized, and thus should not be part of the equation.

Thank you for so rudely pointing out my obvious Freudian slip. I don't have the stress to figure out

>The other, is that it is impossible to know how many randomization attempts it will take without actually having an algorithm to check the validity of the solution of each randomized attempt.

Excuse me, but I'm pretty sure the fact that random sorts are capable of lasting forever is extremely CS 101 (the worst case performance is literally unbounded). Thankfully, PRNGs are total crap, and either will eventually give the right answer or never would in the first place -- though there's no telling how long that would take. If you don't have access to a cruddy, looping RNG, or you're afraid of unbounded performance in the paranoid case, you can simply drop in an iterative function in place of the random one. Not that it's any good either. It's pretty obvious that the re-randomization suggestion was pretty tacky in the first place, and there's no reason at all for you to be so insistent on proving it wrong when I've literally already admitted that it's terrible (O(n × m!) is worse than linear performance, and regardless of whether that specific notation is correct or not this algorithm will always have worse than linear performance) and given rational alternatives.

What I think is fucked up is, people are campaigning against the game because one of the creators is a homophobe. That's right, fucking up someone's art because of their personal beliefs. Fucking niche-ist scum.

>Otherwise, you risk running into a situation where randomization takes 2, 3, 1000, never attempts.

You really over-estimate how much time that would take.... If it takes more than a couple seconds to work then you've gone off the deep end in bad luck etc. Average case performance for something like this is O(n × m!) where n is the number of items to place and m is the number of items that have to be in one specific single location, IIRC. If you let them each/individually be any any of a set of locations, then that lowers. Each randomization should take a small fraction of a second with a set as small as MM's.

If you're really worried about it, you can build a list of valid sets in advance and pick a random one, or take a list of every item in the game permute vital items into acceptable locations in advance of randomly placing the others.

On the vital item topic, you could re-randomize until you have required items in places they're accessible. Also, are you going to do a true randomize or a shuffle? I think that a shuffle would be more appropriate, keeping the normal distribution of items. This is assuming you do a proper randomization per ROM or something. If you don't want to require people to cart multiple ROMs around, but still want a "deterministic" thing going on, you could do it in game ASM but seed it based on the second file's name.

that would be Metadata

Someone could make a patch that overwrites the HUD's properties with values stored in a certain place in ROM.

Heck, I figure I could do it.

Beaut

hey guys

remember cen's splitscreen oot hack?

i do and it still haunts me

6:11 PM 5/23/2013 SECOND RELEASE. MOVE HACK TO code FILE SO NO CRC RECALC ON CHANGED TABLES.

Radeon HD 5770, don't know the RAM.

They're not very respectable, but god damn, some of their songs are catchy in good ways.

I can very extremely easily notice if I drop even 10fps below 60 in any game with a lot of movement. It's not a placebo, either. You do need to be primed to perceive high frequency temporal details (like, by spending a lot of time looking at fast moving objects in high light in real life!) though.

The gameplay simulation is locked to the framerate. There is code built into the game for running at a different framerate, but it's REALLY buggy. So, in effect, if you make the framerate 60fps instead of 20fps, everything will run three times as fast. Hope that's okay!

The proper solutions are to make your own engine with proper full dynamic tickrate support or to wait for 3DS emulation and hack that version of OoT.