Does not apply to the platformer example (rapier2d) because we are waiting on https://github.com/dimforge/bevy_rapier/pull/272. When that PR is merged I will update this.

Thanks to @nfagerlund for the help with the bevy 0.8 update and lots of troubleshooting.

There's a couple extra major changes here worth pointing out

• no more batch spawning, bevy_ecs_tilemap doesn't really support it in the rewrite. This will probably allow us to simplify the level spawning code, but for now it works.
• all tiles have SpatialBundles and are all children of layer entities. Before, this was only true for tiles with intgrid values and metadata. This helps with despawning levels, but it also makes the hierarchy a little less confusing. It does compromise some performance though, since potentially thousands of entities will now have components that they didn't have before.

Hi. During your example platformer I tried to make the same logic for my own game. But when I've changed LevelSpawnBehaviour::UseZeroTranslation to

LevelSpawnBehavior::{
  load_level_neighbors: true,
}

Before that, all collisions work fine, and the game is 100% legit. But after changing the config all collisions took the wrong position and were placed at the same place as it was for UseZeroTranslation. The same problem with the Ladder collision. When I change the config all collisions for entities also shift.

Do you face that problem during your platformer example? If yes, how to deal with it?

Hi,

Ldtk makes it possible to link data to tiles of a tile-set (either arbitrary text or enum-based)

It would be nice if there was a TileData(or equivalent) component inserted on tiles that have data defined so that we could query them and have logic based on the data we defined in ldtk.

Summary

Adds a new attribute to the LdtkEntity derive macro named with. It allows for bundles to implement custom initializers using a method. This macro takes in a scoped function with signature (e: EntityInstance) -> T where T is the field type.

Example

pub struct Bundle {
   #[with(foo_initializer)]
    foo: i32;
}

fn foo_initializer(_e: EntityInstance) -> i32 {
    4
}

#[derive(Clone, Default, Bundle)]
pub struct ColliderBundle {
    pub collider: Collider,
    pub rigid_body: RigidBody,
    pub damping: Damping,
    ...
}

#[derive(Bundle, Default, LdtkEntity)]
pub struct PlayerBundle {
    player: Player,
    #[with(player_collider)]
    #[bundle]
    collider: ColliderBundle,
}

fn player_collider(_: EntityInstance) -> ColliderBundle {
    ColliderBundle {
        collider: Collider::capsule(Vec2::new(0., -4.), Vec2::new(0., -12.), 5.),
        rigid_body: RigidBody::Dynamic,
        rotation_constraints: LockedAxes::ROTATION_LOCKED,
        damping: Damping {
            linear_damping: 10.0,
            ..Default::default()
        },
        ..Default::default()
    }
}

Issue

The same functionality can be done using from_entity_instance by filtering the identifier to the correct type. However, this could cause function bloat when many entities with different identifiers implement the same bundle. You can have cleaner and safer code separation with this with(function) attribute.

ToDo

• [ ] Ensure type safety of function return; the error messages aren't very good if the function doesn't return the correct type

When running a demo map with auto-layers on Linux Ubuntu 20.04 I'm getting a memory leak that will rapidly expand to using 8GB+ of memory in less than 30 seconds before finally segfaulting.

There's nothing obvious in the logs other than the fact that it happens immediately after LDtk asset creation detected. and nothing happens after that.

demo-map.zip trace_log.txt

Closes #96 Closes #108

This is a pretty major change internally. If you're reading this and want to help me out, please update your games to this branch and let me know here whether or not there are any issues. I would like this to be the final PR before releasing 0.4, and I would like to release 0.4 very soon.

bevy_ecs_ldtk = { git = "https://github.com/Trouv/bevy_ecs_ldtk", branch = "feat/respawn" }

The scheduling has been completely reworked, and some systems have been significantly changed as a result. However, this is definitely an improvement. Many frame-delay issues are addressed by this rework, and hot reloading works again. This change was assisted by a new Respawn component, which can work on world entities and level entities. As a bonus, users can use the Respawn component in their games. I imagine this will mostly be used to restart levels.

The main point of this rework is to be more careful about having stage separation between commands-sensitive, order-sensitive systems. If one adds a particular component to entities, and another filters for those additions, there needs to be a stage barrier between them. Most importantly, if one despawns entities, and another spawns similar entities, there needs to be stage barrier between them. This last point was the main cause for a lot of bugs since updating to 0.8 and the bevy_ecs_tilemap rewrite.

One drawback here is that there's a new stage between update and post-update: LdtkStage::Clean. It's important that this goes before PostUpdate, since it despawns bevy_ecs_tilemap entities, which need to be further cleaned up in PostUpdate. It's also important that this goes after Update so that users can use Respawn and Worldly components without experiencing frame-delay or undefined behavior, and without having to worry about doing anything special with their scheduling. This isn't ideal, but I think it's a small price to pay. Besides, stageless is just around the corner.

Use cases targeted

• Spawning LdtkWorldBundle in startup system
  • Selecting levels with LevelSelection
  • Selecting levels with LevelSet
• Spawning LdtkWorldBundle in non-startup system (State::on_enter)
  • Selecting levels with LevelSelection
  • Selecting levels with LevelSet
• Spawning LdtkWorldBundle with an already-loaded LdtkAsset handle
• Hot reloading levels
• Respawning world with Respawn component
• Respawning level with Respawn component

New schedule (updated c5984fded3e875a42d9daa1e238b3ad964ac8a7a)

• Stage PreUpdate
  • LdtkAsset processor system
    • Reads AssetEvent::Modified and adds Respawn components to entities with those handles
  • level spawn system
    • For any new placeholder level entities, or any that have Respawn components, spawn their contents normally
• Stage LdtkStage::ProcessApi (between update and post update)
  • worldly adoption system
    • Have the grandparents of worldly entities adopt them (no change)
    • Needs to be after Update for frame delay reasons
  • LevelSelection system
    • Updates LevelSet components according to LevelSelection values
    • Needs to be after Update and before the LevelSet system for frame delay reasons
  • LevelSet system
    • For any world entities whose LevelSets have changed, or that have Respawn components, spawn/despawn placeholder level entities as children accordingly
  • Respawn cleanup system
    • Exclusive system at the end of the stage
    • For Handle<LdtkAsset> entities with Respawn components, despawns all of their children with Worldly or Handle<LdtkLevel> components
    • For Handle<LdtkLevel> entities with Respawncomponents, despawns their descendants.
    • Needs to be after the LevelSet system for frame delay reasons, but before PostUpdate to appease bevy_ecs_tilemap cleanup

Known issues (to be fixed or promoted)

• When using Respawn on a world where a Worldly entity has the only handle to a particular asset via #[sprite_bundle(...)], that asset unloads.

I moved the Bevy dependency to 0.8 and the bevy_ecs_tilemap one to 0.7, then started looking for whatever broke.

~This isn't a complete upgrade and it isn't in proper working condition (the examples still need a Heron bump that isn't out yet, and also I'm still trying to untangle whatever's going on with inherited visibility), but it IS building. And all these changes seem to be things you'd have needed to do anyway, so maybe it'll save you a couple steps.~

This seems to be mostly in proper working order at this point, but the examples (except basic) still need updates, including a Heron upgrade that I think isn't out yet. There's also some outstanding cleanup that needs done and warnings that need dealt w/, which you probably already knew about.

I made a simple game, and when I run the binary build the map loads just fine, but when I build for WASM it doesn't show the map/level

not sure if it's a misconfiguration on my part,

Idk what info do you need to see if it's an actual problem,

but I will leave my repo here

and feel free to ask me anything

(I'm refreshing the page here)

scrnli_7_23_2022_3-39-03 PM.webm

I've been working on a test project with LDtk, and I've noticed that equal colors that match in LDtk do not match when running in bevy. The level background (above the floor) and clear color (below the floor) in this screenshot are both equal to #0D2B45, but when rendered in engine they don't match. Ideally of course, they would match, but I would also be happy with being able to turn off level backgrounds rendering which could allow me to do my own parallax effects for a background in future.

I made minimal changes to the code to make it compile.

I assume TilemapTexture::Single is equivalent to the TilemapTexture behaviour from 0.7.

Closes https://github.com/Trouv/bevy_ecs_ldtk/issues/121

EntityInstance is a rather large struct, and cloning it requires allocating for several fields. Despite this fact, each use of the #[from_entity_instance] attribute was cloning the struct once, wasting CPU time for no good reason - especially for Bundles that contain several #[from_entity_instance] fields.

Change the attribute to work on From<&EntityInstance> instead of From, avoiding the implicit clone in most cases. The clone is still necessary when a plain EntityInstance field exists in a struct deriving LdtkEntity, which is handled by having EntityInstance implement From<&EntityInstance>.

While being a breaking change, fixing up users should be trivial - in most cases no owned EntityInstance is needed at all, and where it is an explicit clone can be inserted.

I can't seem to figure out how to manipulate(or add) a specific tile in a specific layer and level.

The best option I found so far for changing a tiles texture to another is to Query TileStorage but there's no way to know which layer or level the storage references.

It would be very helpful with small examples showing basic manipulation/adding etc.

:robot: I have created a release beep boop

0.6.0 (2022-12-24)

Features

• add LevelSet::from_iid method (#144) (fb17ae1)
• register types GridCoords and LayerMetadata (#146) (ed4a0f9)

This PR was generated with Release Please. See documentation.

The size of the visual area for an entity should only be an indicator to the user about how big it will seem, changing the size should not change where the entity spawned.

This change is how it works in most other engines I've seen deal with it, and I believe it's better to have a defined point which can be seen in the editor to represent the translation of the entity, rather than arbitrarily moving them half way up their visual area.

The transform propagation system runs in the PostUpdate stage, so spawn the levels before PostUpdate so they have time to propagate, but after ProcessApi, so they'll be ready the next frame (assuming the LdtkWorldBundle will be spawned during the Update) stage.

I ran into this bug because in my game I scale the levels, and collision detection is therefore way off during the first frame sending my player character flying.