Open ughman opened 10 years ago
More features I want for this version:
Until the 1.0.0 release, I'll add features here rather than creating new issues.
This looks like a huge (good) step forward. I am looking so forward to it. Though I have some more suggestions (should not be in first priority):
And that is about it. Ended up being way larger than I thought.
ughman edit: added issue id refs for each bullet point
Those all look good, except for the text string viewer, not sure what you mean there. If you mean editing text like NEW GAME and such, that would be part of the GOOL thing since those are in those entries. No idea what you mean by variables and switches though.
Ah so they are in the code entries? Cool that saves me off some work. :)
Also the switches are the things like MONO and STEREO and VIBRATION ON and VIBRATION OFF. The variables are like the number of crystals. They seem to be mostly %'s and something else, I will try to fiddle around with these when I can.
Some more features I want in:
Some more features but probably post-1.0.0:
How do those zone-music associations work anyway? Is the target music entry/SEQ specified inside the zone entries (maybe in one of the first two items) or is it somewhere else?
Yeah the entry ID is one of the values in the first item.
Also how about exporting entries too? (The format should be the same format as the entry) Currently the best you can do is unprocess entries and export their items and then replace them, wich takes a tedious amount of time.
Oh yeah that's a good one too
And something I forgot in my last post (GitHub mobile wont allow editing) was a Reverse Path option for objects, it simply swaps the first position with the last, second with the second-to-last, etc. This could be particularly useful for duplicating moving enemies or platforms.
How would the autoregenerating drawlists work with multiple-position objects though? Will it also count the other positions? That is like, the best feature this could give as it would cause freezings/crashes to disappear (or be much less common) and also fixing weird drawing bugs when modding!
ughman edit:
Yeah that's good, here's another:
As for drawlist regeneration, using all of the positions instead of just one shouldn't be much harder. The hard part is actually figuring out how the camera knows where it is and where it's facing as well as making an algorithm that can figure out if an object has any positions within that viewing area or not. This is going to involve some 3d math which I'm not good at, so that's a challenge that lies ahead.
I see. But another fear of mine is that it could mess up some of the drawing in Crash 3, take Tomb Time for example: near the end of the level where the purple gem path reconnects, if you slowly start backtracking the stuff will disappear while still perfectly visible. When regenerated the drawing should be fixed, but it could make the game crash due to too many stuff being on the screen at the time (no guarantee though, my modding capabilities on this game are limited due to the scaling issue and the different scenery).
Oh and 1 thing that bothers me when I test my modding is the depth of the objects. Is it specified anywhere? It could be extremely useful (but probably extremely complicated) to like, hide crates behind a platform or put nitros under the floor to troll the player in 3D sections (hey this seems like a good idea actually), because if you do this without editing depth, the crates will look like they are above the platform.
Here are some I came up with:
Also can you post a screenshot of the current GUI (or a mockup of it)? Just to see if there is something I can suggest (also helps me organizing my ideas a bit more).
ughman edit: added issue id refs for each bullet point
It looks pretty much the same, most of the change is rewriting a lot of code so the UI gets updated automatically when changes happen to the objects in the backend.
Oh cool. I like the color coding right there. Also I noticed a CrashEdit tab, does it have like general settings? Anyway it looks good.
Been thinking a bit, and I thought of some stuff that could be useful:
Edit: Is it possible to force a "textured scenery" view (shows the scenery exactly like if it was in the game)? That could come in handy in Bee levels because when you see the scenery it is all grey/white and indistinguishable (except for the warp in/out parts).
ughman edit: added issue id refs for each bullet point
I feel this could be used for some fast, easier, and quick edits:
Actually, I think condensing all of the issues into just this one has overcomplicated things for me, I'm going to split them all out into separate issues.
Even though that's the exact opposite of what I did at the start, heh.
Any updates?
Pretty much not really.
I'm legitimately considering starting up a new branch and rewriting from scratch in C. If I were to do this, I would specifically target features not already in CrashEdit so I'm not just wasting time redoing the same stuff over (crash 1 zones sound like a good start, instantly makes the program useful). There are upsides and downsides to this:
Point number 6 isn't actually as bad as it seems. A lot of stuff in CrashEdit already needs to be rewritten to be undo/redoable. Point 9 could be eased by integrating a scripting language of some kind, especially if undo/redo support was implicit and automatic.
Another point, though, is that I'm currently more interested in an approach like this than the current system. Every time I open the C# crashedit project I feel like closing it and doing something else. Since I'm pretty much the one main developer, that means nothing happens. That said, if someone else wants to take over the C# project, I'm perfectly willing to commit and push all of my private changes, which are a mismash of random broken features, as well as provide any information online whenever. Just don't be surprised to see there's no big undo/redo action system in there.
I could use that (I even have fully functional Crash 1 entity and camera editors programmed right in so that ain't a problem to me).
Ignore that C project comment, decided to stick with CrashEdit instead.
I've added references to the relevant issues to all of the bullet points here. I've put in "(?)" for the ones I couldn't find issues for. Will close this as duplicate once all of them are posted.
Not really sure where to post anything, so here it goes.
I've had a fair amount of work done on CrashEdit locally which hasn't been pushed (apparently the version on here is from december of last year? ancient).
I intend to release 1.0.0 at some point, I think this versioning scheme is much better than what I was doing before. I'll probably make a small post on xentax once it's out, but then I'll switch to hpzr.proboards.com to start a thread and announce any further work there. There are certain features I want in before I publish 1.0.0:
58 An undo/redo system. This is absolutely critical. I never made one because I didn't think I could pull it off but now I have some ideas and I'm going to roll with them.
11 A system that will show exactly how much free space is left in a chunk so you can see how much space you need to free. This is really important in solving packing errors.
14 The ability to delete entities.
18 Rename T11Entry to CodeEntry, and EntityEntry to ZoneEntry. I believe there was another renaming I wanted as well. This one is rather minor.
21 Moving OBJ and COLLADA export code into the 3d renderer (or at least all in one place). The model export code suffers from all the different model types having essentially duplicated export code.
22 Support for the other "animation entries" in crash 1 which have a mysteriously different type id. The format is actually identical, or so it seems, so this should be no problem.
24 Better support for crash 3. The object scale issue is already fixed locally, but the scenery code will need to be duplicated and changed to support crash 3's (very slightly) different scenery entry format.
Some other things I want but probably won't make it into this version:
10 Visualizing the collidable parts of a level. I actually already have this implemented locally (though uncommitted) but the performance is absolute garbage.
17 Automatic regeneration of "draw lists" and "load lists". The game utilizes "draw lists" to detemine which game objects should be present and running. Along each section of a given camera rail is a list of which objects to spawn and despawn when the camera hits the associated points on the rail. These lists need to be regenerated based on where objects are placed in the level. This would also enable box stacking to be implicit rather than careful and complex. Similarly, the "load lists" determine which entries need to be preloaded for upcoming areas. If the data isn't present at the time it's required, the game does a blocking read for the chunk data (waits until it's fully read). On a CD this is extremely slow (could be over a second long without PS2 FDS, unacceptable). __This change would also facilitate an "add entity" command which wouldn't require an object to already exist within the zone (entity entry), and could also allow moving entities between zones.
27 An actually functional "import entry" option. This is necessary for, for example, placing a mask box in Crash Dash or utilizing wireframe boxes in Spaced Out.
29 A GOOL disassembler and editor. This is a pretty big undertaking, but very powerful in the right hands. This is the kind of thing that will allow (sufficiently experienced) people to make their own box types, for example. This would also make it much easier to figure out more on how GOOL works. A debugger would also be nice.
30 Support for crash 1 zone entries. These have a completely different format from the ones in crash 2 and 3, which is why there's no support for them right now.
34 Support for importing music directly from standard MIDI files. Right now importing music involves programs to convert MIDI to SEQ before importing, all of which seem to be proprietary and DOS or Windows only.
32 A barebones MIDI editor built-in. The code to convert MIDI to SEQ will pretty much perfectly match the non-UI code needed for this anyways, and this would be pretty handy.
This doesn't mean 1.0.0 is coming soon, but it is something I intend to happen.