iainuki
Find My Content
Reputation: 0
Neutral
- Group:
- Member
- Active Posts:
- 7 (0.06 per day)
- Joined:
- 25-December 16
- Profile Views:
- 0
- Last Active:
- 17 February 2017
- Currently:
- Offline
My Information
- Member Title:
- Novice
- Age:
- Age Unknown
- Birthday:
- Birthday Unknown
- Gender:
-
Not Telling
Contact Information
- E-mail:
- Private
Posts I've Made
-
In Topic: First order of business!
13 February 2017 - 05:46 PM
zombero, on 12 February 2017 - 06:21 PM, said:Well, I suppose I fibbed a bit, since the real first order of business is getting my development environment up to date! I've finished the first of two major parts of this process (the larger of the two parts) so it shouldn't be long to finish the remainder.
What are you doing to update it? -
In Topic: Some Questions about Coding
23 January 2017 - 01:53 PM
I've been doing some more research. Apparently, some of the Windows-only tools do work under Wine, so I may end up trying some of them as I start to narrow down what changes I feel are needed outside the data tables.
- Does your hack use an expanded rom? (I'm assuming it has to, from how much you've added, but I thought I'd verify.) Is it at all practical to make changes to the code in a non-expanded rom?
- Do you know where the code that determines experience gained for kills lives? At the moment, the sheer amount of experience available with the quantities of units you find in later stages (with 24+ enemy units) is a balance problem, and increasing the numbers of units in the early stages makes them harder but the midgame easier. I've also been toying around with lowering the effective level cap on experience gain (4 levels above is where experience gain drops to 1) to limit the super-unit strategy.
- VerySneaky's rom map has 1F8FF listed as the location for the damage coefficient by terrain table, but there are only 100 bytes, so I'm not sure how that maps to actual damage modifiers given there are 10 movement types and 20 terrain types. Is that what this table does? If so, how is it laid out?
- They have some discussion of city events (pointers to pointers start at 384AE), but not enough information about the events so that I could change anything about the items that events give, or e.g. move an event from one city to another, or across stages.
- Do you know anything about how the code for determining enemy unit drops works?
- Does your hack use an expanded rom? (I'm assuming it has to, from how much you've added, but I thought I'd verify.) Is it at all practical to make changes to the code in a non-expanded rom?
-
In Topic: Some Questions about Coding
09 January 2017 - 02:03 PM
zombero, on 07 January 2017 - 01:28 PM, said:Heh, no worries, there's not much to distract from at the moment since I'm still finishing up my other mod. Geiger's Debugger is what I use, and to my knowledge it has no real competition.
Unfortunately, it looks like you're right about Geiger's debugger: it's not available for Linux, and there doesn't seem to be anything equivalent that is
. Ugh, that is going to make things much more difficult, verging on impossible, for creating new code.
zombero, on 07 January 2017 - 01:28 PM, said:Unless you plan to re-assemble the entire game, any injected code is going to be at least a certain degree of messy and entangled. But there's also things like if I change the data structure of an enemy formation or a character palette, then new features that interact with those couldn't simply be extracted and applied to the original game.
Yeah. I'm thinking at this point that any changes I make will be in a series of discrete patches that some other tool will generate and apply, but with interdependent changes, that patch could get to be large.
zombero, on 07 January 2017 - 01:28 PM, said:Sorry, I can give info about the original game, but I don't really want to share information that would aid in extracting added features from a hack that isn't even released yet.
That's your prerogative.gif)
. I admit, I'm a bit disappointed that SNES modding has so much closed-source software. (I write and use a lot of open-source software for other purposes than editing SNES games.)
On the topic of the original game, after playing around with unit design some, I think that only being able to use three classes in enemy units is workable from the perspective of being able to build units that are threatening enough to the player. The palette issues remain, but I'm going to ignore them for the moment. The bigger issue is proving to be the formations, particularly that there's literally one formation that allows two different big classes, both of which have to be in front. Finshore's text rom map mentions that "group formations" are at 2e83d unheadered, and there are exactly 19 7-byte blocks before the next entry in the table, so I think that's them. Do you know what what the 7 bytes mean? Any nonobvious problems I'm going to run into from changing them if I make sure to edit all the units that use the formations I change so they're still valid? -
In Topic: Some Questions about Coding
07 January 2017 - 10:48 AM
zombero, on 01 January 2017 - 06:26 PM, said:Here's his website:
http://www.verve-fan....php?board=10.0
Though, at a glance, I didn't see the spreadsheet-based program listed there, so it may not be there... in which case I don't know what happened to it.
I found this thread where MrVimes complains about being unable to create his mod because his hex editor is inserting rather than overwriting. His one post on the site you linked occurs after that date, though.
It's pretty much immaterial at this point since I've reimplemented a script that takes information formatted as CSVs and converts it to data in the rom. The only thing I could get from it would be information on the parts of the rom that I don't currently have a map for.
zombero, on 01 January 2017 - 06:26 PM, said:I have movement behavior as being read from a 7x7 table at $2990A (unheadered)
But that's really about all I know about it.
Thanks! That's helpful, since that falls into a big gap in Finshore's text rom map:
Quote
25dAD avatar subpalletes
2d173 stage clear goal 2byte entries
2D9A2 starts enemy group data with Castle of Warren
zombero, on 01 January 2017 - 06:26 PM, said:From what I recall, the palette result is entirely predictable. One of the two minion groups always gets overridden and it's always the same group. So, you can judge which palette swaps look passable and which do not.
My testing so far indicates it's deterministic.
zombero, on 01 January 2017 - 06:26 PM, said:This is Finshore's website: http://www.freewebs.com/finnshore/
If he hasn't posted the palette patch there, then there's probably a reason for it... but you could try asking him anyway. Since I wrote stuff in hex, I don't really have "code" to share, the code is what's in the ROM. But it's typically changes built upon changes built upon changes... individual features are not easily extract from it onto the base game. And the palette swapping one, in particular, is a beast.
I did ask him, but didn't receive a response so far. (I'm not surprised, as you said, he probably doesn't want to post it or otherwise he would have.) I'm taking a more structured approach than you are, I guess, which is why I was surprised your changes are so hard to disentangle. I understand, though. If you have a map to your changes or notes on them, even, that would be useful.
Have you ever used a disassembler for the SNES, and if so, do you have any recommendations for one? Asar says that it runs on Linux, so if I need to do actual programming (which I admit I'm hoping to avoid), I will probably use it.
Do you have any suggestions on advertising a mod or getting beta testers? Once I get it more finished, I'm going to put the code up on Github, but I don't want to distract from the purpose of your board, for your mod, any more than I already have. Thanks for answering my questions.
-
In Topic: Some Questions about Coding
30 December 2016 - 07:21 AM
zombero, on 28 December 2016 - 08:39 AM, said:You could try looking into Mr. Vimes' spreadsheet-based editor, as well. I don't know whether or not that editor was platform-specific.
Where would I find that? I did some looking with Google but failed. My Python script is probably going to use csvs, though currently I'm using JSON.
zombero, on 28 December 2016 - 08:39 AM, said:For enemy formations, the 9th and 10th bytes are both related to map movement. As I recall, the 9th byte is comparised of two 4-bit values which are the IDs of a set of map movement behavior. Each behavior set contains 5 behaviors, and the 10th byte relates to how aggressively the enemy will escalate from one behavior to the next (it doesn't ever backtrack through them). As to which behavior set is used, some of them are conditional (such as the whether the player controls at least one town), this is specific to each behavior set. I didn't get into figuring out what each individual behavior does, and it was often difficult to discern even in the few cases where I tried. I ultimately just scrapped this whole system and created my own behaviors, as I deemed it rather unusable.
You haven't posted your new behavior yet, have you? If you have any information on how the original movement behavior works, like where those bytes are read or where the routines are, I could take a look myself.
zombero, on 28 December 2016 - 08:39 AM, said:As to how many unit types you can put in an enemy squad: not only are you hard-limited to 3 types, but the game designers limited themselves to ensuring that all of an enemy squad's minions share the same palette, which is abysmally limiting. If you do not limit your designs in the same way, then you will get erroneous palette swaps when you meet those enemies in battle. This doesn't affect gameplay, and sometimes looks cool, but it's also confusing since there are already class palette swaps in the game, and sometimes looks terrible. No one has come up with a zero-loss work around for this issue. The SNES is limited to 8 foreground palettes at once, and 5 of these are reserved for the player, 2 for the enemy, and 1 for battlefield effects. FinS made a patch (though I don't recall if he ever posted it for use) that degrades enemy palettes a bit in order to have a 3rd enemy palette. My hack takes the approach of consolidating palettes such that the bug will only occur if there are actually 8 distinct character palettes at play in the field, thereby massively reducing the prevalence of it, and allowing the player to choose to avoid it by ensuring each of their squads has only 4 distinct palettes, if they so choose. And even with that, I still have to limit myself to 3 enemy palettes. But yeah, it's just a fact of life when it comes to hacking this game that you can't have enemy squads that are diversified to the same degree as player squads without running into problems.
That is abysmally limiting and goes a long way to explaining why the later parts of the game are so easy. I don't think they chose a good compromise between aesthetics and gameplay here, to have sacrificed one so much for the other. Okay, so, given that I would make a different choice, how bad are the aesthetics of palette swaps, and is there any easy way to predict which combinations will look terrible? Do you think writing to Finshore could get his patch? Would you be willing to share your code?
Comments
iainuki has no profile comments yet. Why not say hello?