Prime World Editor v1.2.3

Edit history:

Aruki: 2016-06-04 05:45:28 am

Aruki: 2016-06-04 05:45:03 am

2016-06-04 05:44:13 am

Well my end goal is to have support for everything, so.. I wouldn't want that to stop anyone else from working on any tools though. Especially since it will probably take a while to reach that point.

Scans in particular I might do soon, possibly alongside strings. I'm kinda interested in visualizing the logbook model + animation for Echoes/Corruption scans since they have a bunch of associated attachments and it's kinda difficult to run animations with attachments currently (since the attachments are completely separate from the animsets).

For changing logbook categories keep in mind you'll have to mirror any category changes in the SAVW files if you want it to actually show up in the logbook. I think the one in the SCAN file itself is just for the "new [category] scan" text when you first scan the object. SAVW is pretty simple and I wrote up some complete documentation on it over the last week or two.

MetroidPrime_Stratton

2016-06-04 09:10:51 am

how long does it take for information on each file to found about what they refer too and does PWE support editing the savw files?

Aruki

2016-06-04 09:14:57 am

Quote from MetroidPrime_Stratton:

how long does it take for information on each file to found about what they refer too

uhhh what? I have no idea what you're trying to ask here :P

Quote:

and does PWE support editing the savw files?

not yet, the next build probably will

MetroidPrime_Stratton

2016-06-04 09:16:34 am

sorry havent been sleeping well. I want to know how long it can take for a file, in metroid prime per say, to understood properly. to know what the game uses them for...

Aruki

2016-06-04 09:28:49 am

there isn't really a set amount of time it takes, it varies wildly depending on the format. the STRG format for example is easy to understand because it's a relatively small format, a lot of the data is pretty obvious (the strings), and other parts are easy to understand either because they directly reference the string data and from there you can make inferences about what the data is, or because they have fourCCs in the file that basically give away what they're describing (languages). then a format like ANCS is very difficult to understand because it's a pretty huge and complex format that contains tons of different kinds of data. We couldn't even -read- the ANCS files for a long time, and as of recent we're only really starting to figure out what the different stuff in the file is because Antidote and Jack are doing a ton of reverse engineering of the executable using the demo symbols. Even now there's still a lot of gaps in our knowledge as far as how the data is actually used (AFAIK).

as far as just generally knowing what each format is, we know what everything is except for one format (CAAD in Prime 3). That info comes from a variety of sources including the file extensions, reverse engineering and experimenting with the data, the demo symbols, the Tropical Freeze symbols, the stupid amount of debug strings in the MP3 proto, debug strings in the other games.. etc. If you go on the wiki and go on the page for each game there's a list of every format used by that game and what it's for. A couple of the formats that don't have much known about them still are under the major research needed category but most of them don't even have pages (see the game pages).

Also to clarify about SAVW. PWE will not support editing the SAVW files ever per se. The plan is the editor will completely handle that format by autogenerating all the data needed to make sure everything saves/loads correctly based on what stuff you put in each world/area. As a user you will not even need to be aware that the format exists.

there isn't really a set amount of time it takes, it varies wildly depending on the format. the STRG format for example is easy to understand because it's a relatively small format, a lot of the data is pretty obvious (the strings), and other parts are easy to understand either because they directly reference the string data and from there you can make inferences about what the data is, or because they have fourCCs in the file that basically give away what they're describing (languages). then a format like ANCS is very difficult to understand because it's a pretty huge and complex format that contains tons of different kinds of data. We couldn't even -read- the ANCS files for a long time, and as of recent we're only really starting to figure out what the different stuff in the file is because Antidote and Jack are doing a ton of reverse engineering of the executable using the demo symbols. Even now there's still a lot of gaps in our knowledge as far as how the data is actually used (AFAIK).

as far as just generally knowing what each format is, we know what everything is except for one format (CAAD in Prime 3). That info comes from a variety of sources including the file extensions, reverse engineering and experimenting with the data, the demo symbols, the Tropical Freeze symbols, the stupid amount of debug strings in the MP3 proto, debug strings in the other games.. etc. If you go on the [url=http://www.metroid2002.com/retromodding/wiki/Retro_Modding_Wiki]wiki[/url] and go on the page for each game there's a list of every format used by that game and what it's for. A couple of the formats that don't have much known about them still are under [url=http://www.metroid2002.com/retromodding/wiki/Category:Major_research_needed]the major research needed category[/url] but most of them don't even have pages (see the game pages).

Also to clarify about SAVW. PWE will not support editing the SAVW files ever per se. The plan is the editor will completely handle that format by autogenerating all the data needed to make sure everything saves/loads correctly based on what stuff you put in each world/area. As a user you will not even need to be aware that the format exists.

MetroidPrime_Stratton

2016-06-04 09:30:29 am

oh ok, so simple stuff basically. and dont worry about SAVW

Odylg

2016-06-16 07:38:58 am

I run this here hotel of an evening

Is there any way to preview TXTR files?

Aruki

2016-06-16 09:54:39 am

There's a texture preview popup that will show up if you mouseover any property that takes a TXTR file in the world editor, or in the texture slot selectors for the model editor. The model editor also has a button that will convert the texture to DDS. Aside from that, no.

Odylg

2016-06-16 05:32:14 pm

I run this here hotel of an evening

i see the property mouseover, but when i go to change the file the open dialog doesn't show the preview so it's difficult to decide which to pick.

Being able to convert to dds will definitely help, though it'll be rather tedious considering how many TXTR files there are.
Too bad I can't convert more than one file at a time

Aruki

2016-06-16 05:47:46 pm

The changes I'm working on implementing atm will make it easier to tell assets apart and add them to maps.

flarespire

2016-06-23 05:59:40 pm

Hmmm, now that we know how TXTR's store image data and how they work, would it not be possible to write a thumbnail extension for something like Sagethumbs or the base windows explorer shell? Just some food for thought.

Aruki

2016-06-23 06:46:28 pm

We've known how TXTRs work for probably at least a decade at this point :P But yeah sure, it's possible if someone wants to write it.

flarespire

Edit history:

flarespire: 2016-06-23 08:42:59 pm

2016-06-23 08:41:21 pm

been doing some research on this (got myself curious on how it works) and oddly resources seem to be a bit scarce (I did only skim read things), I found something on the Microsoft website about it, but there wasn't much: https://msdn.microsoft.com/en-us/library/cc144067(VS.85).aspx see Thumbnail Image handler, that seemed to be a good place to start.

Aruki

Edit history:

Aruki: 2016-07-01 04:17:43 pm

Aruki: 2016-07-01 04:15:24 pm

2016-07-01 04:15:09 pm

sorry for the relative lack of updates, the next set of changes I'm working on are pretty complicated and have required me to basically completely overhaul a few backend components of the editor, and it can be tough to find enough time to work on it. I've just finished overhauling how resources are catalogued and loaded. There is still a lot more work to do on this unfortunately. I'm thinking the next release will have support for the exporting/cooking stuff, which will make it much easier to find assets and to move them between paks. I'm also considering building in a STRG/SCAN editor since they're simple formats and would be a good way to test out custom assets in PWE. No telling when that release could be, it may be a while still.

I'm looking forward to having this bit finished. It's complex and not particularly interesting to me but it'll open a lot of doors when it's done so I should be able to start adding a -lot- of new functionality.

Baby Sheegoth

2016-07-02 11:38:04 am

Dude, don't apologise. This is one of the best fleshed out tool for any 3D game that I am aware of already. Take your time.

Odylg

2016-07-04 04:33:10 pm

I run this here hotel of an evening

If I were to rename something in PWE and later d/l an updated version would it change the name back to the default or would it keep the custom one?
For example if I were to rename "Dock" to something like "Dock to Main Plaza" in PWE 1.1.0 and then 1.1.1 is released, would the custom name remain in 1.1.1?

Antidote

Edit history:

Antidote: 2016-07-04 06:03:30 pm

2016-07-04 06:01:48 pm

PWE gets the name from the object itself, the name will be persistent. PWE doesn't keep anything separate from the map.
In fact, PWE is pretty much a 1:1 representation of the data, the only thing I know of that it changes is the damageable trigger face flags, but the engine does that as well. In fact I reverse engineered that for Parax who then optimized it and put it in PWE.

Odylg

2016-07-04 07:48:49 pm

I run this here hotel of an evening

Ah, cool. Just wanted to make sure not to waste a bunch of time

Aruki

2016-07-04 07:59:18 pm

Quote from Antidote:

the only thing I know of that it changes is the damageable trigger face flags, but the engine does that as well. In fact I reverse engineered that for Parax who then optimized it and put it in PWE.

PWE doesn't change the face flags, it just interprets the data to ensure the correct face is rendered. The data on the object property itself is untouched.

Antidote

Edit history:

Antidote: 2016-07-04 08:52:01 pm

Antidote: 2016-07-04 08:50:47 pm

2016-07-04 08:50:00 pm

Ah ok, that makes sense.

URDE is going to cook the correct face flags by default when targetting the PC, but allow the engine to make it's changes for the GC retarget so it'll be compatible.
Also, those are flags, not an enum, so it'd be better to interpret it so the correct *faces* are rendered, I've confirmed that you can have more than one face rendered, in fact I think Miles used that to visualize the load triggers.

Aruki

2016-07-04 09:30:16 pm

Miles visualized them by placing actors using a model of a cube that I made. He didn't use the damageable trigger rendering functionality.

Antidote

2016-07-04 09:39:21 pm

Ah ok.

Antidote

2016-07-04 10:21:17 pm

Hmm, I went to get a screenshot of it, but apparently I was either messing with something else and confused the two, or I'm doing something wrong, but it's not working this time.

Aruki

2016-07-04 10:59:20 pm

Yeah I recall trying enabling multiple faces at the same time back when I first noticed that each value was one bit, and it didn't work, which is why I set it up as an enum. It's not really a priority to me right now but I'll take another look at it and verify one way or the other eventually.

Aruki

2016-07-10 08:21:56 am

here's a quick sneak peek at what I'm working on right now, PWE's asset browser: