Backwards Compatibility for community Beta levels

Backwards Compatibility and Community Levels in Dreams

Between the Dreams Beta and Early Access we’ve been hard at work fixing bugs and making improvements to Dreams. As we continue to chase down bugs and add new features throughout Early Access and beyond there will sometimes be knock-on effects to community made content as a result. This means content you’ve made may have broken bits or issues may occur over time.

We try to identify those issues prior to releasing new code but with so much user generated content it’s simply not possible for us to test absolutely everything. With that in mind, we want to give our creators as much information as possible to help fix and repair anything that has broken.

If you are returning to Dreams from Beta and you have published content please read on for backwards compatibility issues we have already identified and how to log your own backwards compatibility issues for us to investigate in our feedback forums. And remember, always test your content before publishing. You can always note any issue or bugs in the version notes to help players who use your content.

What do I do if my content is broken?

Keeping your content working through code revisions is very important to us and we try to identify issues in advance of rolling out new code. How that code affects you and your content may vary depending on what the issue is and how we have chosen to address it. If your content relied on or worked around a particular bug that we later fix, your content will need to be repaired.

If your content is broken, you can get assistance in this Backwards Compatability forum. Please note we cannot make content fixes for you, but we can give examples and information to help you identify solutions and resolve issues. The threads in this forum also contain useful videos and pictures to help you resolve your issues.

When you submit an issue, please note the following:

  • Investigating and resolving backwards compatibility issues is time consuming. Please review existing issues in backwards compatability forum before writing your own. If multiple threads on the same issue start to appear we will try to consolidate them.
  • Check the release notes! Release notes for new code may be useful if you are having an issue as you may be able to see that we have changed code for a feature related to your bug. We post all of our release notes on
  • When submitting an issue, let us know the name of the level, how it behaved prior to the new code change and how it behaves now. The more information you provide, the more helpful we can be!
  • Resolving your issue may require a retroactive code fix. What this does is look at when a piece of content was made (date/time) and what code it was running on. If content is being played and that version has a timestamp before the code change, the game will run the level with the old code. People can play it and everything will work as it did before.
    • As soon as the content’s owner or a collaborator edits the content the timestamp will be updated to after the code change and the new code path will run. The level will begin to exhibit the backwards compatibility issue and a further content change will be required by the user to address its effect.
    • Test your content before publishing! If you publish the level without identifying or fixing any backwards compatibility issues, players playing that new version will see the bug (as they are now playing a version timestamped after the code change).

Known Backwards compatibility issues

Issue 1: Puppet Collision Affecting Puppet Handling and Movement

In the beta, a code bug in the physics engine would result in some collisions within puppets being completely ignored. This meant that setting up collisions in puppets was much more forgiving. You could leave collision active on objects you were adding into the puppet without any major issue or even use exaggerated puppet capsule collisions.

If you have made a character or are using a character in your level that has objects within it that have not had their collision (sculpt tweak menu – physics) turned off, these collisions will likely now fight with the puppets main capsule collision (puppet group tweak menu – physics) or the scene, causing issues with handling. The most prominent issues are the character not moving in the direction you push the stick, moving on its own in a random direction or failing to walk over or through a piece of scenery.

We are utilising a retroactive code solution to address this bug, which means users playing versions made before Early Access will not see any issue. Creators who want to edit and build on that content in Early Access will encounter the issue. To resolve the problem the editor will need to edit the puppet and check every object within the puppet group and make sure that collision is turned off.

Video 2: Lefty's bar (click to view)

Another way this bug may present itself is if the puppet capsule collision collides with the environment. It may be that the capsule has been made to touch the ground causing it to collide with stairs or slopes and prevent the puppet walking up them when they would have in Beta.

Tip – for humanoid puppets the capsule bottom is around the knee of the character (allowing it to walk over things). The top is just below the top of the head (allowing it to walk under things) and should be roughly as wide as the shoulders. If you are animating a crouch you may need to animate the capsule shape sliders (puppet group tweaks -0 physics page) to fit through the hole the character is going to pass through.

Video 3: Gears are metal (click to view)

You might have had your puppet crouch into a hole and previously, the collision would allow you to pass through. Now you may need to add a change to the capsule size and height to allow it to pass through the same hole as well as making sure there are no unwanted collisions in the puppet.

Video 4: Cyrus Adventure (click to view)

You may find that the effect is very subtle. The puppet with collisions active on objects within its group judders or pops slightly as these collisions fight with the puppet capsule.

Issue 2: Joint Limits Not Being Respected

Joint limits were not being respected in certain scenarios – this bug has now been fixed. If users have worked around this issue, they can simply go back into the joint tweak menu and change the limits to correctly reflect how they would like the joint to behave.

Video 1: Joint Limits (Creator Beta) (click to view)
Video 2: Joint Limits (Early Access) (click to view)

Issue 3: Teleporter Chaining Behaviour Has Changed

Teleporters teleport an object in a single frame. In the Beta, if the user tried to teleport an object to an object which is also teleporting it may have worked as long as the gadgets sequence matched the teleport sequence. We have made changes that allow blended teleport positions but a side effect is that now teleporting to something that itself is teleporting will always incur a frame of lag regardless of gadget sequence.

In the attached examples, three sculpts are created - teleporters attached to the first and second, then tags attached to the second and third. The teleporters and tags are set such that Teleporter 1 will move to Tag 1 and Teleporter 2 will move to Tag 2 – resulting in all three sculpts being at the same position as the third sculpt.

The third sculpt is then animated and the first and second sculpt will follow it due to the teleporter/tag logic. The attached videos show the amount of lag in Early Access with the first and second sculpts following the third, whereas in the Beta they simply remained at exactly the same positions as the third sculpt (if the gadget sequence matched the teleport sequence).

Video 1: Teleporter Chaining (Creator Beta) (click to view)
Video 2: Teleporter Chaining (Early Access) (click to view)

The most serious example of this chained teleporters issue is occurring in a popular beta level. You can see a low bar fix for this issue here. This fix does have knock on’s to dependant features like reload animations will fail as a result and will require redesign.

Video 3: Teleporter Chaining in Prometheus FPS (click to view)

Issue 4: Respawning Control Sensor Objects/Groups (Non-Puppet Objects)

The behaviour of respawning a group of objects that is being controlled by a controller sensor at a checkpoint has changed. Previously, the group would respawn at the Origin of the group. Which after the group is created the user has no control over. Now groups will respawn with their controller sensor at the checkpoint, with the appropriate orientation as set by the gadget’s tile or widget. This means the position and orientation of your control sensor now matters for respawning.

If you are encountering respawning problems, try changing the position of the controller sensor and ensuring that its tile or widget is aligned correctly for the spawn behaviour you want.

This issue has a retroactive code fix, so if you plan on editing a previously made level you could encounter this issue.

Video 1: Retroactive code behaviour (click to view)
Video 2: Imp Speedway (click to view)
Video 3: Early Access Controller Sensor Respawn (Non-Puppet) (click to view)
Video 4: Non-puppet controller sensor (click to view)

Issue 5: Physics Behaviour Has Changed

The behaviour of the low/medium/high settings of physical objects (eg. sculpts) has changed. This means particular objects may not interact correctly with other objects – in the example video shown, a ball rolls onto a see-saw and passes straight through it. The fix is to tweak the see-saw sculpt and up the physics quality from low to medium. For any instances in which objects are interacting incorrectly with each other, up the physics cost and that should fix it.

Video 1: Physics Behaviour Low (click to view)

The above behaviour will usually occur if there is a thick object with physics that are set too low – conversely, a similar situation can occur if there is an object which is relatively thin with physics set too high. In this case, as shown in the video, reducing the physics cost from high to medium will have the desired effect. If neither of these solutions work, it may be necessary to make your object slightly thicker, however the above two scenarios should cover most instances of this issue.

Video 2: Physics Behaviour High (click to view)

If tweaking the physics quality settings does not work you may have to change your sculpt slightly, like making objects that need to have physical contacts slightly thicker. This can be achieved by entering sculpt mode on the object and using the stretch tool to widen the model.

Video 3: Dream home example (click to view)
Video 4: Drop Slide bowling example (click to view)

Issue 6: Puppet Respawn Behaviour has Changed

The behaviour of respawning puppets has changed. In the Beta, puppets that died but were not possessed would wait until a possessed puppet respawned for their own respawn to trigger. Now, respawn will occur whenever it is triggered. In the example video, there is a possessed puppet along with a puppet with “record possession” on it which jumps off the edge of the level and dies. Previously, this puppet would not respawn - in Early Access, it does. This can be easily fixed, by removing the “is dead” output wired to the Respawn input. The puppet will now behave as before.

Video: Puppet Respawn Behaviour (click to view)

Issue 7: Detection Scope on Trigger Zones and Surface Snap Behaviour

The behaviour for Trigger zone ‘detection scope’ of gadgets that are surface snapped to an object (sculpt/group) has changed – previously, surface snapping a gadget to an object would cause it to consider itself to be inside the scope of that object.

We felt this was too confusing and hard to signpost for users so we removed it. Now gadgets are simply in the scope they are placed. Surface snapping has no effect on this.

In the linked video, the same scenario is shown in the Beta and in Early Access. A microchip containing a trigger zone is surface snapped to a sculpt and another microchip containing a tag is placed in a group (scope) with (but not surface snapped to) another sculpt. In the Beta, setting the trigger zone’s detection scope to “not here” would successfully detect the tag, as the surface snapped trigger zone was considered to be in a different scope, as was the tag grouped with the second sculpt. Now, only the grouped tag is in its own scope. The trigger zone is still in the world/scene scope (the top most scope, there is no scope above this) and so everything else is in a scope within it. Therefore, setting detection scope to “here” will successfully detect the tag in this scenario.

Video 1: Trigger Zone Scope (Beta) (click to view)
Video 2: Trigger Zone Scope (Early Access) (click to view)
How it worked in beta (click to view)
How it now works in Early Access (click to view)

Issue 8: Behaviour of the Advanced Rotator has changed

The behaviour of damping on the advanced rotator has changed. Previously, there was an issue which meant damping on advanced movers was half what the tweak menu reported it to be. Now, a setting of 50% - 100% will produce correct results. However, this fix would have doubled the damping on advanced movers so an upgrade step was added to halve the damping in levels saved before this change. This can cause a backwards compatibility problem if someone has wired directly into damping with overwrite blend mode. In that case, there is no way to double the value coming in because it could be being generated from anything.

Video 1: Advanced Rotator (Beta) (click to view)
Video 2: Advanced Rotator (Early Access) (click to view)

In the bellow user example the user needs to up the strength of the advanced rotator. There is some complex logic controlling the rotator strength. The simplest way to show the solution is to remove wires controlling rotator strength and up the value to 100% this doesn’t take into account the users design though and only serves to demonstrate the change they need to reflect in their logic.

Video 3: Hovercraft controls fix (click to view)

Issue 9: - Text gadget background settings

We have changed the settings for text gadget backgrounds. The result is that some backgrounds that appeared opaque due to stretching the background texture are no longer as opaque and the border no longer stretches in the same way. In most cases this will just be a visual difference and text will still be legible. In other cases this means that the text on the background may be harder to read.

Creator Beta Example 1 (click to view)
Creator Beta Example 2 (click to view)
Video 1: Connie's Adventure (click to view)
Video 2: Dream Home (click to view)

There is currently no content fix for this.

Issue 10: - Sculpt Looseness and Hull Rendering

We have fixed a bug where users could cause the hull of an object to stop drawing. The result is sculpt hulls are now drawing again on sculpts when in beta they did not. This will likely have broken the visuals in games using this draw no Hulls bug

Unfortunately, you will not be able to achieve this effect in the same way as before and may need to find another way to create the desired effect e.g. by using paint instead of a sculpt object.

Video: Classical order (click to view)

Issue 11: - Joints

Joints are complicated, combining physics and constraints they are used in many ways throughout Dreams including in the puppet. Changes between beta and now have resulted in some physics explosions that were not previously present.

Fixing these may require tweaking some joint settings on pre-existing joints or in extreme cases rethinking the joint structure and replacing the joints completely.

Video 1: Hot Air Balloon Ride (click to view)

Another example of joints causing issues is in a pinball game. The joints have been set to 100% springiness. With springiness this refers to how strong the spring is. 100% means the spring is so strong it doesn’t spring. 0% springiness means the spring has no strength and doesn’t spring at all. Users may need to tweak their joints if they are not working and reduce the springiness in order to let the rotator gadgets move it

Video 2: Joint Springiness Pinball Fix-Up (click to view)
Video 3: Joint Springiness (Creator Beta) (click to view)
Video 4: Joint Springiness (Early Access) (click to view)

Issue 12: - Puppet Rigging

The video below identifies a joint issue in a beta character. The issue presented itself as the puppet being unable to move. When we investigated we found that the characters rig had been broken and something had gone wrong with the grouping of the puppets limbs. We know this firstly from looking at the rig page of the puppet group. Here we see that only the hip limb is active. When investigating the limbs we find that the hip limb group contains the rest of the torso. All limbs need to be in the same route scope of the puppet group.

In the example we found we had to remove this erroneous group by scoping into it and pulling out the hip sculpt. We then live cloned one of the torso pieces to make a new hip. Deleted the old torso joints and re-jointed. Once re jointed we double checked the limb assignments on the rig page. Finally moving the old hip sculpt back into position and grouping with the new hip limb

Video: Save our sprouts example (click to view)

Issue 13: - Jointing to a Puppet

The behaviour of jointing to a Puppet has changed. Due to a bug in joint fixup it is possible to scope into a Puppet, create a Connector on one of the body pieces, scope out and connect to an object outside the puppet group scope. This is an illegal joint as you are not meant to be able to joint to the puppet group directly. In the beta this illegal joint would work. In early access the joint will fail to constrain the object

If this behaviour has been utilised to create a first person rig, the best course of action is to remove the connector and move the sculpt into a group with the Puppet’s head, with the option of jointing it to another non-moveable sculpt if it is desired to be moveable.

Video 1: Jointing to a Puppet (Creator Beta) (click to view)
Video 2: Jointing to a Puppet (Early Access) (click to view)
Video 3: First Person Rig Fix-Up (click to view)

Issue 14: Some User Recorded VO is not playing back currently

For users with their system language in anything other than English, user-recorded VO and sound effects from the Beta may not be playing back correctly. There is a simple fix for this – open up the tweak menu of the sound effect and select, navigate to the Options menu and un-select Multi-Language (Mehrspraching as shown in the video). This will remove any kind of localisation on your recorded audio.

If you wish, you can also leave Multi-Language on and open up the Slice Mapper of your Sound Gadget then change the language setting to default – this will make the Slice play in all situations. You can also use this feature to localize particular pieces of VO or sound effects to certain regions around the world!

Video: User VO Not Working (click to view)

We will continue to update the community on solutions to backwards compatibility issues as we update and improve Dreams throughout Early Access. If you experience any problems, now or in the future, please do give us as much information as possible so our lovely QA & Feedback team at the Molecule can address them.

Feedback and Knowledge Base