[bug ?] error exporting external scripts

[Doridion]

Placed in the Superthread : Editor issues ^^

[antti]

It's probably a bug, but we haven't checked it out yet what's going on here.

[NutJob]

This is not a bump to catch the attention of a Dev but anyone that has successfully got past this sort of error. If so, please share. My entire map runs off external scripts with the exception of one script called gateway and I still can not Export no matter what I try.

[NutJob]

This is not a bump to catch the attention of a Dev[...]

Ok scratch that; this is a bump for confirmation or work around from a dev so I can play my module outside the editor. Don't worry I'll try to keep it to one bump every couple days after this one. ~laughs~ ...unless, I'm the last person who can not Export, then I'll just throw my towel in and move on.

[JKos]

Here is a workaround for you

Code: Select all

function loadScript(entityName,scriptPath)
		if findEntity(entityName) then
			Console.warn('Entity named '..entityName..' already exists')
			return false
		end
		local scr = spawn('script_entity',party.level,1,1,1,1,entityName)
		scr.script:loadFile(scriptPath)	
end


loadScript('test','mod_assets/jkos/my_test.lua')
loadScript('otherScript','mod_assets/jkos/my_other_test.lua')

Tested and it even seems to be save game compatible . This will make loading huge libraries with multiple scripts a breeze.

And as a bonus you don't have to place those script-enties by hand, they are created dynamically. And this means that we can load and destroy scripts any time we want, may be useful for really large and complex dungeons, like orrr3, maybe.

[Doridion]

And as a bonus you don't have to place those script-enties by hand, they are created dynamically. And this means that we can load and destroy scripts any time we want, may be useful for really large and complex dungeons, like orrr3, maybe.

If I simply understood, this script consider external scripts like "items". When spawning them, we give an iteration and so, can destroy them like other items. Really wonderful/useful/epicness !

Letting NutJob testing it and I'll place it in the superthread. I think you'll make love-modders JKos

[NutJob]

Here is a workaround for you

Code: Select all

function loadScript(entityName,scriptPath)
		if findEntity(entityName) then
			Console.warn('Entity named '..entityName..' already exists')
			return false
		end
		local scr = spawn('script_entity',party.level,1,1,1,1,entityName)
		scr.script:loadFile(scriptPath)	
end


loadScript('test','mod_assets/jkos/my_test.lua')
loadScript('otherScript','mod_assets/jkos/my_other_test.lua')

Tested and it even seems to be save game compatible . This will make loading huge libraries with multiple scripts a breeze.

And as a bonus you don't have to place those script-enties by hand, they are created dynamically. And this means that we can load and destroy scripts any time we want, may be useful for really large and complex dungeons, like orrr3, maybe.

Appreciate the work around. While it's loading I'm now having a problem with the namespace and I'll have a lot syntax and hierarchy to rework before I can confirm it's [personally] working. I'm sure it does, though. Thanks.

[JKos]

What kind of namespace problems? I didn't test this much, but doesn't it work if you remove/rename your external script entites and instead load them with loadScript-method?

I mean if you have a external script entity named "lib" which points to "mod_assets/nutjob/lib.lua", just remove it from the dungeon and call loadScript("lib","mod_assets/nutjob/lib.lua")

[NutJob]

What kind of namespace problems? I didn't test this much, but doesn't it work if you remove/rename your external script entites and instead load them with loadScript-method?

I mean if you have a external script entity named "lib" which points to "mod_assets/nutjob/lib.lua", just remove it from the dungeon and call loadScript("lib","mod_assets/nutjob/lib.lua")

That is what I did and it can find the script_entity ('lib.script') but once it gets to my [fake] namespace "GFX" it drops me errors. The external file starts:

Code: Select all

GFX = {}
GFX.v = {}

-- followed by all functions under

GFX.myfunctionA = function() end
GFX.myfunctionB = function() end
-- and so on, using GFX.v to store any variables that need to be saved (or the odd parameter pass to something else, like when using delayedCall)

GFX is no longer an available field outside the scope of the loaded script in this manner. So if I call, in a_new_script_entity:

Code: Select all

lib.script.GFX.getSomethingAndDoit()

I, now, just error out with the editor complaining GFX field doesn't exist.

Edit: important to note I manually CUT & PASTED that script entity to the top of the dungeon.lua file so it was loaded first, so it's not a load-order issue.

[JKos]

It is a kind of load order problem, we had this same issue with LoG1 too. Dynamically loaded scripts can not be used until all Embeded scripts all loaded.
But this can be solved, I'll get back to this soon. I just have to implement same kind of autoexec-mechanism like Xanathar did with his GrimQ-library, should be easy now with dynamic connectors.

You can test this like this:

Code: Select all

function test()
lib.script.GFX.getSomethingAndDoit()
end

and now call this method from the console.

Edit: Ok, this is fixed now, great. But dynamically loading scrpts will be useful, so I'm going to develop this further anyway.