chiefofgxbxl / ice-sickle Goto Github PK

Utility class will have helpful functions like converting a hex code #003399 to an RGB triplet [255,255,255] or vice versa. It would simply contain miscellaneous functions that can be used in windows and plugins.

• Help > Release Notes
• Help > Report Issue
• Help > Support

We are currently using app.getAppPath() as the location for storing plugins, scripting languages, etc. The problem is that while it works in dev, in production the app path includes the /resources/app.asar in the path. Rather than trimming that out only in production, use app.getPath('userData') as the directory to store settings, scripting, and plugins. This will be consistent across dev/prod environments.

See: https://github.com/electron/electron/blob/v1.1.0/docs/api/app.md#appgetpathname

When the user hits the submit button to create the new project, the window should close and the project should be loaded.

We established that the triggers the user writes in the Trigger Editor will simply be concatenated together and placed in the war3map.j file. However, there are other sections that need to be generated, like:

function config takes nothing returns nothing
    call SetMapName( "TRIGSTR_001" )
    call SetMapDescription( "TRIGSTR_003" )
    call SetPlayers( 1 )
    call SetTeams( 1 )
    call SetGamePlacement( MAP_PLACEMENT_USE_MAP_SETTINGS )

    call DefineStartLocation( 0, 2368.0, 256.0 )

    // Player setup
    call InitCustomPlayerSlots(  )
    call SetPlayerSlotAvailable( Player(0), MAP_CONTROL_USER )
    call InitGenericPlayerSlots(  )
endfunction

Some of these sections are obviously very straightforward, but I want to make sure we don't miss anything. Can you comment on any JASS oddities or things we need to be careful about?

An example of a confusing setup: call SetDayNightModels( "Environment\\DNC\\DNCFelwood\\DNCFelwoodTerrain\\DNCFelwoodTerrain.mdl", "Environment\\DNC\\DNCFelwood\\DNCFelwoodUnit\\DNCFelwoodUnit.mdl" ). I believe this is because I set a custom light environment in the map properties.

• Release notes
• Report issue
• Support (wiki)

Create a simple TreeView component that shows a hierarchical display of items, like in Atom. This will be used for the object editor to categorize object entities into folders, and for the trigger editor to organize triggers.

Basic features:

• Add items
• Click to select an item; retrieve selected item; onSelected
• Remove items (capture delete key)
• Context-menu on right-click
• Collapse folders
• Drag and drop to reorganize an item/folder

There is a tutorial which implements a css-only one, but this requires <input> elements. A simple JavaScript implementation using nested <ol>'s would be fine.

The progress bar is not displaying any progress of the update

Create settings.json file if it does not exist before using it so the app doesn't crash, and data can be saved to settings.

Create the next window: imported files. Users should be able to drag-and drop files onto the window to import, or use a file-viewer to select files.

A simple window would simply display the name and the path. Imports may also be categorized by type or organized as the user wishes.

Files imported to the project are stored under the /imports directory.

The following user input windows are unimplemented (so they default to text):

• abilityList
• abilCode
• heroAbilityList
• stringList
• icon
• int
• modelList
• unreal
• bool
• real
• shadowTexture
• model
• versionFlags
• teamColor
• uberSplat
• shadowImage
• defenseType
• deathType
• targetList
• armorType
• attackType
• attackBits
• weaponType
• combatSound
• tilesetList
• moveType
• pathingListPrevent
• pathingListRequire
• aiBuffer
• pathingTexture
• soundLabel
• unitSound
• attributeType
• regenType
• unitClass
• unitRace
• unitList
• itemList
• techList
• intList
• upgradeList
• string
• char

This list may not be complete. More windows may exist in the other object editor types that have not been implemented yet. So far I only checked the Unit fields.

Many of these are simply drop-down menus, so they can simply open a dropdown-single-select menu and specify the Enumeration of keys/values.

Abilities is going to be the most difficult object editor type to implement because of confusing data fields:

1. Data fields

By (1), I mean that it is unclear how Blizzard stores ability data. For example, take a look at the AbilityData.csv file found in WEdata/Units in this repo. On row 53 there is the Storm Bolt ability. The level 1 damage is stored in the DataA1 column (100).

But the ability Bash's DataA1 column actually stores the Chance to bash value. So it's not easy to say an ability's damage is stored in the A column. Is there anywhere in the war3.mpq where a file acts as a lookup table between ability fields and the column the data is stored in?

Display a list of recent maps in the File menu. This will help the user open maps quicker. See #1.

There are four tabs in the Map Properties window:

• General
• Options
• Size & Camera Bounds
• Loading Screen

The last 3 tabs' forms are not pre-populated when the window is opened, even though the data is there. Use the context to set the fields.

If text is too large to fit in the ListView, it breaks the entire script. Instead, the text should be truncated and an ellipses (...) should be appended.

This leads to an error when trying to load a project -- the load code cannot read a folder that does not exist.

When each plugin is loaded, they need to be given the Plugin class to use for all their functionality. The problem is that plugins loaded in the deployed application (not via npm start) try to require('...Plugin') and fail because that is part of the application's node_modules.

Plugins will have to be re-structured again to be in the following form:

var myPlugin = function(Plugin) {
  // can do stuff with Plugin

  return {
    init: function() {},
    onMenuClick: function() {},
    ...
  }
}

module.exports = myPlugin;

Implement a number of prompt requests to ask the user for input.

e.g. promptInput, promptOpenProject, promptYesNo, etc.

The production version complains frequently about missing files, such as when the app is supposed to require() core application files. Evidently, these are not being included in the application build.

Previous ideas to resolve this included copying all that data to the user's machine (messy and non-standard), or using the extraFiles build option to include them in the app directory.

The current naming scheme of the events is like: this-new-event when it should be thisNewEvent

Add menu item to File menu bar to open a new Settings window. The user will be able to view and alter various settings for the editor. To get started, a few things can already be chosen:

• # of most recent projects to list (0-10)
• map author name to automatically set when creating a new project
• maximize root window (if maximized, call root.maximize)

Use Gitbook to develop a knowledge base of questions for Ice Sickle, plus misc. WC3 information like quirks and tips. The gitbook can then be opened in a Help window (via Ctrl-H, too!), since browserWindows can also open remote URLs. It may help, if the page time is too long, to load it and keep it hidden.

The plugin class should contain an object called Enum which contains all the enumerations under the enum folder. This way, plugins can easily use these values.

Create a Windows/OSX installer, probably using https://github.com/electron-userland/electron-builder. This will create an executable which the user can download and run to install the application.

If settings does not have the children globals/locals then an error will occur when trying to read. Set those if not present.

The logic is written assuming a dev environment. The code needs to load from %apppath%/scripting/languages instead.

The welcome screen could use a visual touch-up to better display recent maps, and make way for other content in the future.

The new Documents system needs to contain the folder icesickle, and sub-directories plugins and scripting/languages

To improve the Wiki, we'll be using more and more icons and images uploaded to GitHub content URL (drag-and-dropping into a textbox). There should be a master list to easily reference these image paths.

Place in sidebar or footer?

Implement Electron's autoUpdate. A Squirrel deployment system will need to be established to create releases. The application will automatically check for updates when it is launched, and close if it needs to apply updates. The user may also click a Check for Updates menu item in the Help menu.

It will be a while before this feature is implemented. The code base will need to become more stable, and release cycle and procedure established.

Create a new map and directly open the object editor. The window opens but the page is not populated.

Create a new class to resolve object entities, given a type and id. The resolver's job is to give back an object with the requested entity ID, but with unmodified/default fields filled in from the base object. This functionality is already implemented in the Object Editor, but would be good to put in its own class as other windows may need it.

The parallel window to Map Properties is the Scenario Properties, which has the following forms:

• Players
• Ally Priorities
• Forces
• Techtree
• Abilities
• Upgrades

The priority for this form is the Players and Forces forms, as they are the two necessary ones to make a map functional. Implement this functionality along with form pre-populating.

The structure of the repo folder can be cleaned up by storing the window manifests (/windows) alongside the actual HTML views (/views). It may make more sense to place everything under a windows folder, where each view gets a sub-folder:

/ windows
  / object-editor
    object-editor.html
    manifest.json
  / trigger-editor
   ...

Notepad++ has a decent layout:

For scripting compilation, simply copy over a hard-coded version from an empty map so we can get the merging set up and the map working.

What are the different coordinates used by WC3? E.g. camera bounds, map size, camera offset, camera margin, and so on.

The role on the MenuItem can be set to quit to handle this automatically

Create a new log event, which stores an array of log messages for the app or plugins to use

Types

• info
• warn
• error

e.g. Plugin.event.send('log', { type: 'info', message: 'the plugin loaded successfully!' } )

Implement the Size & Camera Bounds menu in the Map Properties window. The user should be able to resize the map size and camera bound boxes. Remember that the sizes have to be multiples of 32.

Opening a recent project from the application's menu bar (File) is not emitting the projectLoaded event, even though it is opening the project.

Implement a task window (e.g. Ctrl-G) which consists of a textbox where the user can enter virtually any possible action to perform. They can search for actions, object entities, world entities, etc. This would be similar to the new "Tell me what you'd like to do" bar in the latest Microsoft Office Suite (see Excel or Word for an example).

Plugins should be able to:

• Be defined similarly to Node.js apps (package.json)
• Be loaded automatically from the /plugins folder on app startup
• Send and receive events
• Register new windows
• Store plugin settings
• Add plugin sub-menu to main menu bar

Certain windows should not be resizable. This can be controlled via the resizable boolean set in the window .json file

After #40, add a .log section under the Plugin class as a shortcut / alias

e.g.

Plugin.log('info', 'the plugin successfully loaded!')

instead of having to send:

Plugin.event.send('log', {
  type: 'info',
  the plugin successfully loaded!
});

Both would be valid ways of logging. The first one is simply quicker.

See #40

Tried to run src code and I got this:
npm start

An event needs to be added to the root window so that when it closes, the entire application shuts down. It does not make sense that, for instance, the Object Editor can stay open without having root open, but that is how it currently works.

Security vulnerability exists in electron 1.6.10 (current version). Update to 1.6.16.

• Don't show "checking for updates" window - we'll assume this always happens (silently)
• Store when updates were last checked for in Settings
• Display updates last-checked in About window
• If an error occurs in downloading the update, notify user

Stores editor settings globally