gemot encubed  

Go Back   gemot encubed > Gemot > Production & Help

Production & Help For discussions regarding production aspects, especially localisation, of visual novels and related games.

Reply
 
Thread Tools Display Modes
  #16  
Old 2012-02-21, 12:17
jonathanasdf jonathanasdf is offline
Member
 
Join Date: Feb 2012
Posts: 12
Send a message via MSN to jonathanasdf
Default

So that means...
0x0E: if (!(x || y)) return x
will ALWAYS return 0 :\

From 9999.bnr it seems 0x07 is switch, 0x08 is case, 0x09 is default, and 0x0A is break. From what you say there, I guess 0x00 is false and 0x01 is true.
Edit: hm, it seems that if it reaches a statement 0x00 0x00 then it crashes. Also, it seems that the stack defaults to giving a value of 0 if you try to access it and it's empty.

Yes we are planning to change the font eventually.

Quote:
Sorry, haven't got a clue. They may very well be offset labels though.
That's the best theory I've heard so far. Makes sense, since I was trying to call bnr scripts and passing values to the 2nd parameter thinking it might've been an offset into the script, but all that did was crash the game.

Last edited by jonathanasdf; 2012-02-21 at 13:32.
Reply With Quote
  #17  
Old 2012-02-21, 13:44
erengy
Guest
 
Posts: n/a
Default

Oh, you're right, my mistake. Now that I take another look, it's actually like this:

Code:
if (x || y) {
  return 1;
} else {
  return x;
}
Reply With Quote
  #18  
Old 2012-02-21, 21:16
jonathanasdf jonathanasdf is offline
Member
 
Join Date: Feb 2012
Posts: 12
Send a message via MSN to jonathanasdf
Default

So that's just a normal or.

I think that for 0x06 0x01 to 0x07 it's not what you have written there, but rather x = x+y, x = y-x, etc. At least, when I try with

05 03 05 05 03 07 06 01 04 04 06 1E

etc, it gives the error 変数以外に=式は使えません
Which also implies that there's the concept of variables.

for 0x06 0x08 onwards it's right.
Reply With Quote
  #19  
Old 2012-02-22, 12:57
erengy
Guest
 
Posts: n/a
Default

Well, at least one of the parameters is bound to be a variable. Otherwise there would be no point in adding two constant numbers; you would just pass the result directly to the function. Though it is still possible to do so I guess, using 0x06 0x10 instead of 0x06 0x01, for example.

I think I got the function mapping pattern by the way, which turned out to be quite simpler than I imagined. LFScriptFunc.fnc includes function codes between 0x00-0x12: Your "callBnr" is actually "SLoad", "callBnrAndReturn" is "SCall", "alert" is "print", and so on. As for LFScriptFuncEx.fnc, the first one is 0x80, so you just need to add 128 to a function's zero-based index to get its code. The ones you've confirmed so far through 0x83-0xC2 seem to fit this pattern at least:

Spoiler

This also explains your comment on 0x84:
Quote:
This does not seem to be needed to show the text or the backlog, but 0x84 always follows 0x83. It takes 1 parameter, but changing it doesn't seem to affect anything.
0x84 (WaitMessage2) doesn't actually take any parameter, but it's there for whatever reason anyway.
Reply With Quote
  #20  
Old 2012-02-22, 17:42
jonathanasdf jonathanasdf is offline
Member
 
Join Date: Feb 2012
Posts: 12
Send a message via MSN to jonathanasdf
Default

Nice! too bad that doesn't tell us what the parameters do :(
But at least the function names seem logical, so that should aid a lot in determining what the function does. For the tool though I'd like to stick to our names since for the most cases it's more informative.

My interpretations:
Spoiler


And I might as well list down the functions from the script files here then, for simplifying future lookup (this is copied from your previous post).

Actually, 0x83 is SetMessageE and 0x84 is EndMessage, and 0x84 does take 1 parameter.

Spoiler

Last edited by jonathanasdf; 2012-02-22 at 18:55.
Reply With Quote
  #21  
Old 2012-02-22, 19:20
erengy
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by jonathanasdf View Post
Actually, 0x83 is SetMessageE and 0x84 is EndMessage, and 0x84 does take 1 parameter.
Oh, right. Looks like I mixed them up.

Quote:
Originally Posted by jonathanasdf View Post
Nice! too bad that doesn't tell us what the parameters do :(
Haha, that would be great, wouldn't it. What we have here though, is more than one could hope for. I wonder if the game still runs without the .fnc files... Nah, it doesn't. Tried it now, threw out a couple of errors and crashed.

Mapping function codes with their names was actually the last distinct objective I had in mind, but now that I think about it, there are these parameter types. We already know about type3 (int32), type4 (float) and type5 (string index). For the remaining ones, here are all the examples:

type6:
Spoiler

type7:
Spoiler

I think type6 is either signed integer (assuming type3 is unsigned) as WN() can take -1 to clear the speaker tag, or an indicator that the value can be type3 or type5. Second one sounds more likely.

As for type7, we know that second parameter of SetMessageE() is some incremental number. One thing that comes to mind is it could be some kind of index, a variable index perhaps. It could be for keeping track of which lines are read and which of them or not, and to keep them in save files. We may be able to test this theory by changing some values and checking if it breaks line skipping.

As you can see, assuming that my interpretation was correct, some parameters have default values. The default value for SEP()'s volume parameter is 0xFF, for instance. But how are they used? I think either all the functions in .bnr files have their proper arguments, or there is some other opcode we're currently unaware of to push the default argument onto stack.
Reply With Quote
  #22  
Old 2012-02-22, 19:50
jonathanasdf jonathanasdf is offline
Member
 
Join Date: Feb 2012
Posts: 12
Send a message via MSN to jonathanasdf
Default

My theory is that type6 means anything, because print can take a float as well.
Your idea about line skipping is interesting, maybe 0x84 has to do with that?
Reply With Quote