464 réponses à ce sujet

[pyide]

Oh nevermind. I can add new binds just fine to the ini in notepad++,

ex: Bindings=( Name="LeftControl", Command="shot" ) to take screenshots with left control under [Engine.PlayerInput], save, then open the ini in your program and rebuild and it works. Thanks man, this thing will come in handy!

[Iron Spine]

pyide wrote...

Oh nevermind. I can add new binds just fine to the ini in notepad++,
ex: Bindings=( Name="LeftControl", Command="shot" ) to take screenshots with left control under [Engine.PlayerInput], save, then open the ini in your program and rebuild and it works. Thanks man, this thing will come in handy!

heh that's a use I hadn't thought of. The user going in and making changes and then using my program to automatically recalculate the bytes for the changes they made so the game doesn't puke. Good one. Just remember that will only work for sections my program is actually coded to edit. So at the moment that means only the BIOInput and with next release the additon of BIOEngine. The rest of the data packs are not recalculated because they are not yet edited within the context of my program.

This BIOEngine section is just n-sanely huge and interesting too... there's an AllowD3D10 option that is False by default... once I get finish up here in a second and post the new release with BIOEngine editing I may have to take a break from coding and mess with some of this.

Modifié par Iron Spine, 31 janvier 2010 - 03:45 .

[pyide]

Iron Spine wrote...

heh that's a use I hadn't thought of.
The user going in and making changes and then using my program to
automatically recalculate the bytes for the changes they made so the
game doesn't puke. Good one. Just remember that will only work for
sections my program is actually coded to edit.

Yeah, it seems to work fine too, but only the first time. So if you load up all the changes you want and rebuild it should be good, but if you close out of everything and try to make changes a second time that way the game will crash on load.

Modifié par pyide, 31 janvier 2010 - 05:12 .

[runab0ut]

@Iron Spine

Thanks for the editor. Any known issues that we're supposed to be aware of? Haven't tried it yet, am on a different machine. I do hope it makes backups.

[Iron Spine]

runab0ut wrote...

@Iron Spine
Thanks for the editor. Any known issues that we're supposed to be aware of? Haven't tried it yet, am on a different machine. I do hope it makes backups.

When you 1st launch it part of its initial configuration is to create a copy of your existing Coalesced.ini file to a .ME2CERestore file. At any time later you can simply click the Restore command to restore that file. You should make sure your Coalesced file is the original unedited version when you launch the tool, or at-least make sure the file is working in the game properly if you've made changes to it manually, since it becomes a restore file for the program to use.

There is 1 known issue and it's in the Bugs thread in the project space. The last node can not have its data edited because of an oversight on my part which failed to attached the last data object so when you access the last node it'll detect a null reference. It is caught and does not effect editng anything else nor saving. It just means you can't edit the data in the last section until the next version is released, in which that bug has already been fixed.

[Iron Spine]

pyide wrote...

Iron Spine wrote...

heh that's a use I hadn't thought of.
The user going in and making changes and then using my program to
automatically recalculate the bytes for the changes they made so the
game doesn't puke. Good one. Just remember that will only work for
sections my program is actually coded to edit.

Yeah, it seems to work fine too, but only the first time. So if you load up all the changes you want and rebuild it should be good, but if you close out of everything and try to make changes a second time that way the game will crash on load.

Interesting. I assume any changes you're making outside in NP++ are always isolated within the BIOInput file data?

[pyide]

Yeah, so far I haven't tried changing anything else, it's not an issue or anything because I can edit it all at once when I need to.

[Iron Spine]

I just finished testing some settings changes using the tool for the BIOEngine and it worked like a champ. I removed all custom settings from the GamerSettings file to make sure none would be overriden for the test. I then changed VSync to false in BIOEngine, but the game seemed to still have it on so I was thinking "whaaa hmm". But I looked a bit further and there's another setting in that sectin too called SmoothFrameRate defaults to True. So I set that to False as well and reran the game. Blamo... fps went from 60 to 400. A good sign for editing the BIOEngine data directly in this manner using the utility.

[Kru12000]

Brilliant! Thanks Iron Spine and pyide. Now I can take SS's. (the screens are saved to C:\\Users\\user1\\Documents\\BioWare\\Mass Effect 2\\BIOGame\\Screenshots in .bmp format if anybody is wondering)
Btw there's 2 settings that I think go with SmoothFrameRate. MaxSmoothedFrameRate and MinSmoothedFrameRate. You can change those and keep vsync on with the high fps too. I haven't installed fraps yet to verify this yet though.

Modifié par Kru12000, 31 janvier 2010 - 08:16 .

[BaronIveagh]

That was quick! How long till some more serious mod tools, you think?

[Iron Spine]

BaronIveagh wrote...

That was quick! How long till some more serious mod tools, you think?

I delayed the next release last night with BIOEngine support because I wanted to more fully test it this morning. So far it looks like it's good to go.

I am now adding a Quick Jump featue. We'll be able to save locations with a right click on the treeview and then later jump back to those instantly using a combox containing he saved quick jumps. I thought we could use something like this since the settings are big and it can be hard to locate some of them again (or just tedious) especially in BIOEngine. That data is over 109k in size.

Anyway just need to finish getting a 1st version of the QJ working and then I'll post it.

[Iron Spine]

Kru12000 wrote...

Brilliant! Thanks Iron Spine and pyide. Now I can take SS's. (the screens are saved to C:\\\\\\\\Users\\\\\\\\user1\\\\\\\\Documents\\\\\\\\BioWare\\\\\\\\Mass Effect 2\\\\\\\\BIOGame\\\\\\\\Screenshots in .bmp format if anybody is wondering)
Btw there's 2 settings that I think go with SmoothFrameRate. MaxSmoothedFrameRate and MinSmoothedFrameRate. You can change those and keep vsync on with the high fps too. I haven't installed fraps yet to verify this yet though.

Excellent. I'm having a good time with the code, as well as rummaging around the data discovering things. Found the Min/Max and the other 2 VSync entries plus a bunch of stuff some time yesterday.

As far as what you said about "keep vsyc on with high fps too" I don't quite follow what you're saying on that one. VSync is specifically designed to sync with the current refresh rate. This prevents screen shearing. A side effect bonus of VSync is it dramatically reduces board overheating on boards that can achieve much higher fps if left to just runaway with it (vsync off).

However, with vsync on, there should technically be a cap imposed where it can not exceed the refresh rate otherwise the purpose would be defeated. But it sounds like tha's what you're saying which is why that makes no sense to me. So maybe I misunderstand?

UPDATE:
Perhaps you meant to say the fps can be controlled or fine tuned with the Min/Max settings which is certainly true. If you disable VSync but leave SmoothFrameRate True and adjust the Max upward then what you will do is simulate a vsync of the new number. However this will only limit the runaway factor (which is still good) but not prevent screen shearing / tearing because only a real sync with the refresh rate can address that. But that can be used to control the max FPS for people that run with VSync off especially if they overclock and risk overheating with runaway fps so that will be useful by some to be sure.

Modifié par Iron Spine, 31 janvier 2010 - 04:02 .

[apoc_reg]

Hey guys, great project. will try it out.



Is this similar to the complier someone posted on gamespot?



Also could this be used to bind to the xbox 360 pad, remove gui elements or bind to keys seperately (eg run/walk/use command)?



Thanks again

[Kru12000]

Iron Spine wrote...

However, with vsync on, there should technically be a cap imposed where it can not exceed the refresh rate otherwise the purpose would be defeated. But it sounds like tha's what you're saying which is why that makes no sense to me. So maybe I misunderstand?

You're right! I've spent the whole afternoon trying to fix the performance issues with this game by mucking with the .ini files and for some reason got it in my head that you can have high framerates with vsync on if you got triple buffering on as well... lol. After finding out the game doesn't cope well with one of my bios settings I'm a bit delirious now trying to see how far I can max things out with graphics options

[Iron Spine]

apoc_reg wrote...

Hey guys, great project. will try it out.

Is this similar to the complier someone posted on gamespot?

Also could this be used to bind to the xbox 360 pad, remove gui elements or bind to keys seperately (eg run/walk/use command)?

Thanks again

I am trying to get the next version released in the next few minutes which adds huge BIOEngine support. It is important to note that rebuilding calculations are only applied to data sections explicitly supported by the tool, while other ares are treated strictly in their original binary streamed formet.

What I mean by that is right now the tool supports BIOInput and BIOEngine explicitly, so those 2 data sections are included in recalculation when rebuilding, while all other sections retain their existing structure. So this means any changes you make in BIOInput and BIOEngine sections will be included in recalculations, but any changes made to any other areas will not until or unless support for those areas are added to the utility.

Since most bindings of this nature that I've seen so far *appear to be* in BIOInput then you probably can however if they have to be created in a different section (not in BIOInput and not in BIOEngine) then it won't work unless you manually recalculate the bytes, or support for that area is added to the tool.

[Iron Spine]

Kru12000 wrote...

Iron Spine wrote...

However, with vsync on, there should technically be a cap imposed where it can not exceed the refresh rate otherwise the purpose would be defeated. But it sounds like tha's what you're saying which is why that makes no sense to me. So maybe I misunderstand?

You're right! I've spent the whole afternoon trying to fix the performance issues with this game by mucking with the .ini files and for some reason got it in my head that you can have high framerates with vsync on if you got triple buffering on as well... lol. After finding out the game doesn't cope well with one of my bios settings I'm a bit delirious now trying to see how far I can max things out with graphics options

Hey let me get this next version posted and you'll be able to do CRAZY amount of fiddling with graphics related settings in the BIOEngine data. You'll want to look at th SystemSettings entries 1st  but there's a ton of others.

[Iron Spine]

Release 1.2B is posted with BIOEngine support. Needs heavily tested and any bugs reported please.

[Kru12000]

yo apoc somebody already remapped the keyboard shortcuts to their controller.
social.bioware.com/forum/1/topic/106/index/774202
Thanks to Iron Spine's app this should be easier to do using the rebuild function after making the necessary additions in Notepad++.

Modifié par Kru12000, 31 janvier 2010 - 05:56 .

[Iron Spine]

Kru12000 wrote...

yo apoc somebody already remapped the keyboard shortcuts to their controller.
social.bioware.com/forum/1/topic/106/index/774202
Thanks to Iron Spine's app this should be easier to do using the rebuild function after making the necessary changes in Notepad++.

Hey excellent that might help Pyide because he wants to do the oppostie. Map controls in the menus currently bound to the keyboard to the mouse instead. I haven't had any time at all to search for stuff because I'm too busy writing code but I know he's searching hisbutt off trying to find the bindings for menus to keys. Don't know if that thread will help but hopefully.

[devlaZ]

Works great, thanks

[Dayson_Dawn]

So I just downloaded this and I notice in ME2 my mouse is a bit.... sluggish. Can someone write down their settings so i can match theirs.



Also so project members, do you think it's possible to add the section where you can modify how long corpses stay?

[Iron Spine]

Dayson_Dawn wrote...

So I just downloaded this and I notice in ME2 my mouse is a bit.... sluggish. Can someone write down their settings so i can match theirs.

Also so project members, do you think it's possible to add the section where you can modify how long corpses stay?

Which embedded file is that in? Right now BIOInput and BIOEngine are supported. Once the code reaches a stable state and I've added some more of the basic features I have in mind then adding support for more embedded data is certainly possible. After all that's how it evolved over the last 2 days. I added BIOInput and then finished addin BIOEngine this morning.

As far as adjusting the mouse someone else that's been messing with mouse settings will need to chime in. My default settings are actually just fine so I didn't need to tweak them at all. But I know a lot of people did which is why I wrote the program in the 1st place, it's just growing

Speaking of that I had an idea this morning that I'm now working toward. Because the data is spread across such a wide range, especially the huge BIOEngine data, I am creating a mechanism to make it easier to keep track of where settings are and what they do.

So for example here's what I have in mind, and am actively coding right now. A Quick Jump Panel with complex object support. Theory: Create a new entry with a category name of Mouse Tweaking. Inside this new category object add nodes related to tweaking the mouse. Click on one of these quick jump nodes and bam, it takes you directly to the associated node you need to edit in the BIOInput or BIOEngine trees.

Anyway it's just a thought and I'm working on it right now to see how feasible and useful it'll be. I'm thinking this might work pretty good and really help cut down on tediously re-finding entries a person may be working on a lot as they fine tune them for their system

[Dayson_Dawn]

Iron Spine wrote...

Dayson_Dawn wrote...

So I just downloaded this and I notice in ME2 my mouse is a bit.... sluggish. Can someone write down their settings so i can match theirs.

Also so project members, do you think it's possible to add the section where you can modify how long corpses stay?

Which embedded file is that in? Right now BIOInput and BIOEngine are supported. Once the code reaches a stable state and I've added some more of the basic features I have in mind then adding support for more embedded data is certainly possible. After all that's how it evolved over the last 2 days. I added BIOInput and then finished addin BIOEngine this morning.

As far as adjusting the mouse someone else that's been messing with mouse settings will need to chime in. My default settings are actually just fine so I didn't need to tweak them at all. But I know a lot of people did which is why I wrote the program in the 1st place, it's just growing

Speaking of that I had an idea this morning that I'm now working toward. Because the data is spread across such a wide range, especially the huge BIOEngine data, I am creating a mechanism to make it easier to keep track of where settings are and what they do.

So for example here's what I have in mind, and am actively coding right now. A Quick Jump Panel with complex object support. Theory: Create a new entry with a category name of Mouse Tweaking. Inside this new category object add nodes related to tweaking the mouse. Click on one of these quick jump nodes and bam, it takes you directly to the associated node you need to edit in the BIOInput or BIOEngine trees.

Anyway it's just a thought and I'm working on it right now to see how feasible and useful it'll be. I'm thinking this might work pretty good and really help cut down on tediously re-finding entries a person may be working on a lot as they fine tune them for their system

Just wanted to say thanks for updating. As for where the file is I am unsure. There are 4 or 5 entires in the coalesced file. if you ctrl + f and type in 'corpse' you'll see the entries.

I apologize I can't tell you the file. Currently away from the comptuere where ME2 is on

Modifié par Dayson_Dawn, 31 janvier 2010 - 07:21 .

[Iron Spine]

Dayson_Dawn wrote...

...

Just wanted to say thanks for updating. As for where the file is I am unsure. There are 4 or 5 entires in the coalesced file. if you ctrl + f and type in 'corpse' you'll see the entries.

I apologize I can't tell you the file. Currently away from the comptuere where ME2 is on

Hey that is not a problem. There's a LOT of embedded files in the Coalesced file and I don't expect anyone that's not been heavily examining the structure to know what they're actually looking at yet.

The file those settings are in is called BIOGame.

Just to clarify for you and turn on a light so you'll be like OH! Ok!:

This is my concept of the coalesced file based on my exploration so far. Anyone that knows different or corrections please chime in:

The coalesced file contains a number of other files. Each file is compacted to its minimum size with all extranious trailing spaces and unneeded entries removed and then inserted into the Coalesced file as a file entry. The result of this is a highly optimized file that is as compacted and small, and therefore effecient, as it can possibly be while still being human readable.

Each file entry, such as BIOGame.ini defines its own length in its entry header. This is how the game processes each file in Coalesced.ini. It locates each file entry, such as BIOGame.ini, then processes the header for that entry, and then it knows all the data related to that file because it knows the length of the file and can simply chew it into a structure and then pull the settings from it. Then it would move on to the next file entry nd repeat the process etc etc.

Anyway that's just my concept of what is probably happening I don't know that for sure.

[Dayson_Dawn]

Iron Spine wrote...

Dayson_Dawn wrote...

...

Just wanted to say thanks for updating. As for where the file is I am unsure. There are 4 or 5 entires in the coalesced file. if you ctrl + f and type in 'corpse' you'll see the entries.

I apologize I can't tell you the file. Currently away from the comptuere where ME2 is on

Hey that is not a problem. There's a LOT of embedded files in the Coalesced file and I don't expect anyone that's not been heavily examining the structure to know what they're actually looking at yet.

The file those settings are in is called BIOGame.

Just to clarify for you and turn on a light so you'll be like OH! Ok!:

This is my concept of the coalesced file based on my exploration so far. Anyone that knows different or corrections please chime in:

The coalesced file contains a number of other files. Each file is compacted to its minimum size with all extranious trailing spaces and unneeded entries removed and then inserted into the Coalesced file as a file entry. The result of this is a highly optimized file that is as compacted and small, and therefore effecient, as it can possibly be while still being human readable.

Each file entry, such as BIOGame.ini defines its own length in its entry header. This is how the game processes each file in Coalesced.ini. It locates each file entry, such as BIOGame.ini, then processes the header for that entry, and then it knows all the data related to that file because it knows the length of the file and can simply chew it into a structure and then pull the settings from it. Then it would move on to the next file entry nd repeat the process etc etc.

Anyway that's just my concept of what is probably happening I don't know that for sure.

I should've mentioned earlier today I adjusted the values as appropiate for corpses to say and it was a no go. but I have faith in your team :happy: