Forum Replies Created
-
Posts
-
Quote:we should consider an option to promote wimpy, faceless mooks with random names
I'm a bit late to this party, but RTK9 PC w/PUK allows exactly that to happen – occasionally during a battle, you'll get a notification that a soldier performed exceptionally well, and you get the option to promote them.
DA's second algorithm is actually pretty close to what I was seeing – generals with one good stat and three middling ones.
It did flesh out the game a bit, but things do start to get cluttered if you get too many of them. Maybe it could be an optional thing?
Quote:re: languageI've never been able to get the hang of C (only ever used in one class for college, and the prof was the worst slacker in the room so we never learned much). I've worked with it a little, and anyone who sticks with it has my respect :-) Basic I've done a bit more with, it's not a bad language at all.
Quote:i was going to eventually ask what language ya wrote the doe editor in….It's all in C#. I didn't want to mess with all the winforms stuff, so I used built-in designers to do the heavy lifting there.
Quote:IN ADDTION TO a drop down menu that lets you select the chapter for each set of tiles on screen.I knew I'd left something half-done. I think that'll be the next thing I fix :)
Quote:I was recalling back to that "un-editable" area that is visible but just helps to connect paths/ rivers/obstructions, etc and didnt know if that is still in the plans.This one is actually fairly hard, because it means I have to look up adjoining locations (where applicable). It can still be done, though.
Quote:1. Making the menus similiar to sprite function and being able to type in a letter and it takes you to that letter IE: type Z to go to the first officer with a Z, would make it easier to search for officers.Very easy! It will be done.
Quote:2. Think we could give each battle some kind of generic name?The one thing that makes me hesitate on this one is that people are already rearranging battle locations – and therefore the map, etc, etc. So a "generic" name may only serve to confuse people who move a Luoyang battle to Luo Sang (for example).
Awesome, I was hoping to see more on this project!
Quote:i've got close to 20 years of coding experience… so… i can't imagine there being much in the way of limitations.I would imagine not! I only have a few years of professional experience, but if you need anyone to bounce implementation ideas off of, let me know. An RTK construction kit's been on my mind for some time. :)
A project like this is much, much harder than a tinkering tool like DoaEd, so you have my respect and admiration for taking it on.
If you're targeting so many platforms – what language are you using? My first guess would be Java.
Quote:BTW i saw your 7th saga post. The trick is to make your main char a mage like Esuna, kill the 2nd character since exp is halved with 2 people. Level up on brains/s.brains, revive the dead 2nd character only to recruit another groupie and strip their leveled up equipment off of them since their level is based off of the main character. Some people like Lejes may attack you though if you have runes. So die on Wilme, have him take your runes, recruit lejes, then kill Wilme to get your runes back. <- use winballs to get around towns.Yeah, this would be the way to play the game normally ;) I played as Esuna, with the "difficulty" mod (which wasn't complete), and still ran into problems 'cause I hate grinding.
Money was never a problem, although I'd keep this in mind for future play-throughs.
I wanted to replace Olvan with someone else (probably Kamil), but I couldn't find anyone just before getting the 7th Rune so I was stuck with Olvan for the rest of the game.
Back on-topic…
Portrait/Sprite import is also the path of most resistance for ME, but it seems to be the roughest for others as well. I'd probably only allow import of four-color BMPs, but I could *probably* tweak the import stuff to let people pick their palette for import (e.g. you could import from 'properly' colored images).
In terms of difficulty I expect the following order:
1: (hardest by far) Image import function
2: Battle taunt/location
3: Map warp location display – initially at least I wouldn't have editing.
OK, time for a new number!
Destiny of an Editor v0.97 is released.
This version makes a small fix to the portrait code used during expansion, and adds a new feature – battle editing!
Currently only modifying the officers is supported, but the implementation's pretty flexible. It shouldn't be that hard to add location support… and maybe taunts :)
Note that if you're crazy enough to add NEW battles, they won't be editable. For now it makes the most sense to only support existing battles…
I've got a few directions to go from here:
- Add taunt/location support
- Display Warps on Map (if not edit)
- Add portrait import / loading sprites directly
Any other thoughts?
Quote:No don't do that! In the original DoaE portraits, half are stored on page 2 and half are stored on page 3. It is splitting those at 80. So basically half of Xu Zhu's portrait is on page 2 and half is on page 3. That EOR #$80 is handling that. I'll show you the changes I made to only look at >= F1:Yep, should've realized it was more complicated than that ;)
Thanks for the updated code.
I've updated DoaE to use the new portrait code, and added a new feature. I'll be uploading shortly.
MiDKnighT, I've got a question about the portrait lookup code…
There was a bug since Li Su has a nonzero value in that "unknown" section, but it's less than 0xf1. You said that you'd modify the code to fix it so that byte values less than 0xf1 are ignored, but I don't think you updated the procedure here, so I had to go off of some guesswork:
Code:00:8344:49 80 EOR #$80Means that the following stuff is only executed if it's greater than 0x80, right? Is it sufficient to change this to 0x49 0xf0? If so, I'll go ahead and make this change in the editor.
Ah… interesting. I wondered if that might have any effect.
Lu Su is one of the characters that has that "unknown byte" set to a nonzero value, if I remember right. It helped me find a bug in my portrait bank code.
Try setting his portrait value in DoaEd to 0 and save (yeah – I know it'll display zero, but save anyway).
OK, I've updated DoaEd to v0.96g.
All this does is fix a bug with portrait bank selection (allows you to switch back to 0 properly).
Maybe this could be a feature of DoaEd?
I mean, sure, I'd have to do something tricky to absorb "any" BMP file and make sure it only has 4 colors, but I'm sure it's something that I could pull off if there's the demand for it.
I downloaded it, the ROM's the correct size but it looks like the code to load portraits wasn't added.
At 0x3cfe4, the code is still
Code:10044980e6f1when it should be
Code:4C3083000000. Same with 0x7cfe4.
The other steps haven't been taken yet, either – so while DoaEd thinks it's dealing with an expanded ROM with portrait feature support, and the portraits themselves are in the right spot, the ROM wasn't modified to take advantage of them.
Darn. you posted while I did.
When you re-load the ROM in DoaEd, do they show up as bank 0 or bank N initially?
Did you choose "Yes" to both dialog boxes when you expanded the ROM?
Hm. I tested this, and it looks like there is a bug, but only switching TO bank 0. I don't see any issues switching from bank 0 to 1.
I'll have a re-release once you can confirm the status of the issue.
