Bio2 Bio1.5 Mix

[AleX_Red_07]

Impressive.
Thanks for the update.

[Graco]

Wow that's pretty awesome. Any plans on what you might implement in the future with your recent development?

And no rush here by the way, things are getting more interesting. I'm still holding out for trial rooms to be added if they haven't been already.

[Mikhail]

You added file headers to each file type type so it just reads the file headers then loads whole files instead of getting lba + filesize? did you overcome the 255 file limit too?, can it be set as high as possible say 999? irc epsxe will read custom iso's past 650mb and has multi disc combine tools.

[MeganGrass]

Wow that's pretty awesome. Any plans on what you might implement in the future with your recent development?

And no rush here by the way, things are getting more interesting. I'm still holding out for trial rooms to be added if they haven't been already.

I'm already toying with the idea of multiple scenarios for multiple characters, in addition to testing both retail Bio2 and Bio1.5 running from the same disc. Multiple scenario setup is already working a charm.

For a better understanding of the multi-scenario ordeal, just simply imagine Bio1 with both Chris and Jill's scenario's playable from one disc. This idea be expanded much, much further, by having multiple games running from the same disc.

The idea behind multiple games really isn't about multiple "games", persay, it's really just a clever way of adjusting & creating the proper code & flags to handle something of the sort, in addition to the custom runtime data & disc structure that corresponds with said code, both of which I have already completed.

So, imagine this: you boot up the game and you're given the option to play either retail Bio2 or Bio1.5. Or, in another case scenario, that extra runtime data could be an unlockable mini game, with all-new characters, locations, weapons, enemies, etc. Or, it could simply go unused. It's all just fun and games, for now.

As for some of those Trial rooms, here ya go:

You added file headers to each file type type so it just reads the file headers then loads whole files instead of getting lba + filesize? did you overcome the 255 file limit too?, can it be set as high as possible say 999? irc epsxe will read custom iso's past 650mb and has multi disc combine tools.

Something similar to that, yeah. All RDT data is archived into a single, encrypted file. It still gets the LBA and filesize (that's imperative), but it does so in a way that is just as fast but 100x more convenient than the original setup they used.

As for the 255 file limit thing, I really have no idea what you're talking about... but no, I am not limited to maximum file limits, if that's what you mean.

Right now, I have all runtime Bio2 and Bio1.5 data on one disc, and it isn't anywhere close to being 650mb. Streaming video (*.str) is the absolute reason why those retail discs are bloated, so I have nothing to worry about there.

[J0shuaKane]

were you able to implement the improved partner AI you developed for retail?

[MeganGrass]

were you able to implement the improved partner AI you developed for retail?

Uhmmm, you'll have to refresh my memory

I have thoroughly tested various partner AI in drastically different situations, all went as planned... but I'm also using an advanced script compiler.

I have learned a lot over the past year or so, and I have determined that partner AI can be used anywhere in the game, given the following conditions are true:

First and foremost, the script bytecode must have the proper flags for spawning, otherwise the NPC will have the intelligence comparable to that of a bag of sand.

There simply can't be too many enemies in a room, in order for partner AI to work properly - this scenario will likely lead to the game crashing.

Even after everything is setup to perfection, having partner AI isn't always the best experience, and so I am considering looking into a possible solution to make the partner slightly more intelligent. I was recently given a very nice, blank template written in C for creating AI for this game, so we'll see what happens.

[AleX_Red_07]

It looks very cool.
Your achievement is really adorable.
While watching the video, I heard good music bio3, only Carlos is not enough.

[Mikhail]

I'm already toying with the idea of multiple scenarios for multiple characters, in addition to testing both retail Bio2 and Bio1.5 running from the same disc. Multiple scenario setup is already working a charm.

For a better understanding of the multi-scenario ordeal, just simply imagine Bio1 with both Chris and Jill's scenario's playable from one disc. This idea be expanded much, much further, by having multiple games running from the same disc.

The idea behind multiple games really isn't about multiple "games", persay, it's really just a clever way of adjusting & creating the proper code & flags to handle something of the sort, in addition to the custom runtime data & disc structure that corresponds with said code, both of which I have already completed.

So, imagine this: you boot up the game and you're given the option to play either retail Bio2 or Bio1.5. Or, in another case scenario, that extra runtime data could be an unlockable mini game, with all-new characters, locations, weapons, enemies, etc. Or, it could simply go unused. It's all just fun and games, for now.

As for some of those Trial rooms, here ya go:

Something similar to that, yeah. All RDT data is archived into a single, encrypted file. It still gets the LBA and filesize (that's imperative), but it does so in a way that is just as fast but 100x more convenient than the original setup they used.

As for the 255 file limit thing, I really have no idea what you're talking about... but no, I am not limited to maximum file limits, if that's what you mean.

Right now, I have all runtime Bio2 and Bio1.5 data on one disc, and it isn't anywhere close to being 650mb. Streaming video (*.str) is the absolute reason why those retail discs are bloated, so I have nothing to worry about there.

I meant the debug menu and inventory for instance in the pvb it only references 00-FF for the rdts and items and is missing multiple entries, hence db's problem with having to remove certain rooms to make space for overs that where already taken up.
If say I wanted to add a extra pld, wep or rdt to the new container files you've setup would I just need to rebuild the container file without having to add new instances into the exe to read them.

[MeganGrass]

I meant the debug menu and inventory for instance in the pvb it only references 00-FF for the rdts and items and is missing multiple entries, hence db's problem with having to remove certain rooms to make space for overs that where already taken up.
If say I wanted to add a extra pld, wep or rdt to the new container files you've setup would I just need to rebuild the container file without having to add new instances into the exe to read them.

Well, I'm not using the executable from Bio1.5 - I am using the Bio2 beta executable as a base, whereas I've already begun the process of porting my code to the Dual Shock ver.

...and like I said before, I am not restricted to or capped by maximum file limits. I can put 4,294,967,295 separate RDT, PLD, PLW, DO2, BGM, etc files on the disc, if I'd like.

DarkBiohazard's problem appears to be that he expects to fix the entire vanilla build by adding runtime data. This is not "how it works" - the ability to program and to insert one's own code is required. At the absolute, minimal, the ability to at least modify the executable is required, even if only on a very small scale. Until he learns, or at least, realizes this, nothing is going to change or be accomplished.

...also, there isn't any cap on the vanilla build of Bio1.5, either. I have absolutely no clue where you get this 0xFF count.

So yes, that's how it works - Each archive is compiled during toolchain batch operation, which takes a grand total of about 10-15 seconds. In other words, anything I want to add can be tested in-game, real-time, in about 20 seconds (have to give the emu time to boot up, heh).


EDIT:
Another thing I wanted to add is that I am not using the original ROOM_POS structure (the index that contains the names and coordinates of rooms in the debug menu). I am using a similar, but custom structure that is located within an overlay. Since I created the overlay from scratch and it's compiled during toolchain batch, I am able to adjust this table for as many RDTs that I'd like to add.

By default, the engine can contain 48 RDTs per Stage, where it's capped to 7 Stages. The corresponding overlays that contain Stage data have been recreated from scratch and compiled during toolchain batch, again, allowing me to add/remove anything I wish to account for everything.

Long story, short - I can add or remove anything from the disc that I wish, and get the executable to recognize and load it.

[Ultimacloud123]

I would like to learn more about the whole RDT and stages thing if you don't mind explaining. About how many RDTs and stages are present in RE, 1.5, and RE2? This is all new to me and want a better understanding.

[MeganGrass]

I would like to learn more about the whole RDT and stages thing if you don't mind explaining. About how many RDTs and stages are present in RE, 1.5, and RE2? This is all new to me and want a better understanding.

I don't know of Bio1's limits on this matter.

For both Bio1.5 and Bio2, it's exactly as I mentioned - 48 rdts per Stage, 7 Stages max (I think Bio1.5 is limited to 6 stages, I can't recall right now).

The overlays I mentioned contain very limited, yet required information that pertains to each stage set of rdt data. The overlays are loaded into memory when the player transitions from one rdt stage to another.

Mind you, that's the default limit - I can push it past this, if I really wanted to.

[Mikhail]

Well, I'm not using the executable from Bio1.5 - I am using the Bio2 beta executable as a base, whereas I've already begun the process of porting my code to the Dual Shock ver.

...and like I said before, I am not restricted to or capped by maximum file limits. I can put 4,294,967,295 separate RDT, PLD, PLW, DO2, BGM, etc files on the disc, if I'd like.

DarkBiohazard's problem appears to be that he expects to fix the entire vanilla build by adding runtime data. This is not "how it works" - the ability to program and to insert one's own code is required. At the absolute, minimal, the ability to at least modify the executable is required, even if only on a very small scale. Until he learns, or at least, realizes this, nothing is going to change or be accomplished.

...also, there isn't any cap on the vanilla build of Bio1.5, either. I have absolutely no clue where you get this 0xFF count.

So yes, that's how it works - Each archive is compiled during toolchain batch operation, which takes a grand total of about 10-15 seconds. In other words, anything I want to add can be tested in-game, real-time, in about 20 seconds (have to give the emu time to boot up, heh).


EDIT:
Another thing I wanted to add is that I am not using the original ROOM_POS structure (the index that contains the names and coordinates of rooms in the debug menu). I am using a similar, but custom structure that is located within an overlay. Since I created the overlay from scratch and it's compiled during toolchain batch, I am able to adjust this table for as many RDTs that I'd like to add.

By default, the engine can contain 48 RDTs per Stage, where it's capped to 7 Stages. The corresponding overlays that contain Stage data have been recreated from scratch and compiled during toolchain batch, again, allowing me to add/remove anything I wish to account for everything.

Long story, short - I can add or remove anything from the disc that I wish, and get the executable to recognize and load it.

The cap i'm refering to is the one inventory items / debug menu rdts for example you can scroll to FF then it resets back to 00 as it doesn't goto 0100 or higher.
You say the stages are limited to 48 rdts per stage, I'm guessing the plds and weps are also capped? it's just a case upping the table count in the stages for each file type?

why knock db, mine or over patchers efforts? none of us have claimed that where fully able to restore the game to it's full glory, we only provide said patches for overs enjoyment, mostly as a stop gap until the real thing leaks.
You seem to take offense to this but I don't know why, are we somehow lowering the godlyness of this game by providing inadequate patches by your standards? since when did re become yours, TeamIGAS and Geminis intellectual property? the whole encryption protection is pure bs.

[MeganGrass]

The cap i'm refering to is the one inventory items / debug menu rdts for example you can scroll to FF then it resets back to 00 as it doesn't goto 0100 or higher.
You say the stages are limited to 48 rdts per stage, I'm guessing the plds and weps are also capped? it's just a case upping the table count in the stages for each file type?

why knock db, mine or over patchers efforts? none of us have claimed that where fully able to restore the game to it's full glory, we only provide said patches for overs enjoyment, mostly as a stop gap until the real thing leaks.
You seem to take offense to this but I don't know why, are we somehow lowering the godlyness of this game by providing inadequate patches by your standards? since when did re become yours, TeamIGAS and Geminis intellectual property? the whole encryption protection is pure bs.

Oh, the items that you can collect in game. Yes, I can surpass the 0xFF count, but I haven't done so yet.

Currently, PLD and PLW counts are capped ... however, I plan to change that. It will require some more programming, but I am able to swap out player AI with each PLD load, therefore, giving me 16 max players all with their own AI - which I can now start messing with. After that it accomplished, I will simply uncap the max count and push it to an unsigned short (65535 max PLD files).

I take absolutely no offense from anything, and never meant to give any, actually. You asked about the issue and referenced him, and I know that he's trying to improve it for everyone's enjoyment, but facts are facts. Programming is absolutely required to allow for more data that exceeds the normal/default limits. It doesn't matter the game, system, etc - something that massive requires it.

...and no, none of this is my intellectual property hahahaha I never claimed it was, and truth be told, I'm not exactly a big fan of 1.5 - it was a complete flop, in my opinion. I am merely testing old data in a new engine solely for the purpose of learning and fun.

So far as my encryption is concerned, it's only going to be enabled in my own private and public builds. As mentioned on one of the YouTube pages, I am going to release the source and everything required to run this build using my custom CD layout. That way, everyone who is interested can check it out and make their own custom builds with insane amounts of data with no caps.

That said, encryption will be removed from the public source. However, there will be and option in the source to enable one's own encryption method - I am not providing anything of the sort, as it is totally up to the user to determine and code the option, not to mention writing the PC application that will encrypt said data.

Really, there's nothing to get upset about. Source and tools get released, everyone is happy, both modders and enthusiast alike.

[Mikhail]

I'll look forward to a seemlessly linked 1-3 running on the same disc then :-)
meanwhile work starts on my re0 thriller / investigative drama prequel staring Ben, Barry, Chris, Wesker and Chief Irons, I'm hoping to make it similair in style and pace to Grim Fandango, Fahrenheit, Fear Effect, Alone in the Dark: The New Nightmare.

[Gemini]

since when did re become yours, TeamIGAS and Geminis intellectual property? the whole encryption protection is pure bs.

You are missing the point here. The fact is that Mark's code and all the extra work done here is indeed Mark's intellectual property, just like Squeeze Bomb is my intellectual property, and IGAS' work belongs to IGAS alone. As for the encryption, it is quite essential because we all know what happened in the past. I mean, this is the internet, you know how it works.