Sonic Heroes E3 Beta released for Gamecube

So there hasn’t been a topic made on the subject yet, so I thought I’d make one (especially when I’ve done a video based on it).



LINK


ashthedragon (and from the help of other members) from Sonic Retro managed to purchase a E3 (beta) version of Sonic Heroes for the Gamecube. It has been dumped and is now available to play. You can get the download links from here (in the description). There are two types of ISOs here. A trimmed version, meaning it’s a lot smaller to download so you can just play the E3 version as it is, or the full version, which isn’t any different when you come to play it, but you might discover a lot more if you decide to hack it.


It’s a pretty interesting find, and I enjoyed playing it.

Spoiler

Apparently, this is the exact same as the Xbox E3 version.

 

Brillhant one! Music was changed. Fortunately the Seaside Hill music from the final product isn't like in this demo. This version of the song sounds very blank most of the time and its arrangement is really worse. But the railroad level music sounds incredible!!

 

Since I don't see a place to give my greetings I'd do it here before my first actual post, of course a few of you have seen a more complete version of this.

Hello, I'm Sewer56lol, researcher, web-freelancer, Android ROM tweaker, Aspie among other things and I have came to assist you in the research of this and perhaps following future prototypes, I like Heroes as a game a bunch so every proto that comes around gives me a field day. Regardless of this, allow me to begin.

My knowledge of Heroes is immense and approach to researching it as you might know from my 10.8 prototype page, ruthless, allow me to make hell freeze over. This is a beginning of a slightly longer journey.

Note: This is one long technical post (of hacking guidance/discussion) for anyone interesting in hacking this prototype, I've written it in such a fashion that it should work as a 'rollup', like separate posts (gotta not waste trialist posts), open a spoiler and access what you desire. Or maybe all of it.

I've updated MainMemory's HeroesONE updated with support for RWSDK 3.3 & RWSDK 3.4 content headers.

Spoiler

This should be a shorter rundown, no need for the full-full explanation here I guess.

I've taken my time to take a look through the format of the .ONE archives because I've been slightly curious into what the major or minor difference was between the formats of .ONE between the E3 prototype and the later prototypes as well as the retail version(s) of the game. Originally finding that the data has been stored in the exact same way I was kind of surprised.

Either way, standard procedure, taken a sample of around 20 archives from multiple prototypes, taken HeroesONE, resaved some retail archives to also compare them, took a short look through the HeroesONE source code and not only gained a bit more experience but also learned a bit about the file format.

Unsurprisingly, as I was in fact able to dig into the archives with a modified HeroesONE version even earlier than that, there is no real redeeming difference between the .ONE archives that have any sort of possible impact. While I have seen some minor differences regarding the padding of some of the data in question compared to retail files, it did not appear to make any difference as the prototype, or any other prototypes for the matter did not seem to care at all. The main difference are those 'Magic Numbers' as often referred to in the source and previous looks (and utilities) at the format, it appears that this was all the game cared about to make a difference, everything else was irrelevant.

I've also tried to breakdown on why the same format has had multiple headings, originally I thought of the headings being dates of sorts but I quickly scrapped that seeing that Jan 2004 for a game retailing earlier would have maybe been a bit of a stretch. Either way, I did establish that this was some form of version control due to an observation I made that the game was happy to accept 'backwards compatibility' (or really older headers) on newer versions of the game, either way, checking out more and more archives (though not enough I believe to scientifically 100% prove it) from different versions the main observation thus far was that the header is different depending on the version of RenderWare SDK the contents of the archive were built with, so I decided to tag the archive versions by RenderWare versions.

Anyway some new statements here and there to prevent redundancy, new set of magic numbers from two archive versions I have found in the E3 prototype and testing with around 20 or so archives before passing it off as working, HeroesONE has been updated to support the .ONE archives from the E3 Beta, you can dig this prototype all you want now (although I've already done it a while ago), enjoy.

Magic Numbers
Heroes = 0x1400FFFF;
Heroes E3 = 0x1005FFFF;
Heroes Pre-E3 = 0x1003FFFF;
Heroes Pre-Pre-E3 = Unknown;
(These are in Little Endian, you can find them at 0x4 - 0x8 in the file headers as well as before the individual file data)

Magic Numbers by SDK
Heroes = RW SDK 3.5.0.0
Heroes E3 = RW SDK 3.4.0.5
Heroes Pre-E3 = RW SDK 3.3.0.0 (found only in stg00/test level .one files)
Heroes Pre-Pre-E3 = RW SDK 3.2.0.0*

*Note: play_ground.txd is a left over texture file with this RW version, presumably an old testing stage, as suggested by two level slots before Seaside Hill in this prototype rather than one.

Changelog
- Add support for opening, recognition and saving of .ONE archives with the E3 & Pre-E3 headers.
- Add an option to save in the Heroes E3 & Pre-E3 format into the HeroesONEEdit GUI.
- Add an option to save in the Heroes E3 & Pre-E3 format into the HeroesONE CLI.
- Some minor code method wrapping to prevent redundant code between the 3 Heroes .ONE types.

Download: (When I go on my Windows machine and compile)
Source Code (already merged): https://github.com/sonicretro/HeroesONE

About those inaccessible levels and pesky .rel files.

Spoiler

I would like to say as someone who has tampered with Heroes for a longer period of time and messed around with a lof of various things to do with the game that this is completely and entirely correct and in fact is the only and sole reason these levels are not loading, nothing else. The real issue is not in fact missing files of any kind, in fact the soft-coded nature of loading levels in Heroes makes the game indiscriminate on whether certain files are present. Remove object layouts, camera, lighting, particle data, visibility data, textures, even stage geometry or collision files - the game wouldn't really care (well, unless you corrupt some of these things, then it may).

Good knowledge there from the guy, I really like his work. Inside the Xbox version of the game every stage's individual data is indeed compiled right into the .xex executable, in the same fashion, this data is compiled into the main executable of the PC version of the game. This means that the .xex should have the data up to date with the rest of the stages, it should boot the stages however this could not guarantee that the levels would be bootable directly as there may be still other issues in the way (expained a bit later). I'd recommend for someone with a devkit or debuggable Xbox to load those other stages from the Xbox E3 Prototype, unfortunately much of the other stage files are missing in that prototype, and in fact that prototype is a different build (in my opinion backed up by presentable evidence if necessary, presumably later rather than earlier build). Although about those other stages it should not be that much of a problem, for textures - import with MAGIC.TXD and re-save in the XBOX format, for geometry you'd have to convert all of GC BSP into another workable format like OBJ and convert back into the more 'PC format' BSP which should also work on the XBOX version. About the rest, you'd not need to worry. the other binary files as well as the .dff clumps for level specific objects which power the levels are all in the same exact format across platforms, that should just be a copy and paste job.

Back ontopic, the real issue with those .rel files, or GameCube Relocatable Memory modules actually lies in the fact that during the development of Heroes, the format of them constantly kept changing, when inspecting code execution in Dolphin you'd find that you'd often leave yourself in endlessly ongoing loops made by a branch execution which sets you back until the same branch is endlessly hit if the .rel module is a mismatch - want to nop them? Good luck crashing the game or even the emulator. This goes even beyond the 10.8 and 11.18 prototypes up to the very release, the latter prototype being pretty close to the release date of the game, the format does constantly change for these files. I fully believe that those leftovers are fully working .rel files, maybe some experimentation and comparison of 11.18 -> Retail and different retail files could help, I reckon that it could be possible to bring it back, it is probably more of a 'trick' to figure it out since they are probably not that dated, unfortunately finding that 'trick' could take couple tens of hours or a huge stroke of luck.

As for those .rel files, what makes them so special? What can I find?

Spoiler

Well, figured I'd post this, it could help someone in the future - this is a breakdown of what you should be able to find and control within these files. I don't really have any offsets for this for this build, and they would vary between different .rel files anyway.

Here's are the things I know (for certain), off the top of my head that are stored inside these files:

• Data on handling and operating regular common objects in-game as well as their properties, literally the power to control what possibly makes a spring a spring, want to change the model of a spring for one (two) stages only? Sure, do it here, no problem. (Think of it, change the spring model to load let's say a custom trampoline model you imported into the game's common objects .ONE archive... BRILLIANT!).
  
• Spline and path data, not limited to loops: Rails, paths taken by the 'Flyer' bird like enemies, where and how the enemies walk... etc. You can see the idea here.
• Boss programming. This one should be self explanatory, here you go, port some geometry, textures and collision over and enjoy your fights anywhere (Metal Madness is pretty fun to fight inside the test level).
• Level 'Gradients', quite simply the colour or the colour fade that you see when you remove the skybox from any level.
• Stage environment programming and variables, this for example includes the programming for the lightning you see in Final Fortress (I think I still have an offset for the rate saved somewhere). These should be obvious to recognise e.g. flying in the background blimps which cannot be controlled by object layout files.
• Programming for stage specific placeable objects, such as flying cars in Grand Metropolis, rising pillars in Seaside Hill, etc. Now, if the model name of an object is not referenced in any of the .rel files, then it is very likely that it is very, very, very unplaceable.
• Text shown on screen when playing back in game 'events' (scripted cutscenes/movies with subtitles), albeit not in this prototype.
• Information regarding the playback and selection of the ADX music files, including looping periods etc.
• Screen filters! Hey! Want to make everything super spooky and dark like Mr Skeltal? You can do it somewhere... here. I work with all protos and am guilty of not saving offsets :/.
• Player start positions (In the case of later versions, per-team player starting positions) in this prototype this appears to be a singular, all teams start in the same place as defined by one location.
• Mission counts (not in this prototype AFAIK), amount of crabs to be collected by Team Chaotix, rings to collect to finish etc.
• Ranking requirements, as well as stage finishing co-ordinates where the characters show their poses when touching the goal ring.
• An address/property (somewhere) deciding whether a demo should be started when launching the level, you could technically if you could find it always make the level boot into a demo.
• Player starting spline attachment, not sure how to describe this one, let's just give an example instead - go ahead and modify the starting position in Seaside Hill and observe what happens, you are instantly in mere frames warped onto the automated running section at the beginning of the stage. Auto running sections are also along with splines and paths.
• Singular death plane height for the 'bottom' of the stage (and likely a toggle/option for one, test level's .rel module doesn't seem to have one).
  
• Player velocity expressed as XSPD, YSPD and ZSPD, you can literally have a running start.
• 2P Starting positions, if for a 2P stage.
• Short descriptions for additional properties of common objects [VERY HELPFUL FOR HACKING].

These are just off the top of my head .

So about those levels, yes, they can be just ported onto other stages with working .rel files but then the beauty is lost, incorrect spawn points, no splines, background environment is different or may not exist, issue regarding death pit heights - a part of the authencity and polish (or technically lack of in this E3 prototype) is lost. I've ported (to the 10.8 prototype actually because I like that more than the retail version) and played in all of the levels which don't load already, had a dig, looked at the differences here and there etc. Grand Metropolis is certainly very interesting to say the least...

So hold up! Where are the origins of the crashing regarding levels?

Spoiler

Instead of trying to explain it in long text, here's probably a better idea, a checklist. Let's start with level specific files, I'll use Seaside Hill's file names for easier reference rather than wildcarded names, for other stages it's just swapping numbers around or changing sXX to stgXX.

• s01.dmo - Demo playback data when not touching anything on the title screen, game doesn't care a slight if removed or told to play a demo without it, would just skip demo.
• s01.one - Stage geometry in here as well as some alpha mapping etc. Game doesn't care the slightest, make it a completely empty file even.
  
• s01_blk.bin - Visibility data? Nope, game doesn't care either, only problem is that it will only show the first level chunk out of the 12-22 chunks the levels normally have because there's nothing telling them to load the next chunk between a set of co-ordinates.
• s01_cam.bin - Stage camera? Yaaaawn.... Game does not care. Next!
• s01_DB.bin - Stage layout for decorative objects which don't interact with the player... Hey it's literally an object layout file except the objects here don't care about the player. Next!
• s01_indinfo.dat - Information for Indirects, nope, game doesn't care about that either.
• s01_light.bin - Lighting? Poor game... it doesn't care if it is present or not either. Note: You can toggle lighting using a placeable object, so I do suppose you can probably crash a game that way potentially if you tried too hard.
• s01_PB.bin - Stage Object Layouts. Nothing here either, you will crash the game if you have an object or object property in here which doesn't exist, although I've already checked and that's a non-issue here. Game doesn't care once again if this exists or not.
  
• s01_ptcl.bin - Stage particle data! For all those cool glowing particle emitting stuff! I recommend keeping this here if you have placed any particle emitting objects in s01_PB.bin, else completely useless.
• /textures/s01.txd - Getting into textures? If a texture is missing, object/geometry is blank, nothing more is necessary to say.
• /collisions/s01.cl, /collisions/s01_wt.cl, /collisions/s01_xx.cl, Collision? Nope. Not collision, you can fall indefinitively all you want if you are interested.

So wait? Anything that can really crash the game regarding stage files?

• s01obj.one - If a dynamically controlled/environmental object like the background blimp of Grand Metropolis is missing the game will crash as soon as the stage is loaded, however in this scenario it is not the issue, as the crashing is occuring much earlier in the stage loading process.

Okay! What about the contents and the actual .rel files?

Spoiler

Checklist time! Enough said. This time around instead of saying no to things I'll just skip them entirely, here's all potential crash potential purposes I can think of.

• Format of the .rel module file that as said seems to keep on changing - probably the main and actual culprit.

• Data on handling and operating regular common objects - Technically possible if for example a model file for a specific object no longer exists BUT very unlikely. I've actually not investigated this personally, it'd take a while to scan in fact, though through looking at it earlier, this does not appear to likely be the problem.
• Stage environment programming and variables. No long explanation here. Want to run a blimp? But what if a core mechanic or simply offsets of handling such stuff changed, problems ensue.
• Programming for stage specific placeable objects. Maybe this, unlikely.
• Player Start Positions, Victory Pose Positions, Mission Counts. Would probably just default to 0 if unset anyway.

So how do I bring over a stage on top of another one?

Spoiler

You said you ported these right? Well, I did, but it's not a 100% true representation for the stage, as the cool stuff defined by the .rel files are indefinitively lost, technically not a huge difference but getting to know that forward flying cars were meant to fly backwards can be heartbreaking. Also, loops & rails, good luck with them. Regardless, i'll probably write about this anyway in a future post, but it is extremely simple, especially with every aspect of a stage explained right above already, you could probably figure it out by now.

________________________________________________
Remember, there's some cool stuff in here, port it over

This is presented inside the 10.8 Prototype.
(I've actually already uploaded a video of this).

 

That's actually a pretty nifty resume you've got there. I never knew much work went into Heroes, especially not the research you've put in.

Although if you're looking for a place to introduce yourself, this thread might serve you nicely.

 

I apologize for (essentially) this double post, but having one humongous post would be just a bit too much. I had this post written in advance so I am not that crazy to have written it in an hour.

A bit of an introduction and I suppose a small bit of relevant hacking guidance, if you like this sort of stuff into posts then please leave some feedback on how you'd like research posts to be presented, it'd be greatly appreciated. This is only a small part of my look into this prototype.

This specific post will be focusing on the 'Common' objects, that is objects which are not exclusive to any level or stage and are intended (and I really mean intended) to be always loaded/available and ready to be placed on any stage within the game without the need (technically but not always true) for editing of the setidtbl.bin. Over time within the future I'll write (and wiki after everything's done), on the other discoveries and results of my research of this prototype, because there are a good bunch of things I've dug out that are still out there to be shared.

I've been lurking on... well, not SSRG but Retro for around 6-7 years, one of the things which kind of always irritated me is that nobody posted how they have achieved X/Y result so here is a short guide to loading Sonic Heroes' RenderWare .dff clumps (SDK method) before I will show what I have found regarding this section of the game.

For additional information, when Heroes moved to RenderWare (in the case of it possibly being on a proprietary version prior), evidence suggests that the development of the game began at around RW SDK 3.2.0.0 (based from the earliest texture file found which given the version on the E3 prototype, largely predates the prototype) and the final version of Heroes was built on the 3.5.0.0 SDK.

Guide: Viewing Sonic Heroes (& Shadow The Hedgehog) .DFF clumps (RW SDK Method)

Spoiler

Note: It is highly recommended that you use the SDK which matches the version that your game was compiled with, for Sonic Heroes - please use 3.5 and for Shadow The Hedgehog please use 3.7. Don't have the SDK? Wait a few hours, or find it yourself.

• Rip the necessary model you want to inspect from a .ONE archive using the newest version of HeroesONE (hey you saw it announced in the previous post). You can find a few models outside of ONE archives too . Extract to a folder.

• Rip the necessary textures for the objects in question, they should be in the textures folder on the root of the directory (or dvdroot/textures on PC version).

[For GameCube you have to use MAGIC.TXD utility which is the only tool to support the GameCube TXD format]

Note: If you struggle to find the correct texture archive (it should be obvious) then look for links in the file name, for example these are models from comobj.one and textures from obj_common.txd, for stage specific objects such as ones in s01obj.one (Seaside Hill specific objects), rip the level's textures (and effects) from s01.txd and s01_effect.txd as well as s01_indirect.txd.

• Move all of the ripped textures to a folder named textures.

• Place the textures folder in the folder where the DFF clump you are trying to open resides.

• Open the RenderWare SDK's (acquire from another thread here or wait for permission for me to share another version of it) clump viewer utility, it should be located in RW/Graphics/viewers/clmpview/

• Drag the .DFF into the clump viewer and voila, press space if you are interested in accessing specific settings for the RenderWare SDK.

Extra note: Some objects might have multiple animations where only one will be loaded by default, if they do you can load another animation by dragging an .ANM file corresponding to the .DFF clump/model.

[Interesting] The New Findings, Unseen Before/Unused Common Objects

Spoiler

As darkspines35 on Retro said, the Balloon_Locator.dff is the model for the chao that you see in the final's game's special stages. The natural chao, or a slightly modified model for it (I have not checked) is used for Chaotix' Ocean Palace & Lost Jungle in the final and a similar dark chao being used on the baloon in the final, however the Hero chao is never seen again in any of the other prototypes or the final game.

I've scourged the beta to look for any implementation of those guys but I couldn't unfortunately find anything that seems to reference them or their model, trying to place an object with an ID of 23 (hex), which is reserved for the Chaotix' chao in the final brings no result and freezes the game if within render distance.

Taking a brief look at their model and Sonic Adventure 2 Battle, it seems that these chao have not really (if at all) been modified from Sonic Adventure 2, I've not really experimented with SA2 enough before so I didn't rip the SA2 models for comparison but they look pretty much near if not identical to me.
_______________________________


Two (poorly) rounded circular boards with a gap between them. Purpose unknown. Probably intended to be used with face culling by default and therefore shows only one side of the board outside of the angle with which this shot has been shot with. No textures present at all, could not find any references to the object either: it literally is just there with nothing related to it at all, a model and apart from that a dead end.

There is also EFF_BONUSPANEL, completely identical story, except that the panel is an effect rather than an object and that it is a square instead, can't find anything else on it.

_______________________________


In order: OBJ_FOOTA, OBJ_FOOTB and OBJ_FOOTC respectively.

These three textures are hard to see so I applied TriStrips in order to make the objects in question much more visible. These appear to simply be floating platforms, however, while I have not yet found their object ID (they are all under 1 ID), they APPEAR TO BE FULLY FUNCTIONAL (edit: they are functional, I just written this post much earlier ), extracting from Stage00's relocatable module file there, as with any other object are properties in ASCII briefly/roughly explained for the object in question.

Code:

FIXED Type..2 Fences....not in use......................................MOVING Type.ALTERNATELY Type....DISAPPEAR Type..................3 Fences....
4 Fences................Delay Time(Frm).Range 0.................Range 1.................Pos1 Offset X...................Pos1 Offset Y...................Pos1 Offset Z...................Time Cycle(  Frm)..................
Reference Switch ID.........

[OFFSET 0x82820 from start of stage00D.rel]

This awfully reminds me of the moving platforms in Hang Castle, and it is what probably became of this object in the end, poor platform. The object is found between TObjRolldoor and TObjScaffold (though in rel modules the objects aren't in order anyway). The models slightly in my opinion resemble that of the elevators in SA2's Lost Colony stage.

I suppose the most interesting thing is that this thing has a reference switch ID for activating it - apart from that it's presumably just like your regular floating up and down and all around platforms, like the barrels you love minus pressing up and down.
_______________________________


This is the cake of this section post so it is going to get the 360 degree shot it rightfully deserves. OBJ_GATE, a mysterious object with some kind of chao on the front and nothing else is known about it.

I can't any single sort of reference to this object at all, object properties, searched for gates, tried to look for references to the model and nothing was found by me. Personally I believe that this is the object which later became the Omochao gate as referenced in the final version's AFS file containing the character speech, most notably in: all03_h06_** where the wildmarks represent the character.

Why I believe this despite knowing nothing in connection with this gate apart from the symbol with a chao is that the voices were very likely to be recorded after E3 rather than before E3, as for example where
the MKDD prototype has the character voices used in the TGS build (as referenced by its filename and TGS title screen leftovers) which is incomplete and features Omega's voice unfiltered. As this texture does not appear to be complete, the rest of the gate is untextured, it is very likely that this gate has had more work done on it in the future, otherwise there would more likely be no texture or a full texture would have been intact.
_______________________________

OBJ_SEASAWA. This is a seesaw, while how it may have worked is unknown. According to name it is used with OBJ_SEAWGHT to apply force to one part of the seesaw to launch a character up.

My random guess at why it may have been removed would be that it could have been a pace killer which would slow down your level progression. It appears, although I haven't confirmed it (too lazy) to be using the bobsled's textures rather than having own separate unique textures, that's about it.

Also, OBJ_SEASAWA, could there have been an OBJ_SEASAWB? Some objects in Heroes are in fact split into parts, this is just a random guess here on my part as the object names are only shortened if they are long, but SEASAWA if not short for anything, it is a SEASAW with an A padded onto it.
_______________________________

OBJ_SEAWGHT. A weight to be used with the seesaw, it has a handle indicating that it may have been possible to drop or lift the weight in some form or another within the game.

Image: Unused Character Formation Monitors

Spoiler

I've, played around with the properties of the item monitors in the prototype, but it doesn't appear that these Team Sonic images for formations are used. I decided to give them a bit of justice, edited the item layout a bit and ported them into the 10.8 prototype with my Nightly Seaside Hill.

Video: OBJ_FOOTA and Weights In-Game + 3 Extra Object IDs

Spoiler

I didn't mess around with their properties much (or rather enough) but it should be rather obvious how to tamper from the info left in the .rel module posted above.

In the case that this was not made obvious from the video, once a weight is broken, the character which is set free does not function properly and still cannot be selected as well as having no collision - if the original object that was destroyed is despawned the character is not set free either, I've not tested to see if the character stays and is available at a checkpoint however. As for that invisible character glitch, it is simple, just go into first person view and restart the game.

Info: Extra Object IDs
13 - Unbreakable Weight
14 - Breakable Weight
1E - OBJ_FOOTA/FOOTB/FOOTC

Video: Unused Item Capsule Powerups

Spoiler

Time for some short footage, I got all capsules that I could find placed in-game.


The new unseen before in this game items in this short clip are
FP RING - The Red Ring.
M.BARRIER - Magnetic Barrier.
EXPLOSION - The Bomb.
SFP RING - The Red Ring with the S on the bottom left.
RANDOM(x5,B,FPR) - Random item rotating itembox.
RANDOM(x10,MB,1UP) - Random item rotating itembox.

And the Empty box as you have seen it, it doesn't exist in the final game, it's more of a 'default' or item slot to be used.

Getting things out of the way quickly saving talk for the most interesting:
=> The magnetic barrier does not work at all in this build.
=> Explosion is also the same in this regard.
=> SFP RING may actually work but its purpose is not yet implemented, I'll talk about this one in a minute.
=> FP RING is the same story, removed in the 10.8 proto but the texture still exists for it there.
=> The two random capsules.... There are no random rotating capsules in the final game, apart from that they work as intended.
=> Empty box is just an empty box, probably slot for another item in the future or a prank box, it is also found in the 10.8 prototype.

I suppose it is time to explain that red ring jumbo before people start getting obsessed, I've been digging this proto for a while and as such I've already checked almost all of the depths of the prototype.

SFP in the name of the object stands for Super Formation Power as I am led to believe, in fact in the final - this object still exists, it is the instant team blast gauge granting item with the Sonic Heroes 3 ring logo on. In this scenario, this item is meant to fill up the whole of the Super Formation Attack gauge in order to grant instant Super Formation Attack (more commonly known as Team Blast in the final).

Whether this item actually works or not we'd have to see if there is any Super Formation Attack implementation actually coded in the game, I believe there might likely be as the texture assets exist, and from what I seen in Heroes from the new things in the prototypes in general is that the dev team actually writes things first and then creates their assets. It'd be interesting if bringing it back, if it exists would be a possibility.
FP Ring by name simply stands for Formation Power ring, probably intended as a partial refill of the Super Formation Power gauge.

Here's some extra evidence

Source: game_disp***.one/game_disp.txd

Note: This icon is a spoiler for another research post, there's more interesting stuff reserved for other posts.

A Bit Less Interesting: The Changed Objects

Spoiler

Note: 'Unused in this prototype' refers to the object not being placed anywhere in any level rather than the fact that it cannot be placed.

Note #2: When compared, the Prototype objects are on the left, the objects from the final version are on the right.


OBJ_BACKRING. The goal ring which sends Team Chaotix back to the start of levels (whoops, forgot textures). Nothing here really changed apart from the fact that there is a face culled wall in the middle of the object which was probably meant for another image to be displayed of some sort. It is unused in this prototype, potentially placeable. Note: For some reason the clump viewer here is not very happy to texture the object.
_________________________________

EFF_LASER. The effect used for showing the laser later changed in game. The difference between the two is the very rightmost image.
_________________________________

OBJ_BOBSTOP. These are the little things which you see at the ends of the bobsled sections. Slight difference in texture mapping, model is pretty much the same.
_________________________________

OBJ_DSHR. The dash ring, the only difference here is that the inside of the dash rings use the green texture used with the upward pulleys also sometimes used to signify that an object has been activated.
_________________________________

OBJ_DUSHP. The dash pad, it is mostly the same minus the fact that it is much more flat making it seem like sunk into the ground in game and a minor difference with the model itself.
_________________________________

OBJ_FAN. It appears a bit darker than the one in the final and when looked at from the top it appears a bit more flat, probably due to the centre of the fan sticking out more in the final. It is a bit wider too, otherwise pretty much the same. Used in Ocean Palace in this prototype.
_________________________________

OBJ_FLOWERA. Team Chaotix' flower stem, rather than being more of a natural thing it appears that initially it was supposed to be more of a mechanical device instead - apart from that it is more less the same. Unused in this prototype.
_________________________________

OBJ_FLOWERB. No final version for comparison because in the final version the object is split into two chunks. Unused in this prototype.
_________________________________

OBJ_FLOWERC. It looks fine when opened although a bit weird when closed, the animation of the opening for this flower feels a bit more mechanical in my opinion however I do not feel a gif would suffice in showing this.
Unused in this prototype.
_________________________________

OBJ_ITEMBOX_3 The center blue ring with the star is a bit smaller than the final and the overall look after the applied texture appears different.
_________________________________

OBJ_JBOARD. There is a bump on the final model that is not present in the earlier version making the object look less flat as in the prototype, otherwise it is more or less the same, The angle shot here is not the same angle for both objects as I cannot adjust it manually.
_________________________________

OBJ_LASERF. It is the laser fence, it is a much more bulky looking octagon rather than a hexagon, it retains the same shape if looked down from the top view from top to bottom. It is much more shiny and reflective and apart from the change in the overall shape in the top view and the number of legs as well as the overall texture and how it is mapped there is not much more to say. Unused in this prototype.
_________________________________
[Following Images untagged due to TCRF image limit per post]
##http://i.imgur.com/5cmYUCL.png
OBJ_SWA. The switches, the shape of the head is slightly different and the difference in how the object is textured should be self explanatory. Pretty large difference here.
_________________________________
##http://i.imgur.com/FLEuO4n.png
OBJ_UDREEL. The upwards pulley you see in Rail Canyon, here the green ring is inside rather than split into 4 segments covering the face of the object, texture work varies slightly.
The change was probably done to make the pulley more visible in the final version of the game, especially that the colours contrast better in this state.
_________________________________
##http://i.imgur.com/JtiOVyj.png
OBJ_WEIGHT. The same weight as in the final, just texturework differs.

Oh and another spoiler:
##http://i.imgur.com/uc94uks.jpg
Well, the achievement here isn't actually importing the stage for me, at all, I've done that ages ago, it is the fact that I found the object layout for this stage which just happens to be in 1/7 of the prototypes/demos I have. This is presented fully complete with splines etc. inside 10.8. All that's missing are 2 objects which no longer exist in the game (I'm at least certain of that for 1 out of 2 of them, one may just be broken due to incorrect object properties, this screenshot is a bit dated, I've imported it into the E3 Beta since).

Video: All of the new & different objects, 360° view

Spoiler

_________________________________
_________________________________

And this wraps things up for 'Common Objects', in order to document everything I know I'd need another 3/4 posts like these, while I do not know what I will write about next, some things to look out to me posting in the future are...

OPEN THIS AND SPOIL YOURSELF... OR DON'T, THE OTHERS WILL

Spoiler

Levels: TestLevel, Ocean Palace in full, Grand Metropolis level port, Power Plant level port, BINGO Highway level port, Egg Fleet level draft, Frog Forest level port and Lost Jungle level port as well as that dreaded Bullet Station nobody fully seems to have looked at properly, the geometry for this stage is actually there.

Also includes something I've not looked at, potential prototype/early level chunks that I found, and are left over but unused, I've actually not investigated them yet.

Characters & Enemies: Early icons, another mention of Super Formation Attack, physics differences between teams, missing X/Y char effect/ability, enemy textures with palette issues where certain colours are inverted (exactly as seen in some of the early screenshots in SOST in fact - I think by looking at unused enemies however, that it's an utility problem however, not the actual texture) etc. Unidus is also here but I heavily doubt he's used here either.

Level specific objects: That green frog that you could probably actually punch with Nipples The Enchilada Knuckles, giant alligator which slows the game to a cinematic 15FPS, stage specific enemies, some animation differences (maybe if I'm motivated).

Misc: TBD.

These are just the things off the top of my head but this is about 80-90% of the other stuff I've dug up.
All will be supplied with sources and relevant hacking or inspection guidance.

Now it has been 6-7 hours... sleeptime.

 

Thanks for the reply, and sorry for being a bit quiet recently, I do not get much time to do stuff since school kicks in on my resume again. Time for a quick post I guess.

As for Sonic Heroes, well, this game is and always was in a bit of an awkward situation as such, there actually is not much work done from a 'community' as such, it's mainly me when it comes to the prototypes of the game as such and a few people when it comes to the final version of the game and one person who appears to do prototype stuff but mainly shares AR codes. I do work with the GameCube version while the rest have a preference of tampering with the PC version.

From time to time, however you do see some other people who like to tamper with the game that will show something interesting (e.g. Amy's unused & voiced 'Pink Tornado'**), it is a bit similar to SADX in the very early days until a few certain individuals we know have changed the landscape of modding of this game in major ways. I'm afraid that, while the knowledge of said small population regarding to working with the game is big (and half of which is probably undocumented), currently 'we' are in a bottleneck from making any more advances into large scale modding. Undeniably, we'd love custom stages but there is nobody, inclusive of myself who likes to work with the game and has the skill to reverse engineer the collision format for the stages (in fact I'm not very knowledgeable at all outside of basic modelling on this front) and that is and always has been the bottleneck for Heroes for a very long time. With what we have and know, we can import custom textured meshes into the game, split them into segments and properly load them by editing the visibility data ( _blk ) for stages, but it is no fun if you just fall through the floor and die as you hit the infinitely long death plane at (typically) Y co-ordinate 0.

To explain it better with relation to other individuals, I suppose, there is some interest of the game however all the sources of it are very disintegrated and not in the usual places you'd expect. Those people whom are actually interested don't actually seem to sit in the realms of SSRG/Retro for all I know. There is around 4/5 people, inclusive of myself who like to somewhat regularly tamper with Heroes. Awkwardly 'we' don't maintain any sort of contact with each other (literally haven't even ever basically communicated) and sometimes end up finding the same stuff since nobody tends to document things (there really isn't a place to, bar Retro which nobody out of these people is part of). As for me and my side I'm a researcher of this game so I tend to dig up everything in the protos as such, with this proto in particular I believe that I almost know everything there is of worth of mentioning (sadly a lot of the things I know are yet to be posted and documented). With prototypes AFAIK it is only me that likes to dig everything absolutely back to front so I do suppose I get the pleasure to myself.

Anyway, I'll soon be back to posting everything else here, a huge lot to post for this prototype. I've stopped after the second post here for a while due to temporary demotivation and a 'back to school' period. I'm currently developing something (a large script and a collection of scripts) that should make the game much more convenient to mod and much more easy for those who have not played with Heroes before and are unfamiliar with the filesystem, I'll talk about it in the future when I'm comfortable with it, but I'm really liking the output, really happy how it already is handling prototype ROMs as well as final ROMs. After that it'll be back to reporting of this prototype.

I'll also spoil you guys a bit. I guess I have already mentioned this. The other enemies that are not seen in this ROM are fun to play about with, I've been doing that a bit in the test level (ported it over Seaside Hill) for fun (Highlight being that Egg Hammer is kind of 'retarded'). What I have not mentioned is that Unidus is on this ROM, better yet, he is referenced in the stage relocatable memory module files, both model and I believe programming it seems too, sadly I do not know what defines an object's ID or where they are defined in Heroes so finding him would be a case of literally, brute force every ID that is unknown. Heroes has much more IDs than SA, SA2 though, also multiple lists, I'll probably find him relatively quickly however I guess once I get digging and reporting again, only one list is reserved for enemies so I'd have to at most try FF addresses (and add them to the setidtbl.bin to permit them to be placed, since I've done that for the general list in the 10.8 prototype I reckon that I would get past checking every single ID in the enemies list in around 8-12 hours raw testing, although I doubt I'd have to try that many times). (Sonic Heroes has a theoretical limit of FF FF objects, ouch!)

Would anyone be up for translating some few minor Japanese strings in the future? I do not believe there is much of significance, I can figure some out but not the others, sample:

ヒントリグメッセージのテスです。
"This is a test of the hint ring message"

**PS. Here's the obligatory mention to you, (I like to keep everyone anonymous ) I know you'll eventually read this :V, I do not know what happened to you on Retro and why that fate has met you, completely unexplained judgement for no real known reason, I could only think multi-accounts at best. The researcher in me tells myself you are not here. If you want, join me in the SSRG land and let's make Heroes something better. See you in the future.