Defold 1.2.175 BETA

Since it seems you’re not actually changing any data, but just want to “restart” the scenario you have, I would either:

  • reload the level collection proxy
  • trigger the effect again

And you can do that either via a debug key binding or in the on_reload() function.

Am I missing something?

EDIT: I think the sys.reboot() is the closest to what you’re already doing. And as for the other scenario, I think each developer make up their own code/content in order to be able to test a feature quickly. And
It could be special levels, that only showcase a special feature, or it could be a big in game “debug menu”, that allows you to trigger certain effects, spawn certain enemies etc.

1 Like

:unamused:

Keep in mind that the Defold team works hard to provide a high quality engine for absolutely free. I read through your bug report and it sounds like it is being worked on and will be released when it is ready. In the meantime, perhaps try working on a different part of your project until the bug is fixed. Part of being an effective developer is choosing which tasks to work on and when to work on them. :slight_smile:

11 Likes

ok, :blush:

I can confirm this is an issue introduced in the v1.2.175 beta. I rolled back to v1.2.174 and the icon looks as it should.

This is a bit unfortunate, and perhaps poorly documented BUT Apple seems to have started requiring a 1024x1024 application icon to be bundled with the IPA (at least for new applications?).

The only way such an icon can be included is through a stupid proprietary asset format Assets.car file. And the only way you can create an Assets.car file is through Xcode and an intermediary *.xcasset file. This is the same problem as we have with launch screen storyboards.

So, you need an Assets.car file specified in game.project and you need to specify the icon names (because they will be added to your Info.plist and where they are used to reference the actual files in the Asset.car file).

The process is documented here:

Are you using a custom info.plist btw?

2 Likes

Nope, I use the default one.

I just updated the beta with some new functionality for Live Update.

Since this includes some refactoring of the code, I urge those using Live Update in your apps to take note of this update, and if possible verify that there are no regressions in functionality for you.

4 Likes

I tested Liveupdate with this example code. Just pprint missing resources

pprint({ AFTER_STORE = collectionproxy.missing_resources(…) })

after

print("Successfully stored resource: " … hexdigest)

It’s all time print same data. If use counter and try “load” collection take error about missing resources

3 Likes

Thanks, we’ll investigate this tomorrow!

I’m afraid I cannot reproduce your scenario.
My output is like this:

DEBUG:SCRIPT: Missing resources,
{ --[[0x11190ead0]]
  1 = "3be32cfd80b4016a9ebaf1c7249396ef608c95bd",
  2 = "9170a12e266ec41f5575bb8f837d0f4bb6cab03f",
  3 = "07f1284d530deb401da0ed142da50d5724cb04cd"
}
INFO:RESOURCE: Live Update archive: /Users/mawe/Library/Application Support/e288e86f371f3dfd7d3f1b207f9d8a3206aa5fb4/liveupdate.arcd
DEBUG:SCRIPT: Successfully stored resource: 07f1284d530deb401da0ed142da50d5724cb04cd
DEBUG:SCRIPT: 
{ --[[0x111910e10]]
  AFTER_STORE = { --[[0x111911020]]
    1 = "3be32cfd80b4016a9ebaf1c7249396ef608c95bd",
    2 = "9170a12e266ec41f5575bb8f837d0f4bb6cab03f"
  }
}
DEBUG:SCRIPT: Successfully stored resource: 3be32cfd80b4016a9ebaf1c7249396ef608c95bd
DEBUG:SCRIPT: 
{ --[[0x111911640]]
  AFTER_STORE = { --[[0x111911850]]
    1 = "9170a12e266ec41f5575bb8f837d0f4bb6cab03f"
  }
}
DEBUG:SCRIPT: Successfully stored resource: 9170a12e266ec41f5575bb8f837d0f4bb6cab03f
DEBUG:SCRIPT: 
{ --[[0x111911e70]]
  AFTER_STORE = { } --[[0x111912080]]
}

And my script looks like this:

function init(self)
	msg.post(".", "acquire_input_focus")
	self.target = "levels#level1"
	self.manifest = resource.get_current_manifest()
end

local function callback_store_resource(self, hexdigest, status)
	if status == true then
		print("Successfully stored resource: " .. hexdigest)

		pprint({ AFTER_STORE = collectionproxy.missing_resources(self.target) })
	else
		print("Failed to store resource: " .. hexdigest)
	end
end

local function load_resources(self, target)
	local resources = collectionproxy.missing_resources(target)
	pprint("Missing resources", resources)
	
	for _, resource_hash in ipairs(resources) do
		local baseurl = "http://192.168.10.210:8000/"
		http.request(baseurl .. resource_hash, "GET", function(self, id, response)
			if response.status == 200 then
				resource.store_resource(self.manifest, response.response, resource_hash, callback_store_resource)
			else
				print("Failed to download resource: " .. resource_hash)
			end
		end)
	end
end

function on_input(self, action_id, action)
	if action_id == hash("touch") and action.pressed then
		load_resources(self, self.target)
	end
end

Perhaps you can give me a small repro case project?

1 Like

Please check your version 1.2.175 and build server https://build-stage.defold.com

3 Likes

Thank you!
I can now reproduce it!

(I must be tired, my test was ofc with the working 1.2.174, which I implemented for reference)

3 Likes

@denis.smirnov.by There is now an updated beta with a fix. Please try it out to see if it works for you.
Thx!

3 Likes

Can this new liveupdate mechanism be used in conjunction with the old one? For Interrogation on Android, for example, we use 2 zip files: A big one that we update rarely and a smaller patch file that we update more often. Can I use a system where the big one is loaded using resource.store_archive() and the individual files from the patch archive are loaded using resource.store_resource()?

Also, can we make store_archive() not move the archive? If the .obb archive is moved from its location, then Google Play will attempt to download it again. If we copy it, we waste space.

It’s not designed to be used in conjunction, no.
The downloaded .zip file will contain all missing content.

I think it’s best you add a feature request for those things.

1 Like

Not sure how the .obb file plays into this? This is the live update content that you choose to download.

We use Live Update to work around the 100MB APK file size limit. We add the Live Update content as .obb files (essentially zip) that Google Play downloads for us as part of the app installation process. The main problem is that the live update content gets duplicated once it’s installed with store_resource() and users are complaining that the game takes twice the space it should on their phones. I was hoping that by feeding the obb file directly to store_archive() we could get around this, but we can’t unless the game reads the obb file in-place without moving it.

1 Like

I think this is the crucial part. What format is it exactly?
The resource.store_archive() currently only supports zip files.
If it’s an Android format, we need to mount it in a different way.
I agree it’s a very good feature, so we should definitely do it if possible.

The moving of a file can ofc be changed, we can store a reference to the actual file elsewhere.

1 Like