This is the full-screen widget used both for opening additional levels to be edited, and also for setting the destination level of a teleporter/door object.

The problem is that whilst the title of this screen shows up, the scrollable list of levels beneath it does not.

frogatto/frogatto#74

If you set an object's brightness level to 500, then 100% on the red variable is 500, not 255. However, the set(red, 500) command will still clip the value to 255. It should scale along with brightness.

By default, the button that brings up the offending menu is labelled "rocks" at the moment.

Instead, they seem to just spawn around the upper-left XY corner of the intended particle bounding box.

To reproduce: Rotate something long by 45 degrees, click on the end. (Use the debug console.)

This is something we'll need for proper rotated-objects support, since this function is relied upon for being able to select them in the editor.

i'm having trouble with creating modules -- anytime i do, the engine crashes. running it from the terminal, i end up with a list of candidate searches (whatever those are), and finally the error:

src/level.cpp:623 ASSERTION FAILED: Player object being added to level does not match required >player type. simple_playable is not a obj player_controlled

engine version 1.4
os: kxstudio (ubuntu-derived linux distro)
rig: lenovo thinkpad t520

I'm guessing this is probably an off-by-one error, but at the moment, quite a few objects, on their far edges, are cut off half a pixel too soon. This is most visible on objects that are meant to be used in a tile-like manner, and stacked end-to-end.

If you zoom out to 0.5, and then zoom back to 2.0, this dark rectangle crops the background on the lower-right sides during a little bit of the zooming. This seems to not be an issue from 1.0 -> 2.0, only from further out zooms like 0.5 -> 2.0.

Reproduction:
--level perilous-precipice.cfg, with the player's exact initial standing position
set(level.zoom, 0.5)
set(level.zoom, 2.0)

Both examples here are one pixel (2 with our normal zoom factor) to the left of their intended position.

crevice-village-house-3-backroom.cfg

crevice-village-house-3.cfg

Particles don't seem to process their position (or animation frames) on a "once per cycle" basis, instead only seeming to update their position once per second or so.

Examples include:

• the falling leaves on --level tempo-village.cfg (they're supposed to translate smoothly through the air, rather than jumping position every several seconds)
• the shots from the white flowers on trembling-treetops.cfg (they're supposed to have contrails/tails, rather than being round balls).
• the green particles that are supposed to follow frogatto (as though he's burning) after he falls into acid (acid is present on burning-stone.cfg, down and to the right, and then to the left from the starting pos).
• the fiery sparks which emanate from torches (they're static in position, rather than 'emitting' from the center of the torch and translating outwards)

Strangely, the chimney smoke on --level chopple-shop.cfg works fine, as does the whitewater on tempo-outskirts.cfg. As do the particles on all of frogatto's abilities.

Example levels:
--level nenes-basement.cfg
--level wandering-passage.cfg

Frame in animation isn't settable, while time in animation is. To set the frame, you have to employ a hack where you set time_in_animation to the frame, and then the frame duration of the animation to 1. Because this now constantly advances (it has to, setting the time wouldn't work if it didn't advance over time), you have to maintain the state each cycle.

More more error on xcode6 and use master branch, I changed more file, I can't fix them, But debug version hasn't error.

some error.

include <GL/gl.h> => <OpenGL/gl.h>

and Graghics::color must include head file.

Don't know how fix it, I have no study boost.
anura/MacOS/boost/smart_ptr/intrusive_ptr.hpp:91:23: No matching function for call to 'intrusive_ptr_add_ref'

When executing the following statement in the debug console, the game crashes without telling us why. The problem is that debug('hi') needs to be a quoted string, not a bare command.

EVALUATING: set(event_handlers.process, debug('hi'))
OUTPUT: (0x6d583a0){Uninspectable Object: commands}
anura: /usr/local/include/boost/smart_ptr/intrusive_ptr.hpp:162: T* boost::intrusive_ptr::operator->() const [with T = game_logic::formula_expression]: Assertion `px != 0' failed.
Aborted (core dumped)
david@ubuntu:~/anura$

The draw region seems to be translating unevenly. As the waterfall plays, the texture becomes repeated more and more, vertically, in the same amount of space.

Our metrics for the draw-regions of the waterfall parts have always seemed a little fishy to me, so if this is a correction to the underlying engine, rather than a bug, then by all means, point out what's wrong in the FFL. It behaved correctly in the prior rendering engine, but the numbers I had to apply to the draw region to get it to render correctly seemed to be of mismatching magnitudes with the actual pixel dimensions of the sprites in question.

We don't use this much, only for ropes and waterfalls (and a few chains), and very few of these translate the draw region, so it's not outside the realm of possibility that the way the engine worked before wasn't correct.

--level starlit-cave.cfg, over on the far right side

Sometimes it's invisible, sometimes its the wrong color. In neither case is it drawing the solid line on the top.

For what it's worth, I actually would have no problems with switching to a system where displaying this is not done by a special engine feature, but is instead done by drawing primitives via FFL. I have a number of things I'd like to improve about the display of water (including adding some entirely new kinds of liquid), and the current baked-in engine feature doesn't give me the flexibility I need to do them.

--level celadon-clearing.cfg (down and to the left from the starting position)

--level to-nenes-house.cfg (down and to the right from the starting position)

For example, I had a statement wherein arg.collide_with is defined by the engine as custom_obj|null
on_add_object_fail: "if(not arg.collide_with is null, (arg.collide_with.hitpoints yadda yadda))",

It would complain that arg.collide_with.hitpoints's left side might be null. However, it's clearly inferred that it's definitely not possible to be in that statement if arg.collide_with was, in fact, null.

Two other filters: if(arg.collide_with != null and if(arg.collide_with is custom_obj do correctly work.

We need the same sort of behavior we have for flipping sprites horizontally. We usually offset the solid areas vertically because a lot of sprites need "breathing room" above them to do animations.

Right now, this causes anything which we flip vertically to behave very oddly - often having solid areas right in the way of the only viable "opening" they have for the player to shoot towards them through (this basically acts as a shield for many of the creatures flipped upside down, making it rather hard to fire projectiles at them).

Linux mint 16. Launching game from terminal.

After exiting Citadel for the second time the terminal font color is all black and only rebooting fixes it.

Example on -level burning-stone.cfg, down and to the right.

The compound parts look fine when they're closed:

but when you open them up, the backing object slides around wildly. The solid area also moves in a way that causes them to be impassible at walking level.

The function next_pow2(size_t) in raster.cpp, introduced in commit 0edaeb0, appears to assume that size_t is an unsigned 32-bit integer — specifically, it uses, without modification, the algorithm from https://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2, which is explicitly for unsigned 32-bit integers.

The fullscreen mode does transition in correctly, and the rest of the screen blacks out; it's just that the whole of the final fullscreen window isn't being used for the game.

Running on a mac with OS 10.10.3

When using the "Add Object" tool, objects being placed do not display a partially transparent 'ghost' version of the object under the cursor, indicating where they're going to be placed, before you click the button to actually place an object in that location.

The mouse wheel scroll, in the editor, only works if the mouse is inside the level bounds as drawn on screen. The key controls for zooming work correctly.

I'm running Debian Jessie, and I compiled Anura (cloned 4/13), and using the frogatto module from the Debian repositories, I get

INFO: graphical_font.cpp:196 : LOADING FONT: data/base_fonts.cfg -> data/base_fonts.cfg
INFO: graphical_font.cpp:196 : LOADING FONT: data/fonts.cfg -> modules/frogatto/data/fonts.cfg
ERROR: main.cpp:945 : ERROR PARSING: PARSE ERROR: data/fonts.cfg: Could not find file data/label_font.cfg
INFO: checksum.cpp:89 : EXITING WITH UNVERIFIED SESSION

Copying the contents of /usr/share/games/frogatto/data/ into my build of Anura doesn't help.

I messed up my install of Frogatto somehow, so disregard that.
However, once I copy /usr/share/games/frogatto/data/ into my build of anura, I get

ERROR: SurfaceSDL.cpp:654 : Failed to load image file: 'splash.jpg' : Couldn't open images/splash.jpg
ERROR: SurfaceSDL.cpp:654 : Failed to load image file: 'gui/iphone_controls4.png' : Couldn't open images/gui/iphone_controls4.png
terminate called after throwing an instance of 'KRE::ImageLoadError'
Aborted

I'm not sure why it wants iPhone-specific data to launch on Debian.

On a previous build, I got to the title screen, but Frogatto wouldn't move, and I got a fatal error after pressing some keys. I'll try to replicate it but i'm not sure if I can.

The palette of tile types normally displays small preview rectangles of a given set of tiles (the patches in question are defined in editor.cfg, since they're not always rectangles for certain tile types that don't support rectangular placement).

The textures used by these are garbled in the new rendering engine.

frogatto/frogatto#108

frogatto/frogatto#83

set_event_to_false_upon_being_released: { type:"bool", default: false, editor_info: { type: "bool", value: "false" } },

Also:
bool is the name of the true/false data type in anura, but in the editor_info block, it's not a recognized symbol. Editor_info apparently only recognizes boolean instead, and treats anything it doesn't recognize as an int. It would be nice to make the editor conform to core anura in this naming convention.

Description

When running with a custom locale on Linux, such as LANG=foo ./game, the engine may crash saying

terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted (core dumped)

Solution

This appears to be a bug in some versions of boost::filesystem. The error does not occur if the locale is listed in the output of locale -a. How to add an locale in this list is distro-specific:

On Arch Linux, edit /etc/locale.gen and uncomment the wanted locales, and then run locale-gen as root.

On Ubuntu, run locale-gen <wanted-locale> as root.

Boost tickets

• #8930
• #5928 (closed)
• #4688 (closed)

When creating a new module with
Identifier: test
Name: test
Prefix: test

I get:

INFO: level.cpp:224 : in level constructor...
CRITICAL: load_level_nothread.cpp:61 ASSERTION FAILED: FILE NOT FOUND: test:titlescreen.cfg

I get this whether or not I use frogatto as a dependency, and also if I remove the prefix.

I get the same error if I create the module without Frogatto as dependency and load it after the crash.

However, If I add the Frogatto module as a dependency, and load it after crashing, I get:

CRITICAL: formula_function.cpp:3581 ASSERTION FAILED: Writing to value with invalid type obj player_controlled|null <- custom_obj in set(child.stored_player, level.player) At modules/frogatto/data/level/General/titlescreen.cfg 75:
set(child.stored_player, level.player),

Right now when a sprite is rotated, its various interaction/damage areas are not rotated with the sprite. This has been somewhat harmless on small sprites like frogatto uses (though not entirely harmless), but generally is a fairly serious engine limitation, because it prevents us from implementing a wide variety of game genres where they rely on large shot/object graphics, viewed in a directly top-down perspective, and rely on being able to freely rotate them in any direction to save on art costs.

A side effect of this is that we haven't implemented many 'long' shots in frogatto (except for one or two which travel horizontally), because they wouldn't work correctly in a diagonal direction.

It has a few side effects on existing behavior, though, some of which are confusing to new players who don't understand our internal engine workings, and can't guess as to why something happens the way it does. For example, ants are hitboxed so that their mandibles are the only threatening part - however, if the player bumps into their mandibles whilst an ant is ascending a slope, the hitbox is not rotated, and thus, is fully below the player. The result is that, because of this inconsistency, players can't suss out the rules for why we are/aren't dealing damage, and it just seems to them that our hitbox code is buggy - i.e. "sometimes ants hurt me, and sometimes they don't, and I can't figure out why".

The editor, when saving files, updates all the _addr in the file, resulting in very large diffs, which means that bugs, omissions and regressions are harder to detect.

Repro steps seem to be: open celadon-clearing, zoom way out, select the tile-rectangle tool, and delete all the tiles on the right half of the level. This takes a few steps to trigger for me, sometimes, but usually after at least 10 or so tile add/delete operations it'll always consistently trigger.

Thread 1Queue : com.apple.main-thread (serial)
#0      0x0000000100607e71 in GarbageCollectible::~GarbageCollectible() at /Users/richard_kettering/Public/anura/src/formula_garbage_collector.cpp:59
#1      0x0000000100447d82 in std::__1::__value_type<int, TileMap>::~__value_type() [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:617
#2      0x0000000100447d79 in std::__1::__value_type<int, TileMap>::~__value_type() [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/map:617
#3      0x0000000100447d79 in void std::__1::allocator_traits<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*> > >::__destroy<std::__1::__value_type<int, TileMap> >(std::__1::integral_constant<bool, false>, std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*> >&, std::__1::__value_type<int, TileMap>*) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:1589
#4      0x0000000100447d79 in void std::__1::allocator_traits<std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*> > >::destroy<std::__1::__value_type<int, TileMap> >(std::__1::allocator<std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*> >&, std::__1::__value_type<int, TileMap>*) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:1487
#5      0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1445
#6      0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1443
#7      0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1443
#8      0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1443
#9      0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1443
#10     0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1443
#11     0x0000000100447d79 in std::__1::__tree<std::__1::__value_type<int, TileMap>, std::__1::__map_value_compare<int, std::__1::__value_type<int, TileMap>, std::__1::less<int>, true>, std::__1::allocator<std::__1::__value_type<int, TileMap> > >::destroy(std::__1::__tree_node<std::__1::__value_type<int, TileMap>, void*>*) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__tree:1443
#12     0x000000010043b302 in std::__1::__function::__func<std::__1::__bind<void (&)((anonymous namespace)::level_tile_rebuild_info*, std::__1::map<int, TileMap, std::__1::less<int>, std::__1::allocator<std::__1::pair<int const, TileMap> > >, threading::mutex&), (anonymous namespace)::level_tile_rebuild_info*, std::__1::map<int, TileMap, std::__1::less<int>, std::__1::allocator<std::__1::pair<int const, TileMap> > >&, threading::mutex&>, std::__1::allocator<std::__1::__bind<void (&)((anonymous namespace)::level_tile_rebuild_info*, std::__1::map<int, TileMap, std::__1::less<int>, std::__1::allocator<std::__1::pair<int const, TileMap> > >, threading::mutex&), (anonymous namespace)::level_tile_rebuild_info*, std::__1::map<int, TileMap, std::__1::less<int>, std::__1::allocator<std::__1::pair<int const, TileMap> > >&, threading::mutex&> >, void ()>::destroy_deallocate() at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1362
#13     0x000000010041beb6 in Level::complete_rebuild_tiles_in_background() at /Users/richard_kettering/Public/anura/src/level.cpp:981
#14     0x000000010021f04b in editor::process() at /Users/richard_kettering/Public/anura/src/editor.cpp:1368
#15     0x000000010046be14 in LevelRunner::play_cycle() at /Users/richard_kettering/Public/anura/src/level_runner.cpp:858
#16     0x000000010046b900 in LevelRunner::play_level() at /Users/richard_kettering/Public/anura/src/level_runner.cpp:772
#17     0x0000000100496f61 in main at /Users/richard_kettering/Public/anura/src/main.cpp:1044
#18     0x0000000100001cc4 in start ()

One of the things I've wanted to do since the early days of frogatto has been to have vertical backgrounds made with banks of clouds, which repeat indefinitely along the y-axis. We now have the code to allow backgrounds to repeat vertically, but we do not have the code to insert large areas of empty transparency between vertical objects. We have this for the x-axis; we can separate repetitions of an individual cloud on the x-axis by, say, 1500 pixels, using the xpad key.

We do not have this on the y-axis, and the only way to do it, currently, is to waste an enormous amount of video ram by padding the individual sprite by the desired amount of blank space.

It would be nice to have a ypad key which did the same thing, on the y-axis.

There's a button to make all the selected items a member of a given group, but there's not a way to remove them from that group once added (you have to delete the objects entirely). There is no "Ungroup Objects" button.

when creating modules in the anura engine (pulled 02/18/15), the engine promptly crashes, yielding the error:

src/custom_object_type.cpp:746 ASSERTION FAILED: Could not find file for object 'simple_playable'

os: kxstudio (ubuntu-derived, rolling release)
system: thinkpad t520

We have code that tightens our sprites in memory by shrinking their rectangular area just enough to omit any rows and columns which are composed purely of transparent pixels. This is always active, but one of the intents for this, besides lightening our blitting and video memory load, was to deal with one necessary step in creating texture atlases. I believe the optimization goal (minimizing memory usage at all costs) was a bit too aggressive, in light of the current engine goal of making anura accessible to people interested in game-making, because this breaks object rotation and scaling unless the programmer specifies a workaround flag.

If you're new-ish to anura, and you don't know about this flag, you may try to rotate or scale an object, and be dismayed when it doesn't work correctly. Because the nature of it not working correctly (incorrect centering) is a seemingly shallow implementation mistake, I worry most users will jump to the conclusion that our engine is unfinished and buggy, rather than realizing we have a specific workaround for that. Rotation isn't something that should need a wiki article, or a caveat - it's a common feature in sprite-graphics engines, with some level of expected behavior (like rotating around the middle if a rotation point isn't specified).

Right now, of course, we flag an object animation with no_remove_alpha_borders: true to completely turn off this feature. Unfortunately, because we apply this to absolutely every object that rotates or scales, we've had to apply this to a total of ~100 objects so far.

Suggested Fix:

I think we can get the best of both worlds, though, by tweaking the feature - by simply limiting our current "border shrinkage" such that it doesn't reduce an object's area beyond the point where doing so would alter the midpoint. For most objects, this would mean we'd still remove ~98% of the unused alpha borders around the sprite. But moreover - we'd be able to bring possibly all objects currently flagged with no_remove_alpha_borders back within the fold - as long as their midpoint was preserved, it would be okay to cull significant portions of their sprites.

Not only would this make anura easier to use, it would open up the possibility of applying rotation to arbitrary objects in the editor (something that may be very desirable for games other than frogatto - a good example of why this would be desirable would be the following video showing aquaria's editor: http://youtu.be/bsT6otdcTv0 ).

SDL2main.a is not in Arch Linux's SDL2 package, so the linking phase fails. Removing -lSDL2main in the LIBS line in Makefile fixes this issue (it already uses pkg-config --libs sdl2).

So after finishing compiling the engine, I wanted to run it with Frogatto's data. I downloaded the data from the GIT, and ran the application, but I got this:

$ ./anura
Frogatto engine version 1.4
Build Options: box2d isomap save_png sdl2 shaders svg
LOOKING IN 'modules/frogatto/module.cfg': 1
SET PREFERENCES PATH: ~/.frogatto/
PARSE ERROR: : Could not find file /home/andoru/.frogatto//dlc/lib_2d/module.cfg
PARSE ERROR: : Could not find file /home/andoru/.frogatto//dlc/lib_2d/module.cfg
terminate called after throwing an instance of 'json::parse_error'
Aborted

Am I missing something?
Running on CrunchBang 11 "Waldorf" x86 with Unstable Debian Repos

In a number of cases we use transient dialogues (like a character saying "Hi!") to get the player's attention that there's an optional dialogue to be had. If they really quickly run up and start this dialogue, it's possible to start it before the transient dialogue ends, making the transient dialogue re-appear after the regular conversation finishes.

frogatto/frogatto#78

Having the ability to manually set an object instance's zorder in the editor would be helpful - it wouldn't get much/any use in frogatto, but would be useful for quite a few other projects that have a different model for how they handle zorders.

The editor_changed_variable event isn't fired when the object is moved with the mouse. It only fires when a variable in the side-bar is changed.

It can't check if the event in question exists, since those are our provision for 'duck type' message sending (do something if it's present, ignore it if its not), but at least checking if we're not blindly firing it at a non-existent prototype (done by either typoes, or getting the parameter order wrong) would solve a lot of "why is this doing nothing?" problems.

Normally object blitting gets flipped horizontally if an object's facing is set to -1. If a "custom_draw" transformation is ever applied to an object, from that point on it stops flipping the blitting (even if the custom_draw is basically reset to an 'identity' transform), regardless of what direction the object is facing in. Repro examples:

• mushroom springs on the-empty-place.cfg
• gazers on risky-ridge.cfg

There's another row I've highlighted in red, which is inaccessible. Previously I used to work around this bug by resizing the editor window, but ever since the new rendering engine was put in, we can't resize the window.

Our background parallax layers don't correctly orient themselves when the camera is zoomed; they actually slide around quite a bit, as though their xy offsets aren't being re-calculated to accommodate for the new zoom factor. This has been less of an issue in the past, with flat-color backgrounds, but with our newer, more detailed backgrounds, and with our increasing use of cinematic camera pans and zooms, this is really starting to look more and more bizarre, and needs to be fixed.

Two common zoom factors this needs to work correctly for are 0.5, and 2.0.

It's possible to turbo-skip through several lines of dialogue by holding the arrow keys (or pretty much any other key).