Rick

It ends up being more about your time. Eventually your time is limited due to other commitments and you want to be as productive as you can. Switching engines all the time limits your productivity while increasing your knowledge. It's a trade-off.

EU has made you frisky lol.

When I did UE4 I would simply get one month to get the software and then I was able to cancel and just not get updates but still use that version. I think they eventually stopped the monthly fee and I would think for that reason. They would pump out smaller updates and fixes weekly which I think they thought would be why people would keep thier monthly they subscription, but I don't think it worked out that way. I would renew about every 6 months just for that one mo th to get caught up on all the updates/fixes. What is is your plan for making this subscription work? Will we not be able to use the app without an active subscription or will we not be able to get updates only without an active subscription? If we can still use the app but not get updates then I can't see people keeping an active monthly subscription. They'll just renew when they want an upgrade or a fix. This, however, means to incentivize people you have to be pumping out fixes and advancements every month to make it worth it for people. If you make it so we can't use the app then that only refers to the editor. People could still code in LE without issue. The editor isn't really required it's just a convience thing. They could easily build most of thier levels and such in a modeling package. I don't see how a subscription base works in today's world which is why I think you see engines dropping that idea now. Your pricing models are always about 2-3 years behind the big engine leaders. Learn from thier mistakes. People come to Le because it's easy and it has no royalties. I think they also liked just putting up a reasonable amount of money every year or so and forgetting it. If people can still use the software and just not get updates you'll end up with probably $5-$-10 a year from a person. Probably just best to charge $25 per major update which should be yearly. You'll get more money and people won't have to screw around with the monthly game of subscribing and unsubscribing based on what and when they want to update to current. Most people probably see $25 a year for updates as very fair.

To me he wasn't asking if this behaviour of being able to play the same source on top of each other with one reference should change. That will stay. He's simply asking if a source's reference goes out of scope but it's playing should it be deleted and therefore stop playing. To me I think that makes sense and it's what people do today anyway. That way you can play your audio over and over again via this reference. To let it keep playing while the variable is out of scope now means you have no means to play it again, unless you add the functionality that you're talking about. I'm not really sure what the point of the engine storing these pointers though. The use case listed in the original post is a situation that should pretty much never happen. It doesn't seem to be what people are really doing today. From memory it's not what Josh does in his FPScript and at most it saves a person from having to make a variable at the correct scope for the rare instance they only want to play a sound once in the entire app. Doesn't seem worth the effort on Josh's side to me but I will say that it allows for both styles to work so it's no biggie if he wants to spend the time to manage them internally as well. I just don't see the benefit.

I'm pretty sure sources can play on top of each other. That is I can have one reference to a source that uses a sound and call play on that source while it's still playing from another play call and it works to give that rapid fire audio. Maybe I'm missing something around that? I'm sure I've done that before. So not sure what you mean keeping a list of sources.

You wouldn't have to check if the sound is playing in your case. You'd just have to be more careful with your scoping. The example presented in this thread should almost never happen in my view. Load your assets in a loading area, then play them via thier reference. That's a common design. Who isnt doing this already today? In Lua people are making class/script variables to hold thier sources because you almost always need to play your sound more than once.

Shell's way is convienent, the way I mentioned is reasonable (keep your references in scope for things you need), your way would require a lookup in a global storage container from some kind of key. The global list and lookup feels like it promotes some messy coding. It seems very GameCreators which I always thought was a strange way to mange resources and man did I see some horrible structures in some projects I joined because of it. When everything is available everywhere things get unruly quickly.

Yeah I can see how one would get the best of both world there. At first it seems strange to be thst when a variable seems to goes out of scope it's still technically in scope, but I could see people liking that feature.

Is there a 95% use case for a specific type of pointer? Like are shared the majority of what a person would use? If there is then make that use case the default and easy vs the minority use case. ie if 95% of the time sources should use shared pointers then just make SourcePtr a typedef for shared_pointer<Source> to make things easier. You're starting to see why languages like C# as loved so much. Don't have to deal with pointer **** directly and still get the feel of normal looking class.

As a side note, if we are meant to use these kinds of pointers all over the place you could typedef them with a common naming convention to market less typing for us. I can see that getting tedious. Also what are you doing for Lua? Automatically making all of these shared pointers? If shared pointers is the default then heck you could rename the classes themselves with and underscore and use the now class name as the typedef itself so nothing really changes on our side from today. If you wanted you could probably even extend shared pointer to have addref and release functions that do nothing so current code would work. Making it backward compatible. Gives people a chance to clean up code slowly over time when they upgrade perhaps? Just a quick thought on that.

I think it's reasonable for the user to have to keep the pointer around. Most people will be using classes and so this pointer would be a class member variable so it would exist as long as the class exists and classes generally exist longer than functions so it's reasonable. So yes, when it goes out of scope having it clean itself up then opsould be nice.

I always thought the design of us having to load a sound then make a source and attach the sound was kind of unnecessary from our point of view. Why can't I as the user of the LE API just make a "source" where I pass in the wav/ogg path like I do sound and let the API manage things for me? If a sound is needed then you create it and keep it in scope. Don't put that on the user. I see no point in putting that on the user.

I used to be C++ but I'm Lua all the way now. Way more flexible. You fight less with the language but it can be more error prone since it's not compiled, but you get used to running/testing after small changes. Never code some giant system and then test it in Lua. It'll drive you insane because you've probably fat fingered about 10 different things and the errors they don't always point to the actual error in case of missing an 'end' or whatever.

There is a shader around that let's you hide a section of the terrain. This was generally done at design time so I'm not 100% sure if you can do it at run-time. It would also create a circle patch and would look strange. You would probably fake this in various ways to make it look good but in general LE doesn't do this very well.

I can't walk over some of those rocks. It seems like I should be able to. The character controller I think has a setting for how high the character will go over something. Maybe increase that? Those rocks visually don't look like I should have to go around or jump on. Also when I hold shift to run it shakes the camera violently back and forth.