Prime World Editor v1.2.3

Edit history:

zeldazelda: 2016-12-07 09:24:50 pm

zeldazelda: 2016-12-07 09:24:13 pm

2016-12-07 09:20:01 pm

Another question. Am I the only one that has to repack the files into a iso to play metroid prime 2 echoes (haven't tried metroid prime 3 corruption yet) because if I try to load it from the .dol file, the game doesn't load? (though it does load with the first metroid prime)

Also a couple areas just freeze the game/give me a "disk could not be read" error. This happens regardless of whether or not I edited the area at all, though this may be a repacking issue (not sure).

Also why do a couple areas in the prime world editor crash the program? (EX: Dark Oasis in Agon Wastes)

Aruki

Edit history:

Aruki: 2016-12-08 12:24:18 am

Aruki: 2016-12-08 12:05:57 am

2016-12-08 12:05:42 am

Echoes should be able to run in Dolphin from a folder, it's hard for me to say why it's not working cuz it would be something specific to your setup. The crashes you're talking about I believe happen in rooms with Ingstorm (BacteriaSwarm) objects due to an error in the template file. Don't remember exactly what it was but it's been fixed on the dev build for a while. I'm not aware of any other rooms that crash. I think there was another one that crashes due to not reading a texture correctly which is also fixed in the dev build.

zeldazelda

2016-12-08 01:38:33 am

Will the new update be able to import custom music?

Aruki

2016-12-08 02:45:24 am

no

Baby Sheegoth

2016-12-10 02:28:53 am

You can already do this anyway though

zeldazelda

2016-12-10 05:43:56 pm

You can? How?

zeldazelda

Edit history:

zeldazelda: 2016-12-10 08:39:30 pm

zeldazelda: 2016-12-10 06:05:46 pm

zeldazelda: 2016-12-10 06:05:11 pm

zeldazelda: 2016-12-10 06:04:22 pm

2016-12-10 06:02:31 pm

also, I fixed dolphin not running the game from boot.dol (forgot about changing the path of apploader -_-) but now that I'm using boot.dol to run my edited metroid prime 3 corruption, its running at 50 fps and it is squished a bit from the top and bottom, how can I fix this?

JosJuice

Edit history:

JosJuice: 2016-12-11 03:15:44 am

2016-12-11 03:15:28 am

Dolphin dev

I'm not completely sure why you would be getting 50 fps and a squished image, but my guess is that the game or Dolphin is detecting something region-related that's incorrect. Notably, when you're playing using extracted files, Dolphin will set the game ID to the (hardcoded :() game ID AGBJ01, which is a Japanese one. Which region is your game originally?

zeldazelda

Edit history:

zeldazelda: 2016-12-11 02:13:48 pm

2016-12-11 02:13:21 pm

Originally its "RM3E01" NTSC-US

Aruki

Edit history:

Aruki: 2017-01-14 01:21:51 pm

2017-01-14 01:21:09 pm

The "big" update with game extracting and etc is still not finished but here's an intermediate update I worked on for a couple weeks because I needed a break.

v1.1.1:
- Overhauled collision view

Basically, the collision view is now WAY prettier and easier on the eyes. It's now color coded based on surface type (ie primarily which footstep sounds will play when you walk on it). Additionally, the editor highlights collision triangles that can be stood on, which makes it easier to find new tricks. Note that the "standable collision" highlighting only highlights standable triangles (not edges/vertices) and it's not 100% accurate in Prime 3 maps. There is a new option under the View menu, "Collision Render Settings", which will allow you to configure how the collision geometry is displayed. Finally, the aether box is now displayed as a red wire box.

Download link same as the first post.

The "big" update with game extracting and etc is still not finished but here's an intermediate update I worked on for a couple weeks because I needed a break.

v1.1.1:
- Overhauled collision view

[img]http://i.imgur.com/A8aP7uQ.png[/img]

Basically, the collision view is now WAY prettier and easier on the eyes. It's now color coded based on surface type (ie primarily which footstep sounds will play when you walk on it). Additionally, the editor highlights collision triangles that can be stood on, which makes it easier to find new tricks. Note that the "standable collision" highlighting only highlights standable triangles (not edges/vertices) and it's not 100% accurate in Prime 3 maps. There is a new option under the View menu, "Collision Render Settings", which will allow you to configure how the collision geometry is displayed. Finally, the aether box is now displayed as a red wire box.

[b][url=https://www.dropbox.com/s/utgqphsy1qs85sz/PrimeWorldEditor.rar?dl=0]Download link[/url][/b] same as the first post.

Odylg

2017-01-14 05:23:26 pm

I run this here hotel of an evening

I know what I'll be doing for at least the next few hours :D

Odb718

2017-01-15 01:25:00 am

Shame on you!

Just registered to say I'm completely blown away by this project.
The image you just posted reminds me of my Halo 1 editing days

Aruki

2017-02-02 03:53:23 pm

Quick little video showcasing some recent progress: https://twitter.com/__Aruki/status/827167838901137410

Aruki

Edit history:

Aruki: 2018-03-06 06:51:22 pm

Aruki: 2017-04-20 01:07:22 pm

2017-02-21 01:17:37 pm

Hi! Just a quick update - I'm still working pretty hard on the exporting update and it's finally coming along really well. A lot of the final UI is in place and it's like 10x easier to use than the current public build. It's now totally possible to place any asset you want in any room you want and it just works ingame, fast load times and no hitching. There is more important functionality missing that I'm trying to get out before I can finalize a public release, but right now I estimate I might be able to have it ready within a month or so. I'm really looking forward to this being finished lol, it's taking forever and it's going to enable so much cool stuff that I've been wanting to implement for ages.

Jack879

2017-04-15 10:08:26 pm

It's probably a VERY late addition, but will we ever see a guide (maybe not written by you specifically Aruki) on how to use PWE? Or a readme explaining simple things.

Keep up the good work :)

Aruki

Edit history:

Aruki: 2017-04-15 11:35:36 pm

2017-04-15 11:35:23 pm

I'd be glad to write up a tutorial at some point, but right now there's still so much missing functionality and so many big changes being made that I don't feel it would be super useful at this stage, and it would get outdated too quickly.

Jack879

2017-04-15 11:54:38 pm

Alright cool. I understand it makes more sense and takes less effort to create it once most everything has been completed.

zeldazelda

2017-04-20 02:18:17 am

not to be super pushy or anything, but how's the work going?

Aruki

2017-04-20 01:00:51 pm

slow for the last couple months - Zelda sucked up a lot of my free time in March and then I had a con this month that kinda threw my schedule off a bit, lol. The update is probably like 90% done at this point and I'm really hoping I can get it to 100% soon, but I need to balance it with work and it's been difficult to find time for it.

Aruki

2017-05-10 03:42:58 am

quick MP2/3 repack tests

zeldazelda

Edit history:

zeldazelda: 2017-05-15 02:37:57 pm

2017-05-15 02:37:38 pm

Nice work! i'm really excited to use the new editor!

Aruki

Edit history:

Aruki: 2017-05-15 04:02:02 pm

2017-05-15 04:01:17 pm

disclaimer: the editor is -capable- of doing stuff like this but its a huge pain in the ass. The scripting tools are awful to work with. They will need major improvements.

DJGrenola

2017-05-15 10:37:57 pm

pretty neat nonetheless.

Aruki

Edit history:

Aruki: 2017-05-16 09:47:58 pm

Aruki: 2017-05-16 09:30:50 pm

Aruki: 2017-05-16 09:30:22 pm

2017-05-16 09:23:59 pm

I'll prolly bump this post up again when I actually release, but I'd be really curious to know if anyone has any ideas on improving the scripting interface. It is really awful to use. I kinda have an idea of how Retro's interface worked, but the way I understand it is they made heavy use of editor-only data that we don't have access to, which means implementing these features in a way that actually works decently well with the base game is a really difficult proposition.

---

The biggest problems are:

* there are just too many instances in the scene at once. It's difficult to understand what's going on. There are also lots of instances that overlap each other (for example, the buttons on the frigate targets have 3 button actors that overlap each other) so it's difficult to select the one you want.

* there are a lot of more complex structures made up of multiple instances. This is part of what makes the engine so flexible but it also means it's really difficult to actually change things in the existing game data. For example if you want to change a missile expansion into an energy tank you have to change the model/animset, the item type/amount, the property that makes it refill your energy, and you need to change the STRG asset referenced by the HUD Memo so it uses the "energy tank acquired" string.

* the connections editor is kind of a pain to use. It doesn't give you a good overall view of what the script is doing which makes it difficult to understand what's going on in the scene, and it's tedious to configure new connections.

---

possible stuff that could be added:

* we know Retro's editor had a prefab system, where basically you would configure a prefab of one or more script objects and their connections, and then you would plop it down in the scene wherever you want and it could be manipulated/edited as one object. I already know this system is a must-have for PWE because it vastly simplifies the process of adding new objects to a scene, i.e. you could just add a Power Trooper instantly and not have to manually configure its assets/vulnerabilities/etc. It'd also simplify the process of making large scale changes because you could just modify the prefab and then changes could be propogated to all instances of that prefab in every level. This would also simplify the process of i.e. changing a missile expansion into an energy tank like I was saying, since you could just swap out the entire prefab for a different one. Additionally, we could potentially hide instances that are used internally by the prefab and this might help de-clutter the viewport window. (I'm not entirely sure how much of an impact this would really have.)

The problem is for this to really be useful with the base game data, we'd need a comprehensive set of prefabs ready to go, and some means of automatically detecting them in the game data. There is no ingame data indicating what instances are part of what prefabs AFAIK so auto-detecting these would be difficult. I dont really have any idea how to go about doing this.

* Retro's editor also made heavier use of layering than the final game data does. You can see this in the leaked editor screenshot where there are a bunch of layers listed on the UI that simply aren't there in the game data. This would be immensely useful for organization, since you could potentially have tons of layers for doors, cinematics, puzzles, load triggers, etc. possibly organized into groups and broken down into sub-layers, and then possibly broken down further by prefab, and these would all get collapsed down into the in-game layers on cook. This has a similar problem with prefabs though, where there is no data indicating what objects were originally on what layers, and I don't really have any idea how to go about auto-generating all this data.

I've also considered that this data doesn't necessarily need to be auto-generated. The new PWE build has a system for storing editor-only data which is applied to the game data on export. I'm currently using it to set internal area names in MP1, but it could be easily expanded to include stuff like prefab instances or layers. However, I'm not sure that anyone wants to manually go through and configure all this stuff in every room, so some kind of automated solution (possibly with manual tweaking after) would probably work best.

BTW, Tropical Freeze actually has all of the original editor layers in the game data. Act 1-1 has 376 layers in it. These aren't equivalent to Prime-style layers; they're used for editor organization. In DKCTF, layers are further grouped into "load units", which is what the game actually loads/unloads; those are the equivalent to Prime's script layers. I imagine it's a similar configuration as what they used in Prime, except they excluded the editor layers from the cooked data in the Prime games. I don't know why they changed it in DKCTF without researching it further but I suspect they made it so layers could be added to multiple load units.

* the connection UI is kinda tough. I think it should be more clear what instances are being connected to, which could possibly be done by changing how the connections are displayed, or displaying additional info on the viewport when you highlight a connection (for example, highlighting the connecting instance). I also feel like it's really important to be able to get a bigger-picture idea of what's going on though, so I think there should be some kind of UI that displays connections for multiple instances at once. I could potentially have a node view (such as the editor for Unreal blueprints), but the problem is the view would end up having to encompass nearly every instance in the map in quite a lot of cases, and I don't know how to automatically lay this out in a way that's easy to understand and work with. So I'm not sure a node view is quite the way to go, but I can't think of too many other options.

I also need to improve the UI for actually creating a connection in the first place. Right now it takes a stupid number of clicks - click the link tool, click instance A, click instance B, click instance A combo box, click item for instance A state, click instance B combo box, click item for instance B state, click OK. Its also not really a common case that you're only creating -one- connection so I think it should be easier to create multiple instances at once. It's really just a question of how exactly to go about doing that though, what sort of interface would be easy to understand and work in? Also, it's a given that the state/message combo boxes should be restricted to states/messages that actually work with the script object types being connected, and that there should be a description explaining what the state/message actually does, because it's a PITA to try to remember this stuff.

---

If anyone has any other thoughts or ideas, it'd be much appreciated. I'd like to hear if anyone has any ideas how I could try implementing any of this stuff, or if anyone has any ideas for alternative features that would be easier to add. In the meantime I'll be trying to come up with more ideas, I guess.

I'll prolly bump this post up again when I actually release, but I'd be really curious to know if anyone has any ideas on improving the scripting interface. It is really awful to use. I kinda have an idea of how Retro's interface worked, but the way I understand it is they made heavy use of editor-only data that we don't have access to, which means implementing these features in a way that actually works decently well with the base game is a really difficult proposition.

---

The biggest problems are:

* there are just too many instances in the scene at once. It's difficult to understand what's going on. There are also lots of instances that overlap each other (for example, the buttons on the frigate targets have 3 button actors that overlap each other) so it's difficult to select the one you want.

* there are a lot of more complex structures made up of multiple instances. This is part of what makes the engine so flexible but it also means it's really difficult to actually change things in the existing game data. For example if you want to change a missile expansion into an energy tank you have to change the model/animset, the item type/amount, the property that makes it refill your energy, and you need to change the STRG asset referenced by the HUD Memo so it uses the "energy tank acquired" string.

* the connections editor is kind of a pain to use. It doesn't give you a good overall view of what the script is doing which makes it difficult to understand what's going on in the scene, and it's tedious to configure new connections.

---

possible stuff that could be added:

* we know Retro's editor had a prefab system, where basically you would configure a prefab of one or more script objects and their connections, and then you would plop it down in the scene wherever you want and it could be manipulated/edited as one object. I already know this system is a must-have for PWE because it vastly simplifies the process of adding new objects to a scene, i.e. you could just add a Power Trooper instantly and not have to manually configure its assets/vulnerabilities/etc. It'd also simplify the process of making large scale changes because you could just modify the prefab and then changes could be propogated to all instances of that prefab in every level. This would also simplify the process of i.e. changing a missile expansion into an energy tank like I was saying, since you could just swap out the entire prefab for a different one. Additionally, we could potentially hide instances that are used internally by the prefab and this might help de-clutter the viewport window. (I'm not entirely sure how much of an impact this would really have.)

The problem is for this to really be useful with the base game data, we'd need a comprehensive set of prefabs ready to go, and some means of automatically detecting them in the game data. There is no ingame data indicating what instances are part of what prefabs AFAIK so auto-detecting these would be difficult. I dont really have any idea how to go about doing this.

* Retro's editor also made heavier use of layering than the final game data does. You can see this in the [url=http://math.utoledo.edu/~dgajews/sw35/PrimeInDevelopment1.gif]leaked editor screenshot[/url] where there are a bunch of layers listed on the UI that simply aren't there in the game data. This would be immensely useful for organization, since you could potentially have tons of layers for doors, cinematics, puzzles, load triggers, etc. possibly organized into groups and broken down into sub-layers, and then possibly broken down further by prefab, and these would all get collapsed down into the in-game layers on cook. This has a similar problem with prefabs though, where there is no data indicating what objects were originally on what layers, and I don't really have any idea how to go about auto-generating all this data.

I've also considered that this data doesn't necessarily need to be auto-generated. The new PWE build has a system for storing editor-only data which is applied to the game data on export. I'm currently using it to set internal area names in MP1, but it could be easily expanded to include stuff like prefab instances or layers. However, I'm not sure that anyone wants to manually go through and configure all this stuff in every room, so some kind of automated solution (possibly with manual tweaking after) would probably work best.

BTW, Tropical Freeze actually has all of the original editor layers in the game data. Act 1-1 has [b]376[/b] layers in it. These aren't equivalent to Prime-style layers; they're used for editor organization. In DKCTF, layers are further grouped into "load units", which is what the game actually loads/unloads; those are the equivalent to Prime's script layers. I imagine it's a similar configuration as what they used in Prime, except they excluded the editor layers from the cooked data in the Prime games. I don't know why they changed it in DKCTF without researching it further but I suspect they made it so layers could be added to multiple load units.

* the connection UI is kinda tough. I think it should be more clear what instances are being connected to, which could possibly be done by changing how the connections are displayed, or displaying additional info on the viewport when you highlight a connection (for example, highlighting the connecting instance). I also feel like it's really important to be able to get a bigger-picture idea of what's going on though, so I think there should be some kind of UI that displays connections for multiple instances at once. I could potentially have a node view (such as the editor for Unreal blueprints), but the problem is the view would end up having to encompass nearly every instance in the map in quite a lot of cases, and I don't know how to automatically lay this out in a way that's easy to understand and work with. So I'm not sure a node view is quite the way to go, but I can't think of too many other options.

I also need to improve the UI for actually creating a connection in the first place. Right now it takes a stupid number of clicks - click the link tool, click instance A, click instance B, click instance A combo box, click item for instance A state, click instance B combo box, click item for instance B state, click OK. Its also not really a common case that you're only creating -one- connection so I think it should be easier to create multiple instances at once. It's really just a question of how exactly to go about doing that though, what sort of interface would be easy to understand and work in? Also, it's a given that the state/message combo boxes should be restricted to states/messages that actually work with the script object types being connected, and that there should be a description explaining what the state/message actually does, because it's a PITA to try to remember this stuff.

---

If anyone has any other thoughts or ideas, it'd be much appreciated. I'd like to hear if anyone has any ideas how I could try implementing any of this stuff, or if anyone has any ideas for alternative features that would be easier to add. In the meantime I'll be trying to come up with more ideas, I guess.

DJGrenola

2017-05-16 11:31:32 pm

disclaimer: I haven't actually tried PWE (more than anything else because I'm very rarely near a windows box these days). so this may all be useless.

regarding having lots of things overlapping / too much shit on the screen at once, the immediately obvious idea would be to make more use of keyboard controls for selecting and deselecting groups of things and making things visible/invisible rather than just mouse clicks. most CAD software is generally designed to be used with one hand on the mouse and the other on the keyboard. maybe being able to select multiple things by dragging a box over them, and grouping and ungrouping selections with a keystroke so they can be treated temporarily as a single object. vector drawing packages such as inkscape etc. work this way. but maybe I'm underestimating the problem. dunno. seems too obvious for you not to have already thought of it.

autosplitting stuff into layers is a toughie.