Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#51 2015-11-05 15:29:26

Miksy91
Member
Registered: 2010-10-16
Post 2,205/2,339

Re: Pokemon G/S Flags

With PKSV and Johtomap, you write values in Big Endian - in other words, human friendly way. 0x0001 is represented as 00 01, and for example 0x2A56 as 2A 56. Little endian is the format where bytes are the other way around.

Most data you write you have to write in little endian - such as pointers. Pointer "44 72" in rom address 0x10510 (= 04:4510 (which means rom bank 4 and address 4510 in that bank)) points to 0x13244 (= 04:7244) while in big endian, you would just write 72 44 (--> 04:7244) which is the way the address is shown as pretty much.

But yeah - with hex editor, you'll write most data in little endian. So "33 48 38" is the same as "checkbit1 0x3848" where 0x3848 is the natural way of showing the value. And same goes for all kinds of other data as well.

In little endian, the addresses work so that after 48 38 comes 49 38, then 4A 38, ..., FF 38, 00 39, and so on. This is "natural" because the bytes are in other way around.

You don't have to disable NPC trades if you use these flags. :)

Offline

#52 2015-11-05 15:44:27

Mateo
Member
From: The Sims 4
Registered: 2009-11-25
Post 3,161/3,578

Re: Pokemon G/S Flags

Yeah, it's only linking with another actual game that causes corruption, in-game trades are fine.

Offline

#53 2015-11-08 05:03:46

Skurbert
Member
Registered: 2012-12-16
Post 90/95

Re: Pokemon G/S Flags

Thanks. Everything seems very clear to me now. But there's one thing I still can't get my head around.

How do I point to one specific bit? I mean, you explained that there are 8 bits in one address. Right? To point to them there, then something like this would seem logical to me:

[33] [48] [38] [01]

[Script commando] [little endian flag address in WRAM] AND [the first byte in address 0x3848]. I'm only guessing (yes, I know you should NEVER guess in mathematics), but it seems very logical, because I guess you would have to instruct the game to point to that specific bit.

I'm asking, cause it seems strange to use 8 trainers with the same [48] [38] pointer. It doesn't feel right.

Offline

#54 2015-11-08 09:11:21

Miksy91
Member
Registered: 2010-10-16
Post 2,206/2,339

Re: Pokemon G/S Flags

48 38 here is not a 2-byte pointer to an byte address you're used to. But it is still a pointer in the real meaning of the word since it points somewhere where we look for data.
But perhaps a better word for describing "48 38" here would be an index in a table consisting of bits.

Since the bit table is stored in ram starting at byte address D7B7 and we have 65536 (0x0000 - 0xFFFF) flags (or indexes) to use, we can point to 65536 different bits starting at D7B7. That also means that we can point to bits in bytes until D7B7 + (65536 / 8) - 1 (because 8 bits form a single byte). That -1 in the end comes just from the fact that 8 first indexes (00 00 to 07 00 in little endian format) just point to bits in same byte address, D7B7.

So yeah - what you want to do is to give an individual flag for each event. And if you want to start with flag 48 38 (which points to the first bit in byte address DEC0), the second one to use could logically be 49 38 (for pointing to second bit in DEC0) and so on. And to make sure your flags really point to address space starting at DEC0, keep the Memory Viewer opened when some bits are set or reset.

Last edited by Miksy91 (2015-11-08 09:15:52)

Offline

#55 2015-11-08 13:37:07

Skurbert
Member
Registered: 2012-12-16
Post 91/95

Re: Pokemon G/S Flags

Okay, I got it! It's hard to describe I guess, but it makes very much sense. So I would be right to say that the [33] command is VERY important to use in this case, to sort of "guide" the engine which WRAM address (DEC0) to load/store stuff? The D7B7 is a start of a table with bytes that can be used to store flags. DEC0 is part of that table/index. [33] is a command to tell the engine to use that table for storage. Right?

Offline

#56 2015-11-08 14:57:29

Mateo
Member
From: The Sims 4
Registered: 2009-11-25
Post 3,163/3,578

Re: Pokemon G/S Flags

Yes. 33 is a function (setbit1) that tells the script engine "Go to this array of bits, and set whichever entry in that array I told you to". The 2 bytes after the 33 are the arguments for that function. So [33] [0000] Tells it "Go to the array this function uses, and set the 0th bit".

Ordinarily, DEC0 is out of range, since it is past the end of the actual array. You can't just use bits right after the original end of the array, since other data is already there. BUT by using the extra high numbers Miksy mentioned, we can tell it to read past the original array, past the other data, and end up in a usable area of ram. It's just like how C++ doesn't stop you from having an array with 3 entries and trying to store something to the 34th entry in that array if you really want to, even though the results will be unpredictable if you don't know what is going to be there so it's a bad idea there. That's why Miksy mentioned the formula, so you could figure out how a bit number translates into a RAM address, to make sure the one you want to use won't overwrite anything you don't want it to.

So what Miksy is telling you to do right here is to use, for example, [33] [4838]. That will tell it to set the x3848th bit in that array (because the bytes are swapped when entering them in hex, like was said earlier) and the function you called figures out the ram address for that bit on its own.

Offline

#57 2015-11-22 22:53:56

Skurbert
Member
Registered: 2012-12-16
Post 92/95

Re: Pokemon G/S Flags

OK. I still must be doing something wrong. Hidden Item scripts gives me teru-sama's, trainer scripts gets completely messed up and battle glitch-up and Memory Viewer shows absolutely nothing except 00 00's. But I did what you said and added [33] in front of the BitNr. Why won't it work??

Offline

#58 2015-11-23 21:22:20

Miksy91
Member
Registered: 2010-10-16
Post 2,209/2,339

Re: Pokemon G/S Flags

Skurbert wrote:

OK. I still must be doing something wrong. Hidden Item scripts gives me teru-sama's, trainer scripts gets completely messed up and battle glitch-up and Memory Viewer shows absolutely nothing except 00 00's. But I did what you said and added [33] in front of the BitNr. Why won't it work??

Check the [Color | Function] byte of each of those events that you have problems with.
http://hax.iimarck.us/files/scriptingco … ventaufbau

You can see it with Johtomap so that it shows the first four bits as "Palette" and the remaining four bits as "Type". Type of normal (person) event should be '0', the same for item '1' and for trainers '2' like explained under [Color | Function] there in Scripting Compendium.

What this type, or function part here does is basically for telling the game, how the data should be treated that is found at the address where the script pointer points to. For instance, if you make an item 'Potion', its data will be 12 01. If you approach it in the game, and it is given Type (or Function) '2', the game will instead execute normal script data and first execute scripting command 12 with 01 and the next two following bytes as parameters. And after that, keep executing the next bytes as script data and so on...

12 Activate trigger event from afar:                                          Top
------------------------------------
 
Changes trigger event number on map (map bank/map no) to xx.
 
xx = trigger event number that should be activated
 
Structure:
 
[12][MapBank][MapNo][xx]]

So make sure the Type of your events is right :)


P.S
You'll have to do basically the same thing for signposts (includes hidden items) too; make sure they also have the right function value before approaching them. The functions for signposts are also documented there in Scripting Compendium (and actually at the same place which I linked you there).

Also, Johtomap may change the Function byte of a signpost to 00 (= normal event when "talked to") when you edit it. So if you run into bugs with hidden items (or other kinds of signpost events) after modifying them, check with a hex editor that its function byte is not 00.

Last edited by Miksy91 (2015-11-23 21:26:23)

Offline

#59 2015-11-24 13:15:41

Skurbert
Member
Registered: 2012-12-16
Post 93/95

Re: Pokemon G/S Flags

The function byte is actually correctly set, I always check them in GoldMap. There must be something else...

This is my script atm (They always seem to be 3x 2-byters:

[DE][C7][3E - (PP UP)]. Function byte is set. Works perfectly. But flag cannot be used.

Then I tried this one (because we had to use the spare flags we talked about earlier, etc.):

[33] [48] [38] [3E - (PP UP)]

Didn't work. Gave me Teru-Sama.

I suppose it should look something like this instead?

[12] [3E - (PP UP)] [33] [48] [38]

Trainer scripts always seem to start with the flag number. Trying to insert [33] in front of the flag number seem to corrupt the entire event.

There are also people events giving items. There's absolutely no way to repoint these events, because they are so crammed, etc. These were a complete pain to write in hex so I don't want to redo them. There must be some other flags I could use for these events without using [33] command. Any clues?

I mean, here's the situation: I've added around ~100 trainers, ~50 new items, ~10 new flagged events, everything works perfectly, except their flags are incorrect, which I figured out the hard way when you told me about how the game store stuff in WRAM. This leaves me stranded with hundreds of working script with incorrect flags that has to be corrected. I think I got confused when you told me much earlier that you could have 65 536 flags (256x256), so I thought "well, great!" and just used random flags that were not on the list. Then I came back to earth and realized I had been doing it wrong.. AGAIN! :-)

Last edited by Skurbert (2015-11-24 13:28:09)

Offline

#60 2015-11-24 21:53:46

Miksy91
Member
Registered: 2010-10-16
Post 2,210/2,339

Re: Pokemon G/S Flags

Sounds like you have some problems figuring out, how different events work but that's okay :)

For example, for hidden items, you want the Function byte of the signpost event be set to 07 and the script pointer point to structure "[Bit-Nr. (2byte)][Item no.]" like explained in the compendium. So for setting the first bit in DEC0, write "48 38 xx" in the address where script pointer points to (where xx is the item given).

For people events (, trigger events or normal signpost events) to set different bits, you'll have to include "33 [Bit-Nr. (2byte)]" in their script data. Making sure this works can be easily achieved with writing scripts with pksv instead of a hex editor.

Also if a person event has a bit number for making it being displayed or not (this is generally 'FF FF' for person events that are always shown on map), the person event will be shown if the bit number "points" to 0 bit and hidden if it points to 1 bit.
What more comes to this is that if the flag (or Bit Nr.) of a person event is also affected with disappear and show commands (= scripting commands 6D and 6E) the same way as what would happen when you set or clear their bits with scripting codes 33 and 32. So when you make an event disappear (with code 6D), scripting code 33 is also executed for the Bit Nr., that is given as the Bit. Nr. (or flag) associated with the person event that is made to disappear, for setting the bit value to 1. And same way for showing a person event - if you show an event, "its bit" is cleared or set 0.


Trainers and items have different kinds of script data structures. An item event is given its bit number in person event data (= in place of that 'FF FF' I just mentioned), and "its bit" is set to 1 when the item is hidden (= just like script code 6D functions when you hide any person event on a map). 'FF FF' is probably a general value which doesn't refer to any bit in ram (so practically there are "only" 65535 instead of 65536 flags to use), so if you make an item (or any other event) hidden that has 'FF FF' as its Bit Nr., the event will be shown on the same map when you enter it again. But if the item (or any event) has a different Bit Nr. it won't be shown because its Bit Nr. now refers to a bit in ram that has its value set to 1.


Trainer events have the following script data structure:

[Bit no. (2byte)][Trainer group][Trainer][2byte pointer to Text when seen][2byte pointer to text when trainer beaten][2byte pointer to script when lost (0000=Blackout)][2byte pointer to script if won/talked to again]

As you can see, if you want to make your own trainer, make sure the first two bytes of it refer to a bit in ram area starting at DEC0. Here '48 38' would refer to first bit in DEC0.

Last edited by Miksy91 (2015-11-24 22:05:57)

Offline

#61 2015-11-27 19:33:10

Skurbert
Member
Registered: 2012-12-16
Post 94/95

Re: Pokemon G/S Flags

I spent the entire Thursday and Friday fixing all of the event, trainers, hidden items, etc. giving them new flags, checking the memory viewer, making sure they run correctly, etc. And it works like a charm!

Thanks yet again for helping me out at my most difficult moment!!

On a side note, I didn't have to repoint the NPC-give-item events. In fact, they already had a 33/31 commando, although I had completely forgot about that, until recently when I checked it.

Btw... has anyone figured out how that script on Cianwood City works? I'm talking about the NPC giving you HM Fly when you have defeated the Gym. It points directly to a 52/51 command, but the pointer points to crap (some crap dialogue out of nowhere not tied to the script at all). I really tried to reverse-engineer it by checking the script, but it makes absolutely no sense. It's just a small thing (I'm trying to repoint Cianwood City). Just curious if anyone else been checking it out. Same with the "teacher" script, it point "wrong", but still works.

Offline

#62 2015-11-27 20:38:33

Mateo
Member
From: The Sims 4
Registered: 2009-11-25
Post 3,193/3,578

Re: Pokemon G/S Flags

You are mistaken. This is the script for the woman who gives Fly.

If you saw a script which pointed to a 51 or 52, it was not the right person. There is another girl in Cianwood, who DOES use a 51 command, and she just says a line about Chuck sparring with his Pokémon.


Also, I'm curious as to why you insist on using Hex instead of PKSV for scripting. I know I was once that way, but I had already been scripting in hex for years before PKSV came out and I didn't trust it at first. But once I saw that it compiled correctly and such (with the exception a seldom-used phonecall command) and saw much simpler it made my life because it could use labels instead of manually finding pointers to everything, I didn't go back. I'm just curious what your reasoning is behind doing it the "hard" way when you don't have to.

Last edited by Mateo (2015-11-27 20:48:06)

Offline

#63 2015-11-27 22:44:56

Skurbert
Member
Registered: 2012-12-16
Post 95/95

Re: Pokemon G/S Flags

Ah, yes!  That makes very much sense. I think I moved them around in the editor and picked the wrong one. I'm gonna look into that and see what I can do!

The main reason I don't use PKSV, is that I pretty much wanna have absolute control in what I edit. I'm more used to "The Gold Finger Way". Another thing is the bad first impressions I had with it - PKSV was actually the first thing I tried use for scripting, if you look at my other thread, you can see how I complained about how the scripts didn't work, or showed up correctly, how it changed my Rom from 2 mb to 200 mb, how some of the scripts were erased or just refused to save, etc, all the things you just mentioned, how it didn't compile things the right way (OR not knowing HOW to compile things the right way, I should rephrase it?). It seems very unpredictable.

I'm just scared of it, you know? :P

When I write something in Hex, I know every single byte is gonna stay there until I change it. This is also why I'm very careful when using JohtoMap and other brilliant utilities like One GSC trainer, because there have been instances of important data being overwritten, ruining my Rom. JohtoMap is good at repointing, though, while GoldMap never repoints anything, instead just overflowing the new scripts onto the other. And it mostly can't be discovered until very late, when I test that particular part of a map (and then have to go back to a much earlier backup). If I could use hex all of the time, I would use it!

Just the thought of inserting new graphics in the rom and it overwriting a lots of important stuff gives me nightmares!

In the future, however, I might have no choice but to use PKSV, since more advanced scripting gets more painstakingly in Hex, like you mentioned, "the hard way". I'm just a newb atm, I need more practice, trying to understand all of these hex commands and what they do, etc. And I also feel like I'm learning faster when doing it in hex, bc I repeat the commands and... yeah. PKSV just gives me the creeps.

I hope this got my point across, maybe I've written a bit too much. Hmm.

Offline

#64 2015-11-28 18:33:11

Miksy91
Member
Registered: 2010-10-16
Post 2,211/2,339

Re: Pokemon G/S Flags

Skurbert wrote:

Ah, yes!  That makes very much sense. I think I moved them around in the editor and picked the wrong one. I'm gonna look into that and see what I can do!

The main reason I don't use PKSV, is that I pretty much wanna have absolute control in what I edit. I'm more used to "The Gold Finger Way". Another thing is the bad first impressions I had with it - PKSV was actually the first thing I tried use for scripting, if you look at my other thread, you can see how I complained about how the scripts didn't work, or showed up correctly, how it changed my Rom from 2 mb to 200 mb, how some of the scripts were erased or just refused to save, etc, all the things you just mentioned, how it didn't compile things the right way (OR not knowing HOW to compile things the right way, I should rephrase it?). It seems very unpredictable.

I'm just scared of it, you know? :P

When I write something in Hex, I know every single byte is gonna stay there until I change it. This is also why I'm very careful when using JohtoMap and other brilliant utilities like One GSC trainer, because there have been instances of important data being overwritten, ruining my Rom. JohtoMap is good at repointing, though, while GoldMap never repoints anything, instead just overflowing the new scripts onto the other. And it mostly can't be discovered until very late, when I test that particular part of a map (and then have to go back to a much earlier backup). If I could use hex all of the time, I would use it!

Just the thought of inserting new graphics in the rom and it overwriting a lots of important stuff gives me nightmares!

In the future, however, I might have no choice but to use PKSV, since more advanced scripting gets more painstakingly in Hex, like you mentioned, "the hard way". I'm just a newb atm, I need more practice, trying to understand all of these hex commands and what they do, etc. And I also feel like I'm learning faster when doing it in hex, bc I repeat the commands and... yeah. PKSV just gives me the creeps.

I hope this got my point across, maybe I've written a bit too much. Hmm.

After you have gotten the hang of scripting with a hex editor, you should try pksv though :)
Make lots of backups from your rom file often so if you happen to mess up, you can always return to a backup that is very recent (and you would have to redo 30minutes of work at max). I have around 1000 backups in my pc of DE ;) 2MB files are these days really small, so today, keeping even hundreds of backups in computer of files of that size is no big deal.

I believe the reason why your rom file accidentally turned out 200MB is because pksv works so that whichever address you tell it to write to (marked with #org "address"), it will write to. If the address is higher than the rom size, it fill resize the rom file and probably put 0 bits in between (so your rom file could have turned:
"2MB of original data + 198MB of 00 00 00... + some script data in the end"

I used to mess up myself earlier too and had a pokemon gold rom file that was over 100MB I think.

But what comes to compiling code, there is no reason to worry when using it. How it works is that in case you make a typo, it won't compile at all and will tell you to fix the typo before it can compile. And once you have done that, it will do exactly what you have written in the script. One thing that is a bit dangerous with it though is that it will write exactly what you have written in the script code even though it would at the same time overwrite some important data which happens to be located in the rom file where the script is at.

What I do myself is to reserve lots of space for big, new scripts I write. For example the long event in Milky Village in DE which occurs when you enter the village (in case you have played the hack and know what I'm referring to) is done so that I believe I have around 200 bytes of script code starting at the same address and once I had decided to put the script there, I probably left over 300 bytes of free space starting at that address so I don't have to worry about using call and jump codes to slice the script in pieces because of otherwise overwriting other useful data.

Anyway - once you have gotten the hang of scripting, you usually have a pretty good idea before writing scripts, which commands you need to write the script and in what order, and that way, can figure out, how many bytes your script will need approximately. That way you don't have to reserve lots of space in the middle of a rom bank for no good reason. I personally don't like leaving lots of unused space between different kinds of data I write but that's just me. Sometimes I regret it that I don't leave though...


All in all - pksv could have been done better and using it is not stable. But you shouldn't run into any problems once you learn how to use it first.

Last edited by Miksy91 (2015-11-28 18:35:33)

Offline

#65 2018-01-28 22:52:34

Halfshadow
Member
From: Italy - Lucca
Registered: 2012-04-24
Post 224/283

Re: Pokemon G/S Flags

I need of a temporary Crystal flag to fix the Teleport bug to another area and continue the script with message texts, I splitted the script that continue in the teleported area, only if you talk with the old man that before the edit continued to talk without use flags. This was safe in G/S, but created a bug with the location alert graphic in Crystal, then I splitted the script that continue only if you talk with the old man, I used the FFFF flag, if I save the game and close and reopen the emulator isn't recorded, but isn't cleared if I leave the room. Is already used by something else in Crystal the FFFF flag? And is safe use it or could create other bugs?

-EDIT- Ok, isn't important longer, I did a fix in the PWETER CITY map to clear it when I esc from the museum, I use it only when I come back from restored Pokémon mansion in the museum.

Last edited by Halfshadow (2018-01-29 00:45:01)


The italian Pokémon Green creator.

Offline

#66 2018-01-30 14:54:10

Miksy91
Member
Registered: 2010-10-16
Post 2,320/2,339

Re: Pokemon G/S Flags

Halfshadow wrote:

Is already used by something else in Crystal the FFFF flag?

I think FF FF is a special flag / bit number in such way that setting it doesn't write anything in the ram. So if you for example give that flag to an item ball, and take the item, the item will re-appear on the map next time you enter it. Also I think that most person events use flag FF FF, so if it did write something, you wouldn't find people "anywhere".

Also unrelated to the problem, but flags between 0x0 and 0x7 (0000 and 0700 in little endian 16-bit format) are special so that they are automatically reset once you enter a map. Thus these can be used for events that you would "normally" want to re-occur everytime you enter that map, but that would not occur once you have done them on the map once. These are also handy for flags for person events that should/should not be hidden when you enter the map based on certain circumstances. You could basically load a script from map's script header that either hides these person events or not based on state of a different bit number (or set of bit numbers) for instance.

(Ok, just noticed that this was pretty bad english, but won't bother trying to fix the grammar. You'll probably understand anyway :) )

Last edited by Miksy91 (2018-01-30 15:01:12)

Offline

#67 2018-02-04 22:31:30

Halfshadow
Member
From: Italy - Lucca
Registered: 2012-04-24
Post 225/283

Re: Pokemon G/S Flags

Don't worry for your english, is fine. Thank you. :)


The italian Pokémon Green creator.

Offline

Board footer

Powered by FluxBB