°Aslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=14;area=showposts;start=375e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index0b4a.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=14e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index0b4a.html.zx╬╝g^                    ╚0P.ирOKtext/htmlISO-8859-1gzip8:╓ир        Tue, 10 Mar 2020 16:30:29 GMT0є░░ о0оPоАз▓Ёо═╝g^        #ир Show Posts - Pinkpuff

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 - Pinkpuff

376
Sorry, it didn't even occur to me that it would be in an entirely different part of the code (not sure why though, that does make sense).

So wait... does this mean the people in the normal party will also get less EXP the more people are in shadow? If so, maybe it should be a separate (but compatible) patch? After all, that would still mean that people in shadow progress at the same rate as those in the acutal party, but the rate itself is slower.

377
Great work! This is so exciting!

Since we're at it, I always thought it was a little cheezy that everyone in the shadow party gets the full EXP, allowing a solo character to basically turbo-level everyone at once, as well as being a little silly to think that the people out fighting are levelling up just as quickly as the people in reserve. Maybe it could be divided by something? Or maybe make it customizable... multiply by X and divide by Y where X and Y default to 1 but you can give the addresses so that the person applying the patch can customize the ratio as he or she sees fit? Anyway I don't mean to add unnecessary complication, just indulging in a little wishful thinking since that part of the code is being rewritten anyway.

378
Keep in mind that what you're doing is outside the scope of what FF4kster is designed for. It assumes that it is going to be the only thing modifying your rom, with the possible exception of graphics or something. If you make other changes and they happen to be compatible, that's great. If you can use other editors and they don't interfere, that's great too, but if it does cause a conflict, FF4kster will simply shrug and say "sorry to hear it bro".

Chillyfeez's suggestion seems logical. I'm not certain the "fill with FFs" step is even necessary though, couldn't you just make a patch with your custom battle code and use the rom output by FF4kster as the "base"?

379
Looking back at my code, I discover the editor doesn't even parse that bit whatsoever! Time to fix that...

380
You mean the one in the battle background byte? Yeah I tried it both ways, no effect, it still comes up behind the scenery.

Incidentally, I just tried changing the tileset to the mist cave tileset and using the mist background... that seems to work, the mist comes up in front. Maybe there's something about that tile in particular that draws it in the foreground?

 :edit: Here's a screenshot of young Rydia overlooking the Misty Mountains ^_^

381
Yup, I did that, the problem though is that it's appearing in the background, not overtop like it does in the misty cave...

382
In the mist cave, it seems like it's displaying the mist "background" in the foreground somehow. When I try to do this with a normal map though, it doesn't seem to work. It always displays the background in the background; even if it has the "translucent" flag set. I was hoping to make a "misty moutains" dungeon/area for my hack, and it would be cool to have the mist effect on the mountain...

Any ideas?

383
This wouldn't remember equipment either, would it? Like, if you were to try to implement some kind of dynamic party configuration a-la FF4Advance the character would just get the actor's initial equips replacing whatever it had before, correct?

384
I'm pretty sure at least part of the mystery info in monster arrangements is used in enabling proper cursor movement. As Grimoire has noted before (somewhere... ?), creating monster arrangements from scratch often results in weird cursor movement (it may be difficult to move the finger from the monster in front to the one in back), but if you copy all the mystery bytes/bits from an existing arrangement, that seems to clear it up. If we can confirm this, you'd probably want to take out the option to alter the relevant mystery info and instead have it just change automatically with the arrangement.

So, wait... where are we copying bits from? Where is the monster arrangement information and how is it interpreted? Was this information posted somewhere and I missed it?

385
Yep, looks like these new changes work fantastically! Index changing, the new shields, all of it seemed to work flawlessly. If I may make a suggestion then... is it possible to also include a Copy function as well as a Switch function?

Shouldn't be too difficult. It already has the code there for "highlighting" an index, maybe for "paste" it could just be Insert instead of Enter?

Also, is there any more information you'd like added to the editor that I haven't really explained or explored yet?

Yup, there are a couple things from the wishlist that have yet to be solved. The biggest thing off the top of my head would be getting the tile graphics read dynamically from the rom. I was trying to do this last year and met with mixed success. I can get it to read all the regular tilesets correctly; the only ones that are causing issues are the 4bpp ones (airship, ship). I posted my code in the other thread just to see if anyone could see what I was doing wrong. I can try to pseudocode it down to make it more readable if that would help. In any case, that can be discussed in that thread.

I would also like to make an "arrangement" editor, for editing the monster arrangements (the screen positions of the monsters in a battle, possibly other information related to that?). The wishlist thread on that topic didn't really go anywhere.

There are still several game objects that have "mystery" bits or bytes that we have yet to discover the function of. It's entirely possible that some of them are redundant and actually ignored by the game (the "two-handed" flag comes to mind) but it's also possible that they do have a funciton which we just don't know what it is yet. While working on a test hack (I found this is a good way to test the actual usability/friendliness of the editor for an actual hack) I discovered completely by accident that the spells have a mystery bit (the top bit of the "effect" byte) that was causing a damage spell that had it to deal much less damage than it should. I'm planning on going through all the game objects at some point and making all the "mystery" information editable, if for no other reason than to assist with experimentation.

While not technically part of the editor proper, getting the "complete shadow party" patch working would be such a useful tool for anyone hacking this game, particularly if they're planning on changing the plot in any significant way. That way you wouldn't have to design your plot around the limitation of who can be in the shadow party in what slots at what times.

And finally, on a less technical note, I've been delaying adding the overworld to the map editor, at least in part due to my understanding that it uses at least one multi-tile code (i.e. one of the bytes corresponds to several tiles in a row, f.ex. the snowy mountain tops I think it was). On a technical level this is pretty trivial to implement, but on a user-interface level I've been having problems imagining how to handle the cursor for such a situation.

That's all I can think of off the top of my head but I'll certainly let you know as I think of things  :happy:

What were the minor fixes and cleanups in this update out of curioisyt?

I wouldn't be able to list them systematically... it's just stuff like disappearing or misaligned menu components, labeled a couple more sound effects in the config file, stuff like that.

386
Update time!~~

  • Shield stats now correctly correspond to modified range
  • Certain things can now have their index "swapped", f.ex. weapons, armors, spells, bank 2 messages. Hold shift and press Enter to highlight an entry, press Enter normally on another one, and voila! The entries will change places. This will only affect the information for that object, not things referring to it (so if you swap, say, the Avenger with the Yoichi Arrow, the Yoichi Arrow will now be auto-berserk and the Avenger will be an arrow, and you'll have to go back and manually update the chests etc).
  • Various other minor fixes and cleanups

Enjoy!  :childish:

387
Actually, here it is in the weapon-writing routine:

Code: [Select]
temp = equip_code
if index >= arrow_start and index <= arrow_end then temp += &h40
if index >= bow_start and index < arrow_start then temp += &h80
WriteByte(start + index * 8 + 6, temp)

388
Probably??

Here's all the places where it writes something relating to the bow and arrow ranges:

Code: [Select]
WriteByte(&hC1BE, bow_start)
 WriteByte(&hC1BF, arrow_end)
 WriteByte(&hC246, bow_start - 1)
 WriteByte(&hC27B, bow_start)
 WriteByte(&hC27C, arrow_start - 1)
 WriteByte(&hC286, arrow_start)
 WriteByte(&hC287, arrow_end)
 WriteByte(&hC28C, arrow_start)
 WriteByte(&hC28D, arrow_end)
 WriteByte(&hC297, bow_start)
 WriteByte(&hC298, arrow_start - 1)
 WriteByte(&h19128, bow_start)
 WriteByte(&h19142, bow_start)
 WriteByte(&h1F526, arrow_start)
 WriteByte(&h1F55C, arrow_start)
 WriteByte(&h1A24, arrow_start)

389
Awesome, that seems to work!

Right now I'm just getting it to write the appropriate flags for the shields automatically based on whether its index falls in the defined shield range, but I will certainly make that independently editable soon.

There will be an update in the very near future, with another little surprise thrown in there.  :wink:

390
Yup, now it works!

If you're using a headered ROM just add (or subtract?) 200 to the final amount to find them.

Subtract 20000 and add 200 to get the rom address for a headered rom. E.g. 3F36B would be 1F56B.