haddockd

I released it forever ago. As far as I know there arent any issues with it

Any way to donate to you outside of this site? I am sure alot of us are willing and able to help

I am shooting in the dark here but are you opening a modded ROM? What happens when you open a clean one?

Mine either so dont feel bad

I can easily donate once the ex wife is off the payroll (middle of august) so if you hang in there for a month and a half, i got your back I am already a donator so I hope that has clout

Ah. Would it be worth your time to compress it and test just to see? If it works after recompression then you may have an answer. Also have you tried other emus (Nemu, 1964, etc)?

I assume that means that if you recompress it after modding it that it doesnt crash...correct?

Would you mind posting it here so everyone can access it?

I thought you were porting a map and not an object and I was all over this like a ninja. I already had a response written when i verified. I have never used that tool. Sorry Doing some Google finagling...i cant find it either...weird. On a constructive note, have you tried explicitly giving the path to the objs? So something like this (would be ideal if paths had no spaces)? srcexe c:\modding\Zelda\object_link_boy.zobj 233E0 c:\modding\Zelda\object_ik.zobj 15840 On a less probable note, are you sure the offsets are correct? Also...does the game do nothing when you run it after running the app or does it crash? Just trying to get a feel for exactly what is going on?

I chose to make Ruinous Shards all by myself. I ABSOLUTELY had help but I was always in charge of the project. It took me a great deal of time and the project probably could have been greater if I added staff but I chose not to....and it worked out I think

That may be true but isn't necessarily true. I am referring to highly modularized code. Tight coupling doesnt mean that the module can't be reused, it just means the interaction between them is heavily utilized. For example a vehicle class can make boats, cars, trucks, planes, etc. Some will be more tightly coupled than others (like cars would have more characteristics that we think of for a vehicle) but it doesn't mean that it's a bad thing as it can be used (and reused) by a plethora of organizations and applications (domain allowing). Large systems with a small number of modules are absolutely a bad idea to have tightly coupled (this is a bad idea in general lol). But I see your point

OH! I misunderstood. My bad I do like your ideas but some of it seems to be opinion more than factual base. For instance, you mentioned: The only useful thing encapsulation brings to the table is data-hiding, but that's not an exclusive thing I am not entirely sure that is accurate. Encapsulation allows for a high level of abstraction in a public interface and of course it allows for strong coupling. Keep in mind I am speaking from a complex systems point of view because that is my background. Smaller systems may not have the same requirements so perhaps it is less important...?

I could argue several of those points but it isnt going to help. Sounds like your mind is made up I would recommend that you add a few sources because technically if you dont and you turn this in, it is plagiarism. I would hate for your effort to be seen as such