Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - lasyan3

Pages: [1] 2 3 4
Hack7 doesnt check for sector sizes but just extends and thus brakes the ISO if a file got larger than the original. ISOs will end up larger than before and with messed up LBAs, use cdprog to insert the files. If a file should really get too large to fit into the sector you get an error message and must delete or shorten some dialogue.

What are you saying? Of course Hack7 (and also Mass Iso Update) check for sector sizes! It also scans the iso for empty spaces and reallocate files based on their sector size. It was designed to allow saving of files bigger than original size. The only thing it doesn't do is recalculate ECC, but CDMage can dot it easily. Why are you saying that it doesn't work?

That's good lasyan3, I'm glad you are still working on this project.

Well, to be honest I don't really plan to work seriously on the project anymore (the steal of my laptop didn't help, even if I had not too old backups), I will make an effort at least to repair some bugs but I can't promise I will work again on new features. But hopefully you can still use the amazing Makou Reactor ;)

But since I'm still in contact with a french guy who is still working on the translation, and since he asked me some features (like editing tutorials, menus and world messages), eventually I'll do my best to add those at least.

Anyway, I just uploaded a new revision of Hack7 for your window.bin matter (I didn't put a news on the site neither changed the version since it's a very small debug). Can you test it and tell me if it's ok for you now?

And about the field maps, could you send me one corrupted file so I can analyze the content? Thanks.

Hi Green_goblin,
Well, since the compression function is not the same that the one square used, it's normal to have some minor differences in file sizes.
BUT I admit I found a bug with Hack7, that makes the file of the font twice less ! I'm working on it, I'll tell you when I made the correction asap.

You're welcome :-D

I think field.bin stores both position and size...
That's right.

I don't suppose you mean that the field model files themselves are contained within the .DAT files (.DAT files are quite small), so I assume you mean that the file names are explicitly mentioned...or do you mean that their LBAs are mentioned, in hex? If so, I assume these .DAT files are little-endian, like the various .BIN files FF7 uses? I'll do some digging with a hex editor later today.

You're right, the fields models themselves are not in the DAT but in the BSX files (and BCX files for the main characters). The information in DAT files is only indexes and some information to personnalize the models (like the light if I remember clearly).
In the BSX files, you'll also find the animations for the models (run, walk and all the animations used in the field).
More information in the wiki

Hack could eventually just show a warning and ask the user to let it correct the jump by choosing the command just before or after the bad value, but Makou Reactor has already a kind of solution by displaying the incorrect lines in red :

Exactly, what's this corruption issue you guys are talking about?

I just sent MP to Lazy Bastard, but FYI it's not really corruption: it's about jump recalculation of the IF commands in the script after you add or change it (the jump values are not recalculated automatically in Makou Reactor, but you can check if you see some red lines in the script, it tells you something is wrong with your script flow). Since Hack7 does the recalculation job, it can tell if there is an error in the flow (in this case, the "target event not found" means that the target of the jump value for a IF command was not found).


I'm glad it worked, i asked a friend who knows slightly more about the psx version then myself and he mentioned the FIELD files are read from the LBA (so it probably doesn't use the filename but uses where on the disc it is) which is apparently decided in the file FIELD.BIN (which is in the FIELD folder) and that is Gziped, i don't know how correct this information this is but it may be a good place to start.
That is correct.
I wasn't aware that Hack7 couldn't open modified files. I also wasn't aware of any corruption in hack7 latest version but if there is you could also report that to the creator and just stick to Makou Reactor for now.
Me neither! Thanks for the feedback, I'll get the last version of Makou Reactor and see how to solve this corruption matter ASAP.

Hi TheJolly,

I think you get this error because you selected the field folder from the iso, which is only accessible for readng. Hack7 needs write access to the file. So i suggest to copy the folder on your hdd, and try again.

Well, perhaps Square did use a kind of visual editor that allowed them to directly put field models inside the walkmesh (and also generating the appropriates field opcodes), but this is not something I plan for Hack7.
I'm trying to display the walkmesh and the x,y,z values, and also the triangle id when clicking on a part of the walkmesh with the mouse. Well, if one day we (myst6re and I) success to manage this damned camera :x

DLPB, what do you mean ? I don't understand your question.

One thing missing from this and Makou is the ability to click on a map and get correct x,y,z,t values, so you can place items easily.

You're right, I'm working on it. I can display the walkmesh, but I still have some difficulties whith placing the field camera.

Hi demeterf,
You can use my other tool, MassFieldUpdate, to save multiple files inside an ISO in one single operation.
Is it what you want to do ?

Hi DSieg,

It's because sectors in the cd have a kind of CRC to check the data inside, and I don't recalculate it :P. So yes, it comes from Hack7.
But you can easily rebuild those sectors and recalculate thoses CRC by using CDMage.
With this tool, you can use the "Scan for corruption" function in the "Action" menu, so it will check your iso and tell you which sectors are incorrect. Then, use the "Rebuild sector fields" from the same menu. Should be ok (it worked for me right now, my iso was indeed damaged).

Yes, and you will also have to edit the graphical font of the game (in window.bin).

Running in administrator mode, yet I still get Access to the path 'd:\dat_ini.dec' is denied.

OOps, I did it again (dat_ini.dec is a file generated for my tests, I forgot to disable it :-[). Should be ok now.

No, Hack7 doesn't currently allow to add new messages. And now that you tell, it's a shame! I will see what I can do for that.

Well, after some research, I discovered that in the field scripts, variables of offset 0xF are always set with the SETBYTE command, while variables of offset 0x7 use SETWORD. Same for the commands INC & INC2, DEC & DEC2, and some more. So I'm almost sure that the 2 offsets might be inverted.
But, because the 2 offsets are pointing to the same bank, the same data, it's only the way the field script engine access it that changes. That may be why Black Chocobo works anyway, it probably access the datas on its own, it may not bother on the offsets.


I think there is a mistake in the savemap in the wiki.
I was displaying the content of some variables in a field message, and I found out that variables of bank 5 with offset 0xF are wrapped around by 255. And on the other side, variables of bank 5 with offset 0x7 can display a max of 65535... So it seems that the 2 offsets should be exchanged in the table.


Do you mean something like this :
Code: [Select]
02 - REQSW - CallEntityStartWait
49 - MENU - ShowMenu

Ok I got it.

When I was trying to do :
Code: [Select]
$TW600 = 10;
$TW600 = AddCap16( 42767 );
In fact it was :
Code: [Select]
$TW600 = 10;
$TW600 = AddCap16( -22769 );
Which give -22759, which equal to 42777 when unsigned... Thanks Aali.


Now that I released my tool Hack7, I decided to take some time to play with it. Right now, I'm making some tests to figure out how those events are working, and I don't really get it, so I hope somebody will be able to help me.

In the Wiki, for the event PLUS2! (0x77) it is said that the parameter is signed and the result of the addition is capped at 32767.
In fact, when I try this (code from Hack7, $TW600 is a word variable) :
Code: [Select]
$TW600 = 10;
$TW600 = AddCap16( 32767 );
or this :
Code: [Select]
$TW600 = 32767;
$TW600 = AddCap16( 10 );
The result is indeed capped at 32767.

However, when I try this :
Code: [Select]
$TW600 = 42767;
$TW600 = AddCap16( 10 );
or this :
Code: [Select]
$TW600 = 10;
$TW600 = AddCap16( 42767 );

The result I get is not 32767 as expected, but 42777 instead !!! So, it seems that once the initial value is bigger than 32767, the addition doesn't cap anymore the result ! And it would also mean that the parameter is not signed !
If someone has any idea, please...

Also, it would be great if clicking on the message ID (in the message tab) would instantly point you to the Event script that calls said message. For example, if you wanted to edit the event regarding the bald guy in Sector7 who whines that Johnny's gone, you could click on its message (or its ID, which is 073), and the program would directly lead you to E28: oyaji1 S1 "OnTalk" in the Events tab. Right now, it's sometimes a pain to find the event you're looking for.
I will see what I can do ;). You're right, the tool is missing a search feature.

First question :
Code: [Select]
/*AKAO [0xF2]( 0x00, 0x00, 0x00, 0x29, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 )*/;What are these lines of code for ? Are they important to add, when initiating a battle ?

When you find a line of the form /*NAME [HEX_VALUE] (HEX_VALUE, HEX_VALUE, ...)*/;, it means that the command is not yet fully decrypted (either in the qhimm wiki, either I didn't understand it :-[). But one can still change the HEX_VALUE to make some test, it will be saved.
So I can't tell you if there is some connection between this command "AKAO" and the battles... I think AKAO is linked with sounds, but I'm not sure of anything...

Here is my second question : is Hack7 clever enough to add a Bahamut materia to the inventory, if I type "MateriaAdd( Materia.Bahamut, 0, 0, 0 );" instead ? If yes, I don't know how you managed to make your program turn real words into bytes, but you rock.
I think you probably noticed that when you write "Materia" followed by the dot, a kind of autolist will popup, letting you choose the materia you want.
To fully understand how it works, you should read this short article about C# enums. One of my main goal when working on the new field events interpreter, was to make editing as simple as possible, which means to avoid byte values when possible. So I used this "enums technique" which make the selection of items, materias, field maps and so on much easier. Glad that you like it :D.

Code: [Select]
ItemAdd( Item.ItemPotion, X );This one is confusing. Do one always has to attach "Item" to the item name ? Like :
ItemAdd( Item.ItemTurbo Ether, 1 ); ?
So, I guess that Item.AccessoryBoltRing wouldn't work - I bet one would have to add the typo for the line of code to work :P
For armors and weapons, is it Item.ArmorMystile and Item.WeaponWizerStaff ?
Yes, it's because "Item." is the type of the parameter of the command "ItemAdd", and ItemTurboEther is the value selected for this parameter.
The case of items is special, because there are many many items : basic items (potions, ethers...), armors, accessories and weapons for cloud, aerith, etc. So I added equivalent "subtype" names to clearly separate all kind of items. But you don't need to "guess" the name of the item/materia/etc. you want to add. Just write the type ("Materia", "Item", etc.) followed by the dot, and the autolist will show you all the possible values you can use.
Note: in the current version, the autolist doesn't filter the values with what you write, it only select the value based on the first caracters you write. So if you write for example "Materia.Baha", it will positions itself on the "Bahamut" value. The next version of Hack7 will introduce a better mechanism : when you will write "Materia.Baha", it will show you the 3 materias (bahamut, neobahamut and zero). It will also be case insensitive.

But we know that when you obtain a materia, the sound you hear is different from the one that plays when you obtain an item. In Meteor or Makou Reactor (Field editors for the PC version), the play sound calls a different byte to reflect this. So, what gives ?
This is strange, because in the PSX version the parameters of the sound command for the potions in the first screen of the game, and the materia restore in the reactor, are the same. Maybe the sounds are stored in the field files in the PSX version, while they are in a common place for the PC version...

Pages: [1] 2 3 4