Ved technical documentation

This page is intended to document Ved's internals as well as possible. The page is still being worked on, and more things are being added over time. If you'd like to know more about anything specific in Ved that I haven't explained yet here, or not well enough (except for the easter eggs :P), feel free to ask! If you'd like more information on how to make plugins, check this page. The repository is here.

Last updated: Wednesday 13 July 2022 16:43 (UTC) (this is the last edit date of the file)

Files

The following source files are used in Ved. Note that this table may not be entirely accurate - the "Added" column may not always be filled in even if a file didn't exist since the early days of Ved for example, some files may have been removed from the list altogether when they were removed, some changes may not yet have been documented here, and some files may have had more complicated overhauls. Version numbers in parentheses indicate that basically, the file had either been renamed, or something else is the matter that should be explained in the description.

States

Ved uses state numbers to represent different screens, menus and interfaces. Blue state numbers are not normally used anymore, and/or are not normally accessible, and many of them are leftover testing states. Red, struck-through state numbers have been removed from Ved altogether (and won't be reused).

As of 1.8.2, most of the code specific to each state can be found in the uis/ directory. States have their own versions of LÖVE callbacks (such as ui.update(dt), ui.keypressed(key), ui.mousepressed(x, y, button), etc). Furthermore, user interfaces can be built up of "Elements" which may automatically implement their own callbacks based on their parameters and position. For example, buttons can be defined to automatically be drawn at the correct position, and to execute the same action when it is clicked and when a given shortcut is pressed. For more information, see the GUI elements section. It should be noted that states can also implement ui.draw(), which is called before the Elements are drawn.

State allocation

In Ved 1.1.4 and higher, plugins can allocate an amount of states for their own use, without using hardcoded state numbers, making it unnecessary to think of unique state numbers that won't interfere with any other plugins or future Ved updates. The following functions can be used:

allocate_states(name [, amount=1])

This function is used to allocate the given amount of states with identifier name.

in_astate(name [, s=0])

This function returns true if the current state is s for identifier name. These state numbers start at 0.

to_astate(name [, new=0 [, dontinitialize=false]])

Change state to state number new for identifier name, and if dontinitialize is set, call hook func_loadstate.

For example, take a plugin called My First Plugin, which uses three states. Upon startup, like in hook love_load_start or love_load_end, the plugin calls allocate_states("my_1st_plug", 3). If this is the only plugin, or the first plugin to call allocate_states(), the allocated states will now, internally, be 100, 101 and 102. Let's say My First Plugin has three buttons to go to each of the allocated states. The first button, when clicked, would call to_astate("my_1st_plug", 0), the second would call to_astate("my_1st_plug", 1) and the third would call to_astate("my_1st_plug", 2). Hook love_draw_state, would contain something like this:

if in_astate("my_1st_plug", 0) then
	-- Insert drawing code for first state!
	statecaught = true -- <- only necessary in 1.8.1 and older!
elseif in_astate("my_1st_plug", 1) then
	-- Insert drawing code for second state!
	statecaught = true
elseif in_astate("my_1st_plug", 2) then
	-- Insert drawing code for third state!
	statecaught = true
end

The hook func_loadstate could contain something similar for initialization code for all the states (but without statecaught = true). Speaking about statecaught = true, this variable was used to prevent an "Unknown state" screen from showing, but this screen has been removed in 1.8.2, and thus setting the variable is no longer necessary.

The identifying name can be anything, but this name should be unique to one plugin. It's also possible to allocate multiple blocks of state numbers within the same plugin, if you use different names. If your plugin only has one state, you can leave out the number (allocate_states("my_1st_plug"), in_astate("my_1st_plug"), to_astate("my_1st_plug")). And of course, this means you can have multiple states that are only referred to by string names (I can see how in_astate("my_1st_plug_menu") and in_astate("my_1st_plug_display") can be more pleasing than in_astate("my_1st_plug", 0) and in_astate("my_1st_plug", 1)). It's up to you to choose whatever you like most, or whatever works best for your plugin.

LÖVE version compatibility

Ved is compatible with all revisions of LÖVE 0.9.x, 0.10.x and 11.x (except LÖVE 0.9.0 as of Ved 1.4.2), but its code is written for 0.9.x. Compatibility with newer versions is mostly achieved by causing update changes to be undone; for example, LÖVE functions that were renamed or expect different arguments are redefined/hijacked and then called by those redefinitions if arguments or return values need to be passed differently, and callbacks that get "new-style" data from LÖVE get a bit of conversion code at the top. There are a few instances of conditionals depending on the version number in regular code, but that is not very common.

In summary: (the unsupported features per version are more detailed below)

Checking the LÖVE version Ved is running under

Ved has a dedicated function to check if the current LÖVE version is at least a certain version or later, love_version_meets(). E.g. love_version_meets(10) means "LÖVE version is 0.10.0 or later", love_version_meets(9, 2) means "LÖVE version is 0.9.2 or later". It automatically takes care of the difference between 0.x and 11.x, too, so love_version_meets(10) means "LÖVE version is 0.10.0 or later" while love_version_meets(11) means "LÖVE version is 11.0 or later".

Features unsupported in older LÖVE versions

Nevertheless, there are simply some features or improved behavior added in later LÖVE versions, which Ved takes advantage of, that simply can't be backported to previous LÖVE versions. None of these are particularly important features for Ved's main purpose of editing levels, but it is still good to document them.

Loop points in the music player/editor
This feature is only supported in LÖVE versions 11.0 and up.

Ogg/Vorbis audio can have loop points, which work in VVVVVV. Ved 1.10.0 added support for playing the audio with loop points correctly as well, but this relies on QueueableSource, which was added in LÖVE 11.0. So on older versions, the audio instead just loops from start to finish (including the intro and the possibly otherwise inaccessible part beyond the end point).

Debug mode

Debug mode is a special mode used to access certain features and information that can be useful for debugging and developing Ved. Enabling debug mode has the following effects:

• You can jump to any state by pressing F12
• The window title bar displays the FPS, state number, window size, cursor position and LÖVE version number.
• Entities have tooltips with their properties
• You can access the lua_debug console by pressing Ctrl+PageUp. Make sure you do have a console attached, this blocks the entire Ved window until you type cont in the console. This shortcut is always available on a crash screen, by the way, even outside debug mode.
• You can limit the framerate to 60, 30 or 15 by pressing Ctrl+PageDown
• Entity IDs/table keys are shown in the raw entity properties dialog
• The hidden tileset creator can be accessed by pressing LCtrl+\ in the main editor (I'm pretty sure I've written an explanation of it somewhere, but I may document it here as well) (removed in 1.8.3)
• Pressing LCtrl+' in the main editor will print all tileset and tilecol numbers to the console
• Pressing F11 will print all global variables to the console
• Holding / in the main editor would display instead of all entities, but that key now jumps to the script editor.
• A visual indicator is added that displays when text input is being taken.
• On the loading screen, you can add a fake level to the list of levels by pressing Shift+F2, and (visually) remove the last level from the list by pressing Shift+F3. This is for testing the scrolling area and such.
• You can see outlines for all GUI elements (see below) by holding F8

Debug mode is enabled by the boolean variable allowdebug. It is possible to enable it in-app by going from the load screen to the Ved options, clicking and holding the OK button, and "dragging" over the Send Feedback button holding the right mouse button as well.

Editor-related variables

Current room

Selected tool

Selected tileset

Undo/redo stacks

Other things

The number of the currently selected tile is stored in selectedtile.

To edit roomtext and (re)name scripts in script boxes and terminals, Ved uses editingroomtext. The entity ID of the entity data attribute currently being edited is stored in editingroomtext. You can get the entity being edited by simply doing entitydata[editingroomtext]. Since tables in Lua are 1-indexed, editingroomtext cannot be 0, so to check if we are currently editing the roomtext, just do editingroomtext > 0; to check if we are not, just do editingroomtext == 0.

editingroomname is a boolean that is true when the current room's roomname is being edited, and false when it isn't. However, you should use toggleeditroomname() to start and stop editing the roomname.

When editing enemy and platform boundaries, Ved uses editingbounds. It is 0 when no boundaries are being edited. Its magnitude (i.e. its absolute value, i.e. ignore the negative sign if there is one) will be 1 for platform bounds, and 2 for enemy bounds. Its sign (i.e. whether it's positive or negative) will be negative when placing the first corner (the top-left corner), and will be positive when placing the second corner (the bottom-right corner). So to reiterate: when editing platform bounds, editingbounds will go from 0, to -1, to 1; and when editing enemy bounds, editingbounds will go from 0, to -2, to 2.
You can start a boundary edit by calling either changeplatformbounds() or changeenemybounds().

The variable that controls the eraser (i.e. whether right-clicking will erase tiles if holding a tile brush) is eraserlocked. When it is true (by default), you can erase tiles using right-click. When false, you cannot.

Whether or not enemy and platform bounds are rendered is controlled by showepbounds.

The tiles picker (e.g. what pops up when you click on "Show all", or press/hold Ctrl+Shift) being open or not is controlled by tilespicker. tilespicker_shortcut controls whether or not you are holding the shortcut, so Ved knows to close it when you release Ctrl+Shift. But using RCtrl+RShift will keep the tiles picker open (and mixing Left/Right Ctrl+Shift will be the same as LCtrl+LShift - that is, it won't "stick" and you have to keep holding the key combo).

Level-related variables and functions

Level metadata

metadata["Creator"]
metadata["Title"]
metadata["Created"]
metadata["Modified"]
metadata["Modifiers"]
metadata["Desc1"]
metadata["Desc2"]
metadata["Desc3"]
metadata["website"]
metadata["mapwidth"]
metadata["mapheight"]
metadata["levmusic"]

Room tiles

To get a tile in a room, use roomdata_get(x, y, tx, ty). To get all of a room's tiles, use roomdata_get(x, y).

To set a tile, use roomdata_set(x, y, tx, ty, value). To set all of a room's tiles, use roomdata_set(x, y, values).

From 1.8.0-pre22 until 1.9.0-pre05, these functions had an altstate argument for VVVVVV-CE. See the Changelog of breaking codebase changes for 1.9.0 for more info.

Entities

{
	x = 12,
	y = 34,
	t = 17,
	p1 = 0,
	p2 = 0,
	p3 = 0,
	p4 = 0,
	p5 = 320,
	p6 = 240,
	data = "Roomtext or script name"
}

Room metadata

{
	tileset = 0,
	tilecol = 0,
	platx1 = 0,
	platy1 = 0,
	platx2 = 320,
	platy2 = 240,
	platv = 4,
	enemyx1 = 0,
	enemyy1 = 0,
	enemyx2 = 320,
	enemyy2 = 240,
	enemytype = 0,
	directmode = 0,
	warpdir = 0,
	roomname = "Roomname",
	auto2mode = 0,
}

To get a room's metadata, use levelmetadata_get(x, y).

To set an attribute of metadata, use levelmetadata_set(x, y, attribute, value). It's also possible to use levelmetadata_set(x, y, attribute_table) to replace the entire room's metadata table.

Scripts

scriptnames = {
	[1] = "mynewscript",
	[2] = "mynewscript_load"
}
scripts = {
	mynewscript_load = {
		[1] = "ifflag(2,stop)",
		[2] = "flag(2,on)",
		[3] = "iftrinkets(0,mynewscript)"
	},
	mynewscript = {
		[1] = "reply(3)",
		[2] = "I probably don't really need it,",
		[3] = "but it might be nice to take it",
		[4] = "back to the ship to study..."
	}
}

Counts

	local mycount = {trinkets = 0, crewmates = 0, entities = 0, startpoint = nil, FC = 0}  -- FC = Failed Checks

Metadata entity (level notes, flag names)

The metadata entity is used by Ved to store data that is specific to a certain level. It is a roomtext entity at x=800 y=600, which means it's in room 21,21 (1-indexed). The data is formatted with several levels of separation characters:

For example, one of the "tables" contains level notes. Each level note is separated by $, and inside a level note, the name and the contents of the note are separated by @.

Accent grave (`) is the escape character; if the real versions of certain characters need to be represented, they are escaped as follows:

The function despecialchars(text) encodes the raw characters to escaped format, undespecialchars(text) decodes escaped characters back to raw characters.

As said, | is the primary separator, which separates the following items:

(more coming soon)

Clipboard room format

Currently, when you copy a room to the clipboard, it's stored in a comma-separated format. It consists of 1215 values separated by commas, and it's structured as follows (indices start at 1, as in Lua):

In the room name, commas are replaced by the character ´ (U+00B4 ACUTE ACCENT).

In this format, entities are not copied. I'm planning to replace this CSV system by an XML format, which will also contain entities. Data in the old format will still be pasteable, and I'll probably also leave in a way to copy as CSV.

Dialogs

dialog.create(message, buttons, handler, title, fields, noclosechecker, identifier)

message is the body of the dialog box. This is the only required argument.
buttons speaks for itself as to what it is (but see below), if not specified, only an OK button will be present.
handler is a function that will be called when the dialog is closed, and will be provided with the button that was pressed and the dialog fields.
title is the title text of the dialog. Setting this to an empty string is not needed anymore.
fields defines the input fields that the dialog has, see below. If not given, the dialog has no input fields.
noclosechecker is a function of which the main purpose is to check whether a button shouldn't actually close the dialog, and should return true if so - think of apply buttons
identifier is just an extra internal label indicating the type of dialog, rarely used (it's used for the quit dialog to know that a quit dialog is already on top)

Buttons

Strictly speaking, the buttons parameter accepts a list/table of buttons. For each element, if that element is a string, that string will be displayed as-is. But if possible, it should be an integer, representing one of the built-in buttons. A list of buttons is available as DB, so for example, DB.YES is a "Yes" button. The list is as follows:

DB.LOAD was added in Ved 1.6.0. DB.ADVANCED was added in Ved 1.10.0.

There's also built-in lists of buttons available as DBS, like DBS.YESNO, which stands for {DB.YES, DB.NO}, meaning a Yes and No button.

DBS.SAVECANCEL and DBS.LOADCANCEL were added in Ved 1.6.0. DBS.OKCANCELADVANCED was added in Ved 1.10.0.

Handler

The purpose of the handler function is to take action after closing a dialog. For example, if a question is asked whether the user wants to destroy something, then that should be done if (and only if) the user chooses DB.YES.

The handler is a function that can take up to five arguments:

• The first is the returned button (an element of the buttons list provided to dialog.create).
• The second argument is a table with all the contents of the input fields, where input field keys are the keys, and their inputs are the values.
• Optionally, the "identifier" of the dialog, if given when creating the dialog
• A boolean that is true if closing the dialog has been prevented by the no-close checker (more below)
• As of Ved 1.4.5: the dialog object

Dialog handlers as used in Ved's code can be found in the file dialog_uses.lua, starting with dialog.callback. An example handler is the following. Assume the buttons for this dialog are DBS.YESNOCANCEL. In this example, users press Yes if they want a new dialog to be created showing what they entered in a field with the key name, press No if they still want a dialog but don't want to know their input, and press Cancel if they want no new dialog.

function(button, fields)
	if button == DB.YES then
		dialog.create("You pressed Yes, and the input with key \"name\" is " .. fields.name)
	elseif button == DB.NO then
		dialog.create("You pressed No! Apparently you don't want to know what you entered, but you still want a dialog.")
	end
end

No-close checker

No-close checkers are similar to handlers, but they are called before the dialog closes. This function can stop the dialog from being closed by returning true, and thus are useful for creating error messages if the user puts in invalid input. They can also be used to not close the dialog if an Apply button is pressed, for example.

The arguments for the no-close checker are the same as for the main handler, except the fourth argument (closing prevented by no-close checker) doesn't exist, which means the fourth argument is the dialog object. If the no-close checker returns true (and thus stops the dialog from closing) the handler will still be called, and its fourth argument will be set to true as well. Here's an example of how a no-close checker can be used to give an error message in case someone enters a value for the field with key inp that is empty or above 20 characters:

function(button, fields)
	if button == DB.OK and (fields.inp == "" or fields.inp:len() > 20) then
		dialog.create("Your input must not be empty or longer than 20 characters.")
		return true
	end
end

function(button, fields, identifier, notclosed)
	if notclosed then
		return
	end

	if button == DB.OK then
		-- Save your fields.inp here.
	end
end

Fields

1. Key (its identifier, like name in a HTML input field)
2. X position in characters (blocks of 8)
3. Y position in characters (blocks of 8)
4. Width of input field in characters (so in blocks of 8 again)
5. Default value (like value in HTML)
6. Type (for example, use DF.TEXT for a text field)

The X and Y positions for the field both start at 0, which is the position the regular dialog text also starts.
These are the different types of input fields:

The DF. constants were added in Ved 1.5.0.

dialog_uses.lua has some complete forms (but mostly functions that generate forms) under dialog.form. One general-purpose example is dialog.form.simplename, which has a single text field at position 0,1 to be used to fill in a name (for example a name for a new script or note), and dialog.form.simplename_make(default) to generate a similar form but with a value pre-filled.

More information about how the different types work:

(0) DF.TEXT - Text input

(1) DF.DROPDOWN - Dropdown

7. A list of items shown in the dropdown menu
8. An optional table that converts a value to a displayable "current selection" if you want to hide how the value is passed. If not given, set this to false if you also want to supply the next argument.
9. An optional function that gets called whenever a selection is made from the dropdown. Think of an onchange event in HTML/JS. Gets passed the selection from the dropdown as text, and may return a substitute to fill into the input field behind the scenes.

Basically, there's two forms: first the simpler one. In the simpler form, you only need a list of items that will appear in the dropdown, and whenever the user selects an item, the value of the input field is set to the text of the option that the user selected. This means what's readable as an option will be passed. You may want to set the default value to an option in the list.
An example: {"drop", 0, 0, 30, "Option A", DF.DROPDOWN, {"Option A", "Option B", "Option C"}}
The width is set to 30 because that's how wide dropdown menus are (currently). If you want a function to be called every time an option is selected in this case, there'd be two more arguments: false (as a filler for the second table) and then the function.

For the second form, let's take the example of a user selecting between percentages, let's say 50%, 100% and 200%. You want to pass this as a number instead, so if the user selects 50%, you want the actual value to be 0.5. When the user does select 50%, the "onchange" function is called, and converts the "50%" into 0.5, and returns that. The second table that was mentioned (the one that converts a value to a displayable "current selection") has this 0.5 background value as a key, and that maps to a value of "50%".
So this is that example:

{
	"drop2", 0, 2, 30, 0.5, DF.DROPDOWN, {"50%", "100%", "200%"}, {[0.5] = "50%", [1] = "100%", [2] = "200%"},
	function(picked)
		if picked == "50%" then
			return 0.5
		elseif picked == "100%" then
			return 1
		elseif picked == "200%" then
			return 2
		end
	end
}

As of version 1.5.0, you can use the function generate_dropdown_tables(tuples) to generate these last three arguments. The function takes a table as an argument with key-value tuples as elements (not keys as keys and values as values). It returns the three required arguments for the second form (list of displayed items, converter key-value table and "onchange" function). For example, the previous example could be written more elegantly as follows:

{
	"drop2", 0, 2, 30, 0.5, DF.DROPDOWN, generate_dropdown_tables({{0.5, "50%"}, {1, "100%"}, {2, "200%"}})
}

(2) DF.LABEL - Plain text label

This is just a bit of text that can be displayed anywhere in the dialog you want. It can therefore be used to label other input fields without having to include those labels in the dialog contents.

The "default value" will be used as text, but it can also be a function that returns the text dynamically.

An example for a plain-text label is as follows: {"", 0, 5, 10, "Label", DF.LABEL}
The key is left empty, because it has not much use. But we can't set it to nil, otherwise Lua might think the table ends there. It is positioned on the start of the 6th line. The width is 10 characters, which means it will merely wrap beyond that point. Then the label is just a string, and will be displayed. 2 is the type.

Here's an example of a label that keeps changing: {"", 0, 5, 40, function() return love.math.random() end, DF.LABEL}
This will continuously display a different random number between 0 and 1. Note that the key and the table of fields are passed to the function, but it's not used here.

(3) DF.CHECKBOX - Checkbox

{"option", 0, 5, 2+font8:getWidth(OPTIONLABEL)/8, true, DF.CHECKBOX},
{"", 2, 5, 40, OPTIONLABEL, DF.LABEL}

(4) DF.RADIOS - Radio button list

Radio buttons were added in Ved 1.5.0. These function exactly like dropdowns do, the only differences are the type and the way they behave in the GUI. The width argument is not used. You can use the same generate_dropdown_tables function for radio buttons that you can use for dropdowns.

For example, the time format picker in the language dialog works like this:

		{
			"timeformat", 23, 8, 0, s.new_timeformat, DF.RADIOS,
			generate_dropdown_tables(
				{{24, "23:59"}, {12, "11:59pm"}}
			)
		},

The initial value is s.new_timeformat, which is the setting for the time format, which is either 24 or 12. Selecting "23:59" sets the value to 24, selecting "11:59pm" sets the value to 12. (Note that the dialog handler should apply the change, the value that you fill in as 5th argument is merely the initial state of the 'field'.)

(5) DF.FILES - Files list and directory navigation

The files list type was added in Ved 1.6.0. The default value is the full path to the current directory. It takes 7 more arguments (note that despite me giving each of these arguments names, they don't actually have keys by those names, and this is only to make it easier to understand):

7. menuitems - A table of files, where each file is a table of the form returned by listfiles_generic(). That is, it has the attributes of name, isdir, and lastmodified.
8. folder_filter - If argument 7 (filter_on) is on, then the files listed will only be the ones ending in this string. Usually it'll be a file extension like .vvv. You can make this filter only directories by passing the operating system's directory separator, which should be dirsep.
9. folder_show_hidden - Whether or not to show hidden files or not. This is passed to listfiles_generic(), which goes off of the operating system's definition of hidden.
10. listscroll - The Y offset of the files list due to the scrollbar, as (indirectly) generated by scrollbar().
11. folder_error - A string for indicating errors. It should be non-empty when there's an error.
12. list_height - The amount, in blocks of 8, of the list.
13. filter_on - Whether or not to apply the filename-ending filter from argument 2 (folder_filter).

Note that you need a field with the key of "name" to select a file, and you need a checkbox to toggle showing only directories, showing only files that are filtered, or showing hidden files.

For this reason, it is recommended to make a full file selection dialog with dialog.form.files_make() instead. In fact, all code in Ved currently uses that function instead of making the files list manually.

dialog.form.files_make(startfolder, defaultname, filter, show_hidden, list_height)

All of the arguments are required.
startfolder is the full file path to the folder you start the dialog in, just like the default value for DF.FILES.
defaultname is what to put as the default value for the "Name:" field.
filter will filter for filenames that end in this string, unless you pass it dirsep, in which case directories will be filtered instead. A checkbox toggling the filter will be created. If you decide to filter directories, then there will no longer be a "name"-key field.
show_hidden is whether or not to show hidden files, by the operating system's definition of hidden.
list_height is the height (in blocks of 8) of the list.

(6) DF.HIDDEN - Hidden field

Hidden fields were added in Ved 1.8.5. A hidden field can be used to carry data from dialog creation to dialog submission, without accepting user changes. For example, if you have a confirmation dialog to delete a certain script, you want to still know what script it was when the user presses "Yes". The type of the value can be anything you need, as long as it is not nil (again, Lua limitation, unless we changed dialog fields to have string keys for named arguments). nil values could instead be encoded as having the field be missing altogether, which will have the same effect, because for the handler, fields.the_missing_field would yield nil anyway. Position and width has no meaning for this field, so for example: {"key", 0, 0, 0, "value", DF.HIDDEN}

There is a convenience function to make a form with hidden fields from a table where the keys and values correspond to the field keys and values: dialog.form.hidden_make(values, existing_form). existing_form can be filled in if you already have a form, and simply want to add one or more hidden fields to it.
For example:
dialog.form.hidden_make({script="applebapple"}) or
dialog.form.hidden_make({script="applebapple"}, dialog.form.simplename)

Dialogs (old, deprecated system, fully removed in Ved 1.5.2)

dialog.new(message, title, showbar, buttons, questionid)

message is the body of the text box.
title will be shown in the title bar (if the title bar is shown by setting showbar to 1, which is always done in Ved. In fact, as of 1.4.0, the showbar parameter has no effect anymore). The title is often set to an empty string in Ved.
buttons decides what buttons are shown, and questionid decides what to do with the button that is pressed, 0 to take no action. The question ID system is not optimized for plugins, but the new dialog system allows plugins to specify their own question handlers for dialogs.

Dialog buttons

The fourth argument of dialog.new (called buttons above) can be set to one of the following values V:

(6 has been added in Ved 1.3.0)

Text input

General text input can be started by a single call to startinput(). There's also a function startinputonce(), which can be used if you decide to do it in update/drawing code, but expect me to remove that sooner or later. Input can be stopped (or locked) by calling stopinput(). The text input to the left of the cursor can be found in input, and text to the right of the cursor can be found in input_r. The variable __ (two underscores) contains the text cursor and the text to the right of it. So, to display the input field, you can concatenate input and __ (input .. __).

It's also possible to include text boxes in dialogs, see the above part on fields in dialogs.

Hotkeys

If you didn't know already, you can hold F9 to reveal hotkeys.

showhotkey(hotkey, x, y, align, topmost, dialog_obj)

hotkey is the code (or sequence of codes) for the hotkey in question. More on what these codes are later. This is required.
x is the x-position of the hotkey. This is required.
y is the y-position of the hotkey. This is required.
align can be either one of ALIGN.LEFT (default), ALIGN.CENTER, or ALIGN.RIGHT, and will align the hotkey appropriately.
If you are calling this from a dialog, you will need to pass the next two arguments (and consequently, will need to pass align as well):
topmost is whether the given dialog is the topmost dialog or not. You should be in a cDialog drawing function and just pass the topmost from that function.
dialog_obj is the dialog object the hotkey is located on. You should be in a cDialog drawing function and just pass the self from that function.

Hotkey check function

The following function can be used in button UI elements, to easily add a functioning hotkey to a button. This function will return an anonymous function which returns true if the given hotkey, in combination with a modifier key if specified, is pressed.

hotkey(checkkey, checkmod)

checkkey: The key constant to check.
checkmod: Optional. If specified, the key constant to additionally check. This is passed to keyboard_eitherIsDown, which means 'l' and 'r' variants are checked.

keyboard_eitherIsDown(...)

Hotkey codes

Each symbol in the hotkey font, tinynumbersfont, is actually mapped to one specific character, and is case-sensitive.

What this means is that, for example, a is Alt, but A is just the letter A. In fact, 0-9 and A-Z (uppercase) are all just themselves, along with a lot of other characters. You can also easily combine symbols togetter like so: aS would simply be Alt+S, and show up as such accordingly.

In the following list of usable symbols, a character is simply itself if it has no text saying otherwise:

• 0 through 9
• A through Z
• ,
• .
• ~ is blank, and simply adds a bit of extra space.
• { is a flag, facing right.
• } is an arrow, pointing right. (This is different from x because this arrow's vertical position is at the top of the line.)
• c is Ctrl. This is the Cmd symbol on macOS, Strg if your language is set to German, and the Cmd symbol if your language is set to German on macOS.
• s is Shift.
• a is Alt.

• q is F1.
• w is F2.
• e is F3.
• r is F4.
• t is F5.
• y is F6.
• u is F7.
• i is F8.
• o is F9.
• p is F10.
• k is F11.
• l is F12.

• <
• >
• /
• [
• ]
• z is an arrow pointing left.
• x is an arrow pointing right. (This is different from } because this arrow is vertically centered in the line, as opposed to }.)
• n is the arrow symbol for Return, or Enter.
• b is Esc.
• f is Tab.
• +
• -

GUI elements

DrawingFunction(func)

This element simply calls a drawing function func(x, y, maxw, maxh). This function may return its actual width and height, and must do so if it's in a container that expects width and height.

FloatContainer(el, fx, fy, maxw, maxh)

Container that puts a sub-element at completely custom coordinates.

AlignContainer(el, calign, cvalign)

Aligns its sub-element left/center/right and top/center/bottom depending on parent maxw and maxh.
calign: One of ALIGN.LEFT, ALIGN.CENTER or ALIGN.RIGHT
cvalign: One of VALIGN.TOP, VALIGN.CENTER or VALIGN.BOTTOM

ScreenContainer(els, cw, ch)

Simply holds more elements as though this is another root.
cw / ch: container width and height. nil to fill the remaining parent width/height.

ListContainer(els_top, els_bot, cw, ch, align, starty, spacing, starty_bot, spacing_bot)

Vertical list container. Elements from the top are displayed at starty, elements from the bottom are starty_bot pixels away from maxh given in the draw function. If the maxh given to the draw function is infinite (nil), then bottom elements are not shown.
cw / ch: container width and height. nil to fill the remaining parent width/height.
align: the horizontal alignment of the elements. Can be ALIGN.LEFT, ALIGN.CENTER or ALIGN.RIGHT. Centered by default. This argument was added in Ved 1.8.5.
spacing: the spacing between each top element
starty_bot: if not given, this defaults to starty.
spacing_bot: if not given, this defaults to spacing.

HorizontalListContainer(els_left, els_right, cw, ch, align, startx, spacing, startx_right, spacing_right)

Horizontal list container. Works the same as a vertical list container, but "top" and "bottom" correspond to "left" and "right", and align is the vertical alignment of the elements (can be VALIGN.TOP, VALIGN.CENTER or VALIGN.BOTTOM)

RightBar(els_top, els_bot)

A right-aligned vertical list container with a width of 128, and starty and spacing of 8.

Spacer(w, h)

Filler element that just takes space.

LabelButtonSpacer()

Filler element the size of a LabelButton.

LabelButton(label, action, hotkey_text, hotkey_func, status_func, action_r, hotkey_r_func)

A clickable button with a text label. If clicked or the hotkey is used, the function action is run.
hotkey_text: The displayed hotkey when holding F9. Displayed in the tiny numbers font.
hotkey_func: A function that takes a key as argument (from love.keypressed(key)) and returns true if this button's hotkey is pressed (so that action will run). There is a convenience function hotkey(checkkey, checkmod). For more about that, see the section about it above. Example: hotkey("escape")
status_func: A function that can have three return values indicating the button's status: shown, enabled, yellow. If nil, shown and enabled default to true, yellow defaults to false.
action_r: A function to run when the button is right-clicked.
hotkey_r_func: Similar to hotkey_func, but returns true if the hotkey is pressed for executing the "right-click" action.

ImageButton(image, scale, action, hotkey_text, hotkey_func, status_func, action_r, hotkey_r_func)

A clickable image (scaled scale times) that will appear dimmed or normal depending on whether the cursor hovers over it. For argument descriptions, see LabelButton.

InvisibleButton(w, h, action, hotkey_text, hotkey_func, status_func, action_r, hotkey_r_func)

A clickable button that is not displayed. For argument descriptions, see LabelButton.

EditorIconBar()

A horizontal list container with image buttons for undo, redo, cut, copy and paste.

Text(text, color_func, sx, sy)

This was added in Ved 1.8.5.
A text displayed via ved_print. text can be either a string, or a function returning a string. color_func may be a function that returns R, G, B, and optionally A values (0-255). sx and sy are horizontal and vertical scale values (default 1).
All arguments are optional except text.

WrappedText(text, maxwidth, align, color_func, sx, sy)

This was added in Ved 1.8.5.
A text displayed via ved_printf. text can be either a string, or a function returning a string. If maxwidth is not given, the remaining parent width will be filled. align is passed to ved_printf/love.graphics.printf. color_func may be a function that returns R, G, B, and optionally A values (0-255). sx and sy are horizontal and vertical scale values (default 1).
All arguments are optional except text.

Changelog of breaking codebase changes

Ved 1.8.4 introduced some pretty major changes in the code, which probably broke a lot of plugins. I thought it might be a good idea to finally start documenting breaking "API" changes at this point, instead of having everyone figure them out as commits go by and new versions get released. So this log starts at 1.8.4 and is intended to give an overview of changes that are likely to break plugins.

Depending on how likely I think changes are to break plugins and depending on the weather, changes may or may not get listed here. I'll probably list a lot that isn't necessary, and on the other hand there will probably be some changes I didn't imagine would affect anyone but turn out they do (especially when plugins find-and-replace too large blocks of code or something).

Numbers at the start of list items indicate relevant pre-versions in which the changes were introduced.

1.8.4

• [01] main2.lua has been removed, now all LÖVE callbacks are in appropriately-named callback_*.lua files.
• [03] UI code (in uis/) is now no longer one file per UI, but one folder per UI. ui.load(), ui.elements, et cetera are now in dedicated files that return those callbacks/the elements table: uis/NAME/load.lua, uis/NAME/elements.lua, ...
• [03] drawhelp.lua → uis/help/draw.lua
• [03] drawlevelslist.lua → uis/levelslist/draw.lua
• [03] drawmaineditor.lua → uis/maineditor/draw.lua
• [03] drawmap.lua → uis/map/draw.lua
• [03] drawscripteditor.lua → uis/scripteditor/draw.lua
• [03] drawsearch.lua → uis/search/draw.lua
• [13] Most Image objects created in love.load() are now prefixed image. (like image.undobtn instead of undobtn).
  Some were also renamed: [un]selectedtoolborder → image.[un]selectedtool, solid[half]img → image.solid[half].
  platformimg and platformpart were removed, these were used in Vis

1.8.5

• [01] Some random identifiers were changed from justconcatenatedtogethercase to snake_case, but probably not extensively-used ones (like uniquenotename → unique_note_name or getalllanguages → get_all_languages)
• [03] ListContainer and HorizontalListContainer elements now have an align argument added after ch. Before this, elements in list containers were always horizontally/vertically centered, now this is just the default.
  Old vs new signatures:
  ListContainer(els_top, els_bot, cw, ch, starty, spacing, starty_bot, spacing_bot) (old)
  ListContainer(els_top, els_bot, cw, ch, align, starty, spacing, starty_bot, spacing_bot) (new) HorizontalListContainer(els_left, els_right, cw, ch, startx, spacing, startx_right, spacing_right) (old)
  HorizontalListContainer(els_left, els_right, cw, ch, align, startx, spacing, startx_right, spacing_right) (new)
• [05] Using input to carry state in dialogs is now strongly discouraged in favor of DF.HIDDEN fields (with dialog.form.hidden_make(...))
• [05] All instances of rvnum have been replaced by script_i (or in the help system, article_i
• [08] The help system no longer reserves the first article for the Return button, and the formatting code ) has been removed

1.9.0

• VVVVVV-CE support has been removed, so any functions accepting arguments like altstate, custom graphics sets, etc will lack that argument:
  [02]
  tileset_image(themetadata, chosentileset, customtileset) (old)
  tileset_image(themetadata, chosentileset) (new) [04]
  drawentitysprite(tile, atx, aty, customspritesheet, small) (old)
  drawentitysprite(tile, atx, aty, small) (new) displaysmalltilespicker(offsetx, offsety, chosentileset, chosencolor, customtileset, scale) (old)
  displaysmalltilespicker(offsetx, offsety, chosentileset, chosencolor, scale) (new) insert_entity_full(rx, ry, astate, intower, subx, suby, atx, aty, t, p1, p2, p3, p4, data) (old)
  insert_entity_full(rx, ry, atx, aty, t, p1, p2, p3, p4, data) (new) [05] focused on altstates, which were originally added in 1.8.0-pre22 and 1.8.0-pre23. The altstate arguments were optional and defaulted to the main state if nil/not specified.
  displayentities(offsetx, offsety, myroomx, myroomy, altst, bottom2rowstext) (old)
  displayentities(offsetx, offsety, myroomx, myroomy, bottom2rowstext) (new) getroomcopydata(rx, ry, altst) (old)
  getroomcopydata(rx, ry) (new) setroomfromcopy(data, rx, ry, altst, skip_undo) (old)
  setroomfromcopy(data, rx, ry, skip_undo) (new) rotateroom180(rx, ry, altst, undoing) (old)
  rotateroom180(rx, ry, undoing) (new) gotoroom(rx, ry, altst) (old)
  gotoroom(rx, ry) (new) roomdata_get(rx, ry, altst, tx, ty, uselevel2) (old)
  roomdata_get(rx, ry, tx, ty, uselevel2) (new) roomdata_set(rx, ry, altst, tx, ty, value) (old)
  roomdata_set(rx, ry, tx, ty, value) (new) roomdata_set(rx, ry, altst, values) (old)
  roomdata_set(rx, ry, values) (new)
• [05] next_key(t, c) was removed, but I'm willing to bet no plugin was using it. ("Return the lowest key in table t that is higher than c. If not found, return nil.")
• [19] hoverrectangle(...) now returns whether the rectangle was hovered over, for convenience
• [19] Due to the script editor switching to the new input system, scriptlines and editingline are now no longer used. Instead, inputs.script_lines is the input, and when it's not appropriate to edit that directly, a copy of the table is made instead.
  processflaglabels() and processflaglabelsreverse() now both take the script as argument: processflaglabels(raw_script) and processflaglabelsreverse(readable_script).
  processflaglabels now returns the "human-readable" script (readable_script).
  processflaglabelsreverse used to return true if it failed due to running out of flags to allocate, now it returns success as a first argument and the "raw"/"VVVVVV-parser-readable" script as the second argument (raw_script). success can be false if it ran out of flags, or splitting internal scripts failed.
• [20] In addition to the above, processflaglabels is now called script_decompile, and processflaglabelsreverse is now called script_compile.
• [27] Tilesets have been refactored a little:
  tilesets[file].tileswidth and tilesets[file].tilesheight have been snake_cased to .tiles_width and .tiles_height.
  .total_tiles has been added. This is .tiles_width * .tiles_height.
  .tiles_width_picker and .tiles_height_picker have been added to indicate what the dimensions should be in the tiles picker (only different from .tiles_width and .tiles_height if .tiles_width is higher than 40.)
  Note that .total_tiles may be less than .tiles_width_picker * .tiles_height_picker.
• [27] The tilesetnames table has been replaced by tileset_names and now works differently. tilesetnames mapped from tileset file number 1, 2 or 3 to the filename of that tileset file. It was never used without the usedtilesets table, which maps from chooseable tileset numbers (Space Station, Outside, ... being 0, 1, ...) to tileset file number 1, 2 or 3. tileset_names now maps directly from chooseable tileset number to the corresponding filename. Thus, the hellish tilesets[tilesetnames[usedtilesets[selectedtileset]]] can be written a little shorter as tilesets[tileset_names[selectedtileset]].
• [38] Various names of tables and functions have been snake_cased:
  listmusicnamesids → list_music_names_ids
  listmusicnames → list_music_names
  listmusicids → list_music_ids
  listmusiccommandsnamesids → list_music_commands_names_ids
  listmusiccommandsids → list_music_commands_ids
  musicsimplifiedtointernal → music_simplified_to_internal
  listsoundids → list_sound_ids
  returnusedflags(...) → return_used_flags(...)
  syntaxhl(...) → syntax_hl(...)
  justtext(...) → just_text(...)
  scriptcontext(...) → script_context(...)
  findscriptreferences(...) → find_script_references(...)
  findusedscripts(...) → find_used_scripts(...)
  
• [39] The big block of code at the top of uis/maineditor/draw.lia that handled using the mouse buttons in the main editor (so, all the tools) has been moved to its own file and function, handle_tool_mousedown() in tool_mousedown.lua.
• [39] Entity right-clicking/(shift+)alt+clicking (so, including creating right click menus for entities) has been taken out of entity drawing code (displayentities(...) and displayentity(...)) and moved to its own file and function, handle_entity_mousedown() in entity_mousedown.lua.
• [39] entityrightclick(x, y, menuitems, newmenuid[, sel_w, sel_h[, sel_x, sel_y]]) has been split into entity_highlight(x, y[, sel_w, sel_h[, sel_x, sel_y]]) (for the visual entity border) and entity_interactable(k, x, y, menuitems, newmenuid) (for the right click menus in handle_entity_mousedown().
• [46] Fixed plugin code changes being double-escaped on changing language/font (not a breaking change but may be good to know anyway
• [50] .vvv metadata in the music table is now .vvv_metadata instead of .meta. Some music player functions were renamed:
  getmusicmeta_file → music_get_file_vvv_metadata
  setmusicmeta_file → music_set_file_vvv_metadata
  getmusicmeta_song → music_get_song_vvv_metadata
  setmusicmeta_song → music_get_song_vvv_metadata
  getmusicfiledata → music_get_filedata
  getmusicaudio → music_get_audio
  getmusicaudioplaying → music_get_audio_playing
  getmusicedited → music_get_edited
  

1.10.0 (was 1.9.2)

• [13] Instead of using any code containing the string /available_libs/, prepare_library and load_library from librarian.lua are now preferred.
• [13] The order of initializations in love.load() has been changed a little bit.
• [24] The function directory_exists(where, what) has been changed into directory_exists(path). Use directory_exists(where .. dirsep .. what) if you need to.
• [28] Regardless of LÖVE version, love.mousepressed now never uses "wu" or "wd" constants, and love.wheelmoved is now always used instead. So instead of, on LÖVE 0.10+, redirecting love.wheelmoved to love.mousepressed with "fake" wu/wd buttons, we now, on LÖVE 0.9, redirect love.mousepressed with wu/wd buttons to love.wheelmoved with a "fake" 1/-1 y movement. The love_mousepressed_start hook has been changed accordingly, and a new hook love_wheelmoved_start has been added. This change applies to UIs' and elements' callbacks as well.

Easter eggs