tommai78101 / pokemonwalking Goto Github PK

Area Map Files need a bit more clarification on:

• How the data format is structured.
• What is the algorithm used to read/write data in the custom data format.
• How extensible is the custom data format.
• Whether to use a custom file format descriptor (.AMF file format?) and store them as PNG files...

This needs to be fixed.

Pressing F1 will throw an error. Need to fix this.

Redesign the Script Editor UI, so that only:

• 1. Level Editor can save and load both map area and script files.
• 2. Level Editor determines where to save/load the map area and script files from.
• 3. Level Editor should allow the user to save/load the map area from the official "area" directory, official "script" directory, or the all-in-one "mod" directory.
• 4. If the user chooses a directory not from these 3 places, both the map area and the script files will be saved together.
• 5. If the user chooses the "area" directory or "script" directory, then the map area will be saved to the "area" directory, and scripts to the "script" directory.
• 6. If the user chooses the "mod" directory, the map area will be saved to the "mod/area" directory, the script files will be saved in the "mod/script" directory.
• 7. When loading an area file or a script file, use the checksum to determine where the required files are at, from these places.
• 8. If no required files were detected, do not attempt to continue loading the level editor session. Throw some dialog messages or something to warn the user.

Steps to reproduce:

1. Open an area map that is known to contain trigger data in the level editor.
2. In the level editor, click on Triggers button to switch to the Triggers layer view.
3. Observe how there aren't any trigger datas marked on the area map.

The expected result should be trigger data markers showing up in the level editor.

In Pokemon Red/Blue/Yellow/Green, in Team Rocket's Hideout, there are warp points that can warp the player to different locations within the same area.

Game must:

• Give a better name, if possible.
• Animate the player warping (beam of light or the player flying upwards while spinning around)
• Be able to warp the player to a different location in the same area.
• Fade in/Fade out transition during the warp sequence.
• If warp point destination location is occupied with another warp point, offset the warp point destination location by 1 tile away from the occupied warp point tile. Should be on a vacant, walkable tile.

Level Editor must:

• Use a new tile format to support this warp point.
• Define a new pixel data format.
• Provide different art assets for man-made warp points (Team Rocket's Hideout, Lavendar Town warp points) and natural warp points (Ilex Forest, Deoxy Triangle).

Documentation must:

• Add information about this new warp tile.

The editor needs a mouse selection tool.

When setting multiple triggers on the same tile, multiple issues occur.

• Trigger data value doesn't contain proper (X, Y) coordinates.
• All trigger data values are the same for 1 type of trigger.

This error can be inspected by viewing the editor's source code, and inspect the DrawingBoard.getMapImage() method.

Probably lacking some obstacle ticks to prevent the player from continuously interacting with them.

Now that we have TDIC implemented, we should start utilizing the TDIC to streamline the ability to load scripts when the level area is opened in the level editor.

The current issue with opening existing levels to iterate on new changes, map fixes, and other tweaks, is that the level editor doesn't have any knowledge of any trigger data the old level area files used.

We may need to expand and store additional data into the level area files, so that when opening them, we can load more information.

The whole level editor's metadata storage system is flawed from the beginning, and it is not useable if we cannot re-open pre-existing area maps. It is also not as intuitive when knowing the fact we need to open an old trigger session first, before attempting to load an old map.

Ideally, both the trigger data and the level area data should all be in the same file, so when opening the file, we can restore everything that was saved to said file.

Convert scripts (or ditch the current custom script format) to proper JSON scripts for reading/parsing data.

Currently, the Triggers are being mixed up between Obstacle triggers, NPC triggers, and player-scripted triggers. Too much stuff to handle.

Rewrite and split off these components into their own triggers, so it makes it even easier to manage and take control of them in the script editor.

That way, there is no need to fight over which entity takes which trigger stored on the area map files.

The entire pixel data structure is completely incorrect, thus breaking almost every single component in the game AND in the editor.

Gotta rewrite the [Tiles] section in the documentation, and then have to clean up all the pixel data and bitmaps loading.

TOP PRIORITY!

N = 1 or more.
M = 1 or more. Does not equal to N.

The game and the editor both needs to support tiles that are larger than 1x1 tiles.

Or, the editor needs to support large tiles, while the game translate large tiles into 1x1 tiles that are grouped together with the same functionality.

Either way, this will help immensely with placing down building tiles and large structural tiles that 1x1 tiles can't fit data in.

With the necessary features added to both the game and the level editor:

• TDIC
• Multiple triggers on same tile
• Moving triggers to adjacent tiles

We can then work on adding non-playable characters to the game and level editor.

EDIT: Not there yet. Will need to separate those features out of this NPC feature.

For saving data into the area map file, consider condensing the NPC, Obstacle, and Item data (called EditorDataSet), so that it is in the format (sequential read/write order):

Pixel 0 (first pixel):

• (x, y) position format is AARR. (X = AA, Y = RR)
• (editor ID) is GGBB.

Pixel 1 (second pixel):

• Color Data value (AARRGGBB)

This saves up 2 pixels per data, from 4 pixels down to 2 pixels.

"Save Map" operation doesn't save extra metadata in the map files required for Trigger Data Identification.

"Load Map" is capable of loading extra metadata, but it doesn't have a check to make sure whether the map being loaded has the extra metadata.

When I got on the bike the first time, I pressed a direction before the bike appeared and I biked uncontrollably off the screen. Not a big issue, just letting you know. I couldn't do it more than once, though.

• by erotic_thunder

Sometimes, it is possible for the level editor to become glitchy.

This is due to overabundance of method calls invoking Java Swing validate() method, which updates the Swing UI components.

The goal is to reduce the amount of invocations to validate(). This should also boost performance and reduce computer fan noise.

"RETURN" menu item should always be in the PACK, in all pockets (categories), no matter what. Investigate why it is removed.

By default, Eraser should never be added into the triggers list twice when loading a script file. This needs to be fixed.

Eraser trigger should only appear once in the editor.

I'm wondering if it's really necessary to add/include the Eraser trigger into the area map file upon saving the map?

This is to replace the current loading/saving system the game uses, which involves manually counting bytes alongside how many bytes being read from the data file.

This new method of loading/saving system will not only improve the situation by removing the manual counting, but also make the system be flexible enough to add additional information without having to fight against hordes of byte values.

Documentation will be updated once this feature has been implemented and after it has been successfully tested.

Blocks #9 .

When a modded world is loaded, if the player attempts to enter a warphole (door), the supposed second area didn't get loaded, and the screen shows up as a void. The player can exit the void by returning back to where the door is supposed to be (usually pressing down will exit the void).

This needs to be fixed if the player is attempting to load custom mods and scripts.

Original, default worlds do not have this issue.

Instead of using mnemonics and symbols, triggers can be made human-readable, so it is easier for the users to edit and update the triggers without having to open the level editor and access the script editor.

Due to the recent refactoring, it broke picking up items.

Will need to fix this.

Trigger Data Identification Code (TDIC tag) is a fixed-length checksum used for identifying which trigger script file goes with which area level data.

This makes it so that whenever you create / mod an area and provided script files for said area, the area and the script file can store the checksum, so that, regardless of how many area files and script files are placed in the modding folder directory, they will always be able to uniquely identify each other and the correct script file will always be loaded with the area level that is active in the game.

This also reduces a lot of headache on game and level distribution, which is sorely needed. I blame my younger self for not realizing this sooner.

This is related to non-playable characters and getting them to interact with the player based on trigger data.

Trigger Data not only stores information about events, but also stores scripted movements and dialogues. With non-playable characters, these features are essential to get it to work right.

If an entity moves from a tile to another adjacent tile, triggers must follow the entity, otherwise, the game will be broken.

When following the entity, both the game and the level editor need some sort of tracking to track where the trigger events should fire, and when the tiles are cleared of any events, should triggers be moved elsewhere.

Must capture mouse events only in the main drawing panel area. Not outside of it.

An input bug somewhere.

It's opening PACK too quickly after riding the bicycle and opening the Start Menu.

One more thing- I'm having trouble re-loading maps in the editor; instead of getting the map I saved, I get something like this.
Any idea?

• by erotic_thunder

Info about TDIC: #29

Currently, the game's test level maps are created using the Editor v8 build. The maps will have to either be recreated using the latest Editor v9-dev build (work-in-progress), or new maps will have to be generated.

Currently, dialogues are hardcoded in the game. Revisit the idea of loading dialogues from trigger scripts.

Or perhaps create a new scripting language for NPCs?

This is in conjunction with NPCs, where it is possible for NPCs to have different trigger scripts depending on where the player's progress is at.

Script editor must have the ability to specify multiple trigger scripts in the same location. Each trigger script must have data available to check for conditions.

Level editor must have the ability to store multiple triggers within the area map file.

Game must be able to run and trigger multiple triggers, and checking each trigger condition if multiple trigger scripts are located in the same pixel data.

Blocks Characters / NPCs system.

This is critical... D:

This has to do with the save data having little to no information about the item when attempting to load the data.

Needs both saving and loading the data to work together in order to restore items that were already picked up and put into the PACK.

Current codebase for saving and loading data is not really that flexible to add or make changes without losing track of where the byte pointer is reading at.

Will need a full rewrite, with a better way of packaging the save data information. Also, will need a new documentation change.

Hint: Think about TCP and UDP data packet headers.

Not done with loading/saving system.

Need to check for WorldConstants.isModsEnabled.

When I load, the items disappear.

EDIT: To be even more precise, the items in my inventory disappear.

• by Jonas