Kuribo64
Views: 19,850,316 Home | Forums | Uploader | Wiki | Object databases | IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
03-28-24 09:54 AM
Guest:

Main - Posts by blank

Pages: 1 2 3 4 5 6 7
blank
Posted on 12-02-12 04:32 PM, in Whitehole issues Link | #1308
Can't help you with any Anarchy edited files, but this is the extracted and repacked file that crashed Whitehole.

blank
Posted on 12-03-12 05:36 AM, in Whitehole issues Link | #1326
Posted by Mega-Mario
Edit2- the RARC packer is faulty. The root directory is named 'redblueexgalaxymap' instead of 'stage' as Whitehole expects.


Then it's sort of my fault. The extractor actually extracts to a directory named 'Stage', which I then renamed. But yeah, SMG doesn't seem to care about the root folder name.

blank
Posted on 12-06-12 07:48 AM, in .bva File Format Link | #1496
Posted by NWPlayer123
It's a lot like jpa files.


BVA files looks nothing like JPA files.

To elaborate a little on the VAF1 section:

Offset[/td]Size[/td]Description[/td][/tr]
0x00[/td]4[/td]Magic ("VAF1")[/td][/tr]
0x04[/td]4[/td]Section size[/td][/tr]
0x08[/td]1[/td]Unknown[/td][/tr]
0x09[/td]1[/td]Padding (0xFF)[/td][/tr]
0x0A[/td]2[/td]Unknown[/td][/tr]
0x0C[/td]2[/td]Number of entries in the first subsection[/td][/tr]
0x0E[/td]2[/td]Number of entries in the second subsection[/td][/tr]
0x10[/td]4[/td]Offset to first subsection[/td][/tr]
0x14[/td]4[/td]Offset to second subsection[/td][/tr]

The entries in the first subsection are 4 bytes structures (not completely sure about this):

Offset[/td]Size[/td]Description[/td][/tr]
0x00[/td]2[/td]Number of consecutive entries in the second subsection associated with this entry[/td][/tr]
0x02[/td]2[/td]First entry in the second subsection associated with this entry[/td][/tr]

The entries in the second subsection is simply bytes. They seem to only take on the values 0 and 1, so they might be boolean values.

blank
Posted on 12-08-12 04:21 PM, in Text question Link | #1583
SMG2 uses big endian UTF-16, but you don't need any hex editing, just use msbconv. I haven't really looked into text in SMG1, but iirc it uses BMG files, which these tools can handle.

blank
Posted on 12-08-12 04:44 PM, in Text question Link | #1585
No, but feel free to ask questions if there's something you don't understand. And, it's a hell of a lot more user friendly than hex editing.

blank
Posted on 12-08-12 05:19 PM, in Concerns v3 Link | #1586
Posted by Stygmax
We really should start kicking into high gear and finishing


I've been with this project for a year now, and statements similar to this has been made numerous times. Never once has it resulted in any increase in productivity. In fact, the only time this project moved in anything that even resembled 'high gear' was when Planet Plains were being made, the only level that has been made in the one year I've been here. One year - one level. Not really that impressive.

I must admit that I, for quite some time now, have had my serious doubts about this project. I mean, are anybody actually going to make some levels at some point?

blank
Posted on 12-13-12 05:57 PM, in Looking into SM64DS fixing collision Link | #1737
The main difference is that SM64DS kcl files are LZ77 compressed while MKDS kcl files aren't compressed.

blank
Posted on 12-13-12 06:28 PM, in Looking into SM64DS fixing collision (rev. 2 of 12-13-12 07:15 PM) Link | #1739
In that case the main differences is that the scale factors for the fixed point values are different. The header is also slightly different: SM64DS headers are 4 bytes shorter and the value of an unknown is different.

EDIT: This is the kcl from Tick Tock Clock exported to a wavefront obj and the converted back to a kcl (using an adapted version of the code I use for SMG). I need someone to test this in-game to see if it works.

blank
Posted on 12-14-12 06:40 AM, in Looking into SM64DS fixing collision Link | #1741
Ok, I might know the problem. Try this instead. But if that doen't work, there's some significant difference between SM64DS kcl files and all other types of kcl files I've seen.

blank
Posted on 12-14-12 11:24 AM, in Looking into SM64DS fixing collision Link | #1743
Last try and then I'm done.

blank
Posted on 12-15-12 08:16 AM, in Looking into SM64DS fixing collision Link | #1756
Is that model in the right scale? Compared to the TTC collision it's very small. If it is in the right scale it would mean that models and collision are scaled differently and we would have to find the correct scale.

blank
Posted on 12-17-12 03:43 PM, in Looking into SM64DS fixing collision Link | #1859
Then there's definitely a scale difference between model and collision, and it doesn't seem to be the same as for MKDS. Figuring out the correct scale factor would require a bit of trial and error, and as I don't actually have the game to test, that would be a bit bothersome.

Skelux, could you make a custom level using the original TTC model and the kcl I provided?

blank
Posted on 12-17-12 07:06 PM, in Looking into SM64DS fixing collision Link | #1867
Ok, that makes things a lot easier. Based on that collision are 1000 times larger than the models.

Skelux, this is a kcl of the obj you gave me, in (hopefully) the right scale.

blank
Posted on 12-19-12 11:26 AM, in Looking into SM64DS fixing collision Link | #1932
Sweet. After I've fixed a few things I'm going to release a python script. Then somebody can port it into SM64DSe if they want to.

blank
Posted on 12-24-12 10:32 PM, in Looking into SM64DS fixing collision Link | #2115
I haven't really had time to work any more on this. But it's not a lot that has to be fixed, so the script is getting released pretty much as soon as I get the time to finish it.

blank
Posted on 12-26-12 10:35 AM, in Looking into SM64DS fixing collision Link | #2138
Ok, here is the script. If you want to run it you'll need Python 3.

Usage:
> create_collision.py [-s SCALE] infile [outfile]

where infile is the name of the Wavefront OBJ file to convert and the optional argument outfile is the name of the resulting KCL file. The scale should be 1000 times the scale of the model.

blank
Posted on 12-28-12 03:02 PM, in Looking into SM64DS fixing collision Link | #2212
Posted by Skelux
blank, I'm getting an error. Is this the correct syntax?

create_collision.py -s 400 island.obj collision.kcl


That should be correct. What error are you getting?

blank
Posted on 01-06-13 11:45 PM, in Debug Mode Link | #4292
Posted by Luigi
It would be a big pain to program, but it could work. It would just take a little while.


You don't just add a debug mode.

Could people please stop going "it could be done, it would just be hard" whenever somebody sugests something that requires modifications of the actual game code, unless they at least have an idea of what they are talking about.

blank
Posted on 01-07-13 12:09 AM, in Debug Mode (rev. 2 of 01-07-13 12:13 AM) Link | #4299
Posted by Luigi
I knew what he was talking about...


But you had no idea what you where talking about, as you apparently think it's possible to just add a debug mode.

Posted by NWPlayer123
Posted by blank
Posted by Luigi
It would be a big pain to program, but it could work. It would just take a little while.


You don't just add a debug mode.

Could people please stop going "it could be done, it would just be hard" whenever somebody sugests something that requires modifications of the actual game code, unless they at least have an idea of what they are talking about.

I realize how hard it is to actually modify the game's code through what MN1 taught me. I know what I'm talking about when I say something is or isn't possible, or overly complicated.


If you think you can add a debug mode, I seriously doubt you know what you are talking about.

EDIT: MN1's suggestion is probably the closest you can get to a debug mode.

blank
Posted on 01-12-13 09:47 AM, in Unexpected issues Link | #5454
I don't know if this is what causes the freezes, but MemoryFile has got some serious issues. getContents returns the entire buffer which, due to autoExpand, might be longer than the file length.
Pages: 1 2 3 4 5 6 7

Main - Posts by blank

Page rendered in 0.026 seconds. (2048KB of memory used)
MySQL - queries: 21, rows: 141/141, time: 0.009 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2018-07-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.