When asking for help in understanding an issue, please give relevant information such as any mods you're using, and the stats of the enemy with the issue.
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.
102
New Project Ideas / Re: Final Fantasy Tactics 2 - New project?
July 13, 2015, 11:13:49 pm
Projects often fail because:
1. No implementer. Lots of people have ideas. Not many people can (or rather, are willing to learn how to) implement those ideas. (If you're a programmer in the modern era, and people know this: "I have a good idea for an app, I just need you todo all the actual work code it up.)
Also, different people like different things about this game. I like that stat growth differences are minimal, but one of the first things philsov did was to make stat growth difference much bigger. Without a consistent vision, you're going to have lots of inconsistent ideas thrown in the mix. See https://en.wikipedia.org/wiki/Design_by_committee.
So if your plan is just, "Let's work together with lots of strangers to make a complicated thing," stop now. You might want to start with a list of things YOU like about it. Maybe write out the design principles before you decide to throw in with not-like-minded folks.
1. No implementer. Lots of people have ideas. Not many people can (or rather, are willing to learn how to) implement those ideas. (If you're a programmer in the modern era, and people know this: "I have a good idea for an app, I just need you to
Also, different people like different things about this game. I like that stat growth differences are minimal, but one of the first things philsov did was to make stat growth difference much bigger. Without a consistent vision, you're going to have lots of inconsistent ideas thrown in the mix. See https://en.wikipedia.org/wiki/Design_by_committee.
So if your plan is just, "Let's work together with lots of strangers to make a complicated thing," stop now. You might want to start with a list of things YOU like about it. Maybe write out the design principles before you decide to throw in with not-like-minded folks.
103
Help! / Re: Source code for the event compiler and decompiler?
November 23, 2014, 04:09:59 pmQuote from: nitwit on November 22, 2014, 10:43:52 pmWhat's your experience in reverse engineering?
It doesn't seem very complicated.
104
New Project Ideas / Re: Jobs and Etc. Ideas Proposal Thread
October 29, 2014, 08:26:55 pm
Lancer concept: 100% character evade, no shield, two-handed spears.
Not very concept-compatible with Jump, though.
Not very concept-compatible with Jump, though.
105
PSX FFT Hacking / Re: ASM Hack Proposals
October 24, 2014, 12:00:04 pm
On avoiding player resets as a design principle.
I did, because there are permanent penalties for breaking the law, and I couldn't be arsed to keep track of which ones did what. Some penalties took away stats (which are limited), while others take away items (and I don't think it excludes unique items, let alone ones you can't just buy again).
I also reset on deaths in Rondo of Swords because it halves the stats of an injured character, and I can't recover before the next story battle, where I might need them.
The first example above is about permanent loss of a limited resource (collection-type player). The second is about withholding resources when I (might have) needed them to progress, or to gather more resources, or to prevent more punishment (scared player, or player that thinks they need all the options, or player that doesn't like losing control).
Basically, if you don't want to have the player reset, the time+effort lost for a single reset should be obviously of greater value what the reset will recover in terms of resources. (The "obvious" is important: Decisions are made on what is known, not what is true. It doesn't have to be true, but it does have to be "obviously true".) Meaning, instead of resetting and replaying, you can beat the battle and then spend that time+effort from not resetting to regain at least that much resource. And the value of resources scales up with difficulty.
So if you care about player resets, any punishment you give should either be small, or they should be able to recover in an obvious way that doesn't cost as much time+effort as reaching some part of the battle. For example, recovering injuries by walking back and forth, or paying gil, if gil doesn't feel (back to that "obviously true" again) like a limited resource.
Or you can just forget about caring whether players reset. But there is a way to care about it and still make changes.
Quote from: Elric on October 20, 2014, 03:09:59 am
When playing FFTA (for those wackado people that do so) do people reset every time a unit has to go to jail for breaking a law? I dont see it as much that much different of a concept.
I did, because there are permanent penalties for breaking the law, and I couldn't be arsed to keep track of which ones did what. Some penalties took away stats (which are limited), while others take away items (and I don't think it excludes unique items, let alone ones you can't just buy again).
I also reset on deaths in Rondo of Swords because it halves the stats of an injured character, and I can't recover before the next story battle, where I might need them.
Quote from: JantheX on October 21, 2014, 08:08:29 pm
4. Using the "will someone reset" standard ultimately results in making no changes at all, since any change that is impactful enough to be interesting is also going to be challenging enough to cause at least someone to avoid it.
The first example above is about permanent loss of a limited resource (collection-type player). The second is about withholding resources when I (might have) needed them to progress, or to gather more resources, or to prevent more punishment (scared player, or player that thinks they need all the options, or player that doesn't like losing control).
Basically, if you don't want to have the player reset, the time+effort lost for a single reset should be obviously of greater value what the reset will recover in terms of resources. (The "obvious" is important: Decisions are made on what is known, not what is true. It doesn't have to be true, but it does have to be "obviously true".) Meaning, instead of resetting and replaying, you can beat the battle and then spend that time+effort from not resetting to regain at least that much resource. And the value of resources scales up with difficulty.
So if you care about player resets, any punishment you give should either be small, or they should be able to recover in an obvious way that doesn't cost as much time+effort as reaching some part of the battle. For example, recovering injuries by walking back and forth, or paying gil, if gil doesn't feel (back to that "obviously true" again) like a limited resource.
Or you can just forget about caring whether players reset. But there is a way to care about it and still make changes.
106
Bugs and Suggestions / Re: Javascript prototype for asm tooltips on the wiki
July 27, 2014, 03:24:23 am
I added a page (http://ffhacktics.com/wiki/R3000_instruction_set) for the script to link to, and edited the script as needed.
107
Bugs and Suggestions / Javascript prototype for asm tooltips on the wiki
June 18, 2014, 04:53:11 am
Put into Greasemonkey.
It's a mockup of what can be done: tooltips and links for ASM instructions. Ideally, this would be done through wiki markup instead of Javascript, but this is fine until people figure out what they'd like out of it.
Code Select
// ==UserScript==
// @name FFHwiki ASM helper
// @namespace Raijinili
// @description FFH wiki ASM helper
// @include http://ffhacktics.com/wiki/*
// @version 1.1
// @grant none
// ==/UserScript==
var desc = {
'add': "Add add $d,$s,$t",
'addu': "Add unsigned addu $d,$s,$t",
'sub': "Subtract sub $d,$s,$t",
'subu': "Subtract unsigned subu $d,$s,$t",
'addi': "Add immediate addi $t,$s,C",
'addiu': "Add immediate unsigned addiu $t,$s,C",
'mult': "Multiply mult $s,$t",
'multu': "Multiply unsigned multu $s,$t",
'div': "Divide div $s, $t",
'divu': "Divide unsigned divu $s, $t",
'lw': "Load word lw $t,C($s)",
'lh': "Load halfword lh $t,C($s)",
'lhu': "Load halfword unsigned lhu $t,C($s)",
'lb': "Load byte lb $t,C($s)",
'lbu': "Load byte unsigned lbu $t,C($s)",
'sw': "Store word sw $t,C($s)",
'sh': "Store half sh $t,C($s)",
'sb': "Store byte sb $t,C($s)",
'lui': "Load upper immediate lui $t,C",
'mfhi': "Move from high mfhi $d",
'mflo': "Move from low mflo $d",
'mfcZ': "Move from Control Register mfcZ $t, $d",
'mtcZ': "Move to Control Register mtcZ $t, $d",
'and': "And and $d,$s,$t",
'andi': "And immediate andi $t,$s,C",
'or': "Or or $d,$s,$t",
'ori': "Or immediate ori $t,$s,C",
'xor': "Exclusive or xor $d,$s,$t",
'nor': "Nor nor $d,$s,$t",
'slt': "Set on less than slt $d,$s,$t",
'slti': "Set on less than immediate slti $t,$s,C",
'sll': "Shift left logical immediate sll $d,$t,shamt",
'srl': "Shift right logical immediate srl $d,$t,shamt",
'sra': "Shift right arithmetic immediate sra $d,$t,shamt",
'sllv': "Shift left logical sllv $d,$t,$s",
'srlv': "Shift right logical srlv $d,$t,$s",
'srav': "Shift right arithmetic srav $d,$t,$s",
'beq': "Branch on equal beq $s,$t,C",
'bne': "Branch on not equal bne $s,$t,C",
'j': "Jump j C",
'jr': "Jump register jr $s",
'jal': "Jump and link jal C",
'nop': "No operation (do nothing)",
};
var re = /^([0-9a-f]{8}: [0-9a-f]{8} )(\w+)(\s.*)?$/i;
function tooltipize(i, node){
var txt = node.textContent;
node.textContent = ''; //remove
//make new nodes and add them
txt.split(/\r?\n/)
.forEach(function parse(s){
var match = re.exec(s);
if(match == null){ //no asm detected
node.appendChild(document.createTextNode(s+'\n'));
return;
}
var prefix = document.createTextNode(match[1]);
var instr = match[2];
var suffix = document.createTextNode(match[3]+'\n');
var link = $("<a></a>", {
href: "./R3000_instruction set#"+instr,
title: desc[instr],
}).text(instr);
console.log(prefix, instr, suffix, link);
$(node).append(prefix, link, suffix);
});
}
$('div#mw-content-text pre').map(tooltipize);
It's a mockup of what can be done: tooltips and links for ASM instructions. Ideally, this would be done through wiki markup instead of Javascript, but this is fine until people figure out what they'd like out of it.