Rick

I switched it to use the Interpreter:ExecuteFile() function and had my entity script accept both the lua file to load and a string which represents the function name in that file to run which I them get from with: _G[funcName] This works but as beo6 pointed out in his thread it's not ideal as it clutters up the global space and has potential collisions with function names if not careful. Would love for dofile() to be rewritten like I assume import was to handle zip files and such?

Just restarting steam worked too. Thanks for the feedback. We treated the fireball in your hand like a flashlight where you can toggle it with 'f'. You don't have to have it in your hand to shoot it. We plan on having water element too and switching between them with 1,2 keys but I can see how having it always in your hand would make more sense.

So this problem is on my and tj's pc only? It's working for others?

Is there something with the game launcher that needs to be reset? It seems like when I click launch it should validate the game is there and if not download it, but it's not doing that. It's just saying "Failed to download Workshop item".

That's what I'm doing right now as a workaround. It seems import only works at the top of script and not inside a function so I hardcoded the intro script to be imported into the cutscene script and it defines a global function that I call, but that's just a workaround really. Ideally this functionality is generic and I could release it to others. For that to happen I need to be able to load a lua file dynamically inside a function. That's what I was doing with dofile(). The best part was my function in the cut scene was defined as local and I returned it so no messy global issues. The below is the ideal situation I think,just doesn't work when published. --inside my generic CutScene.lua file that takes an editor parameter of what lua file holds the details to the cutscene self.func = dofile(self.scriptFile)

I deleted the zip file in that folder and when I try to Launch from Game Launcher it now errors with "Failed to download Workshop item".

Tj and I launched a demo. The first time we published it had a sound file missing and wouldn't work. Tj fixed that and updated the game player. For him now it works. For me, when I click the game again it doesn't do any updating and so it's running the same old exe which fails. I've unsubcribed and re-subscribed and that didn't work. I've even removed reinstalled the game launcher and that didn't work. The old content must have still been there because again it didn't show any updating/downloading dialog when I launched the game like it did the very first time we published it. EDIT: Guess it stopped working for Tj too now. Really need some help here.

In this case we are using Game Launcher so exposing isn't an option, but just annoying these aren't documented. I never go to the header file. Shouldn't have to, but thanks for the info. Will try that function.

I see no documentation link of Interpreter in the API reference. I'll give this a try though thanks.

I need to be able to load lua files in code at run-time that doesn't use import at the top. I have a cut scene script that you specify the lua file that has the cut scene in it as one of the editor properties. I then use dofile() and in the editor this all works great. However, when we publish the lua cut scene file ends up in the data.zip file and dofile() doesn't know how to load it from there so it fails. TJ and I have a game coming out today on the gameplayer and the intro sequence is hacked together and I did the import at the top of the intro sequence in my cut scene script just to make it work so we could release it, but that won't work when we want multiple cut scenes in our game. So is there a way to load a lua script during run-time that isn't import at the top of the script and have that work when published? Josh, perhaps you can rewrite dofile() like I'm guessing you did import so that it handles the lua in zip files when published?

I think having it part of LE is key with this, but when you consider what the tutorials that have the grid textures on them need, it's really just walk around, jump, maybe crouch, and 'e' key for Use. Adding life and weapons starts to make it more complicated than it needs to be and those tutorials don't take advantage of those 2 features anyway so no sense in having them for those maps. A nice progression would be good though with those tutorials. Building on the script as the tutorial permits/requires.

I think there is 2 different things here. Map size and terrain size I believe are different right? Map size is more like world size maybe?

I feel like for some of the basic examples there should be a really basic FPS script for them. I get reusing the 1 script for convenience but since these things are for examples and tutorial type stuff it would be beneficial, I think, to have basic movement and use functionality without all the clutter for people. Just an idea so that newbies don't get overwhelmed with everything that's in that script when looking at those example grid maps. I bring this up because when I do training I use that script, but it's so busy that to point out some of the basic stuff I have to weed through much of it and tell people to not worry about some of that stuff right now. I can make my own script of course, but was just thinking since most of those example maps don't need 90% of the functionality in that script, it might be nice to have a more basic FPS script as well be part of LE.

Loading maps isn't asynchronous and so each time you load there will be a pause. So yes, you could get an infinite world, but you'd have to be loading models that have already been loaded in memory at least once (to take advantage of instancing because loading a model that is already loaded isn't really noticeable). And you'd have to load probably a few tiles at a time each frame to avoid a possible noticeable lag.

I've never used that library before so I'm not sure if the sln file makes a DLL or I suppose you could import the source files and see what happens. If you aren't familiar with C++ then making these things work can be a pain sometimes.

Any Lua lib should work with LE, but you just won't be able to run in sandbox mode (if an external dll is being loaded) which means no gameplayer for that game.

What do you mean pre-render? Do you mean load it into memory? You can load as many maps as you want into your world but if they are all located in the same place they will draw on top of each other unless you go through and hide all entities in said map.

Maybe this isn't a bug but it seems like a bug to me.If I have logic that doesn't let me hit the KeyHit(Key.F) line and I hit the 'f' key, and then I have logic that hits that KeyHit(Key.F) function in later frames, the action will happen even though I hit the 'f' key many frames ago. So this seems like hitting keys on the keyboard set some flag that it was hit but doesn't release that flag until KeyHit() is called. To me it seems like key hits should get released each frame. Does that make sense? I know KeyHit() says the following (below) but is there a case where this behavior is really wanted vs having it reset each frame? I know I can use KeyDown() but then for toggle behavior I have to make a boolean flag to go along with it. Should KeyHit() be that toggle behavior for us?

I find myself right clicking a folder in the script editor and wanting to find a New Script option there that will fill in all the script functions for me like doing so in the assets panel area. I can create a new file but it's empty and not a script file from the script editor.

I don't really understand this idea. Something like LE is not a language it's a library. What difference does it matter if the LE API is built into BMax or if it's just an external library that can be used with BMax? You'd still get the same benefits you talk about would you not? I guess I wouldn't view this any different than exposing LE's API to .NET. You include the LE.dll to your .NET app and now you get to use all .NET has to offer, DB access, sounds, 2D, etc, but no need to have LE built into the .NET framework to get that.

Together with the new IDE features we have and Workshop integration, it could be really nice. What could be very nice? I'm having a hard time translating what NA is talking about. Is this basically just having LE available in BMax again?

Love it!

I didn't say it's not possible, I said today it doesn't work that way where you can assign multiple ones. You weren't asking for multiple assignments but just a way to see it without going into the "file system", then Olby mentioned multiple faces/materials and I was just pointing out that today it doesn't allow you to assign multiple materials via that way. Yes, I would love if it did all of this

I don't think you can do that from that tab today anyway.

I still think adding a checkbox in the properties section to collapse or not would be a better solution.