Rick

That makes sense. Seems like you can also have a separate GUIView then, that also subscribes to your spaceship Model so it could update the UI too when certain events are fired. That's cool. This method seems like it also gives you a good networking approach once you are able to run LE on a server without a graphics card, since all the game data and logic is in Models, you just send the data to the clients and they update their visuals. With remote procedure call you can even fire events on those client machines to update their Views.

So where does the actual storage of data go? I can't imagine it goes in the View or Controller so that leaves the Model. If it goes in the Model that would mean that each instance of a View has it's own instance of the Model so that it can have it's own data? I was originally thinking the Model would just be the logic alone, but then I wouldn't know where the data would be stored so now it seems the Model needs the data for that specific instance of the View it's working on.

Then this is where you can borrow from .NET with events and have an EventArgs class that you derive from for specific events so it can store specific variables about that event. This would allow you to define all event variables as Event1<EventArgs*> OnPositionChange, and still be able to pass different data based on the event. Derive from EventArgs to make PositionChangeEventArgs that has an x, y, z variable, and when you fire OnPositionChange create an obejct of PositionChangeEventArgs and fill in x, y, z and pass it to the event when the Model fires it.

I wonder if it would be better to just fire events from the Model to the View and pass in the information required for the event instead of having the View query the Model for data. That way the views wouldn't need to hold onto a reference to the Model. It would just need it at startup to subscribe to it's events. Basically you would have events for every kind of thing that could happen to a View(Entity).

But duplication of things LE already stores might not be all that bad. I'm reading more about this and it seems at some level the Model doesn't need to know about the View or Controller at all. This would be huge in being able to port all your game logic over to multiple engines. You wouldn't need to change your game logic at all. Just the Controller and Views which would help same time and reduce bugs when porting a game. At first glance anyone using LE would say you are wasting memory and processing time, but you are gaining the ability to port your game much faster and easier. This could be huge if you plan on making things on consoles.

I'm curious on how you are going about Views also. Are you taking everything in the scene and putting them into 1 View or are you breaking them out based on some criteria or are you dynamically making/destroying Views as the game goes along? This is interesting stuff

Ah, events. Yeah that makes sense now. I was trying to figure out how the Model would tell the View without storing ID's to it, but events solves that. I like that idea. You can use that event system I posted a few times on here. That would work very nice with this because the View methods that you bind to events can be private and not exposed to the View objects if you want, creating a nice and tight object that is controlled by the Model logic. Seems you think I opened your eyes, but I think you opened mine The only strange thing about this with LE is that the way it's setup the assets already know their positions and other values. So storing them off again in the Model section would be duplicating things. Like in the Model section you'll have Vec3's for positions of assets when in reality you can get that from the View side because it has the TEntity and when you have that you can query anything about that like position/rotation etc. That was one of the reasons LE is slightly different than other none entity based engines where it's up to you to store the position and other attributes yourself. LE already does that.

It seems to me from the wiki description, that the model tells the view of the changes. The view doesn't query the model for the changes. So if the model portion of the code has to tell your 3D models in the view to change, how can it ID those 3D models in the view? It seems you would want to use the TEntity for that ID. No reason to create your own. So that's why it seems like it would make sense that the model hold these ID's of all the views, so it can tell the views what to do. That's just my understanding of it, and honestly the MVC model isn't something I've used before but from reading the description of it this is what my take on it is. In your example, selecting the units would be the Controller potion. That input would them populate the Model portion (SelectUnits logic) with the TEntities that were selected. Running the Model logic would then set their tints, which is telling the View portion of the change you need. Then LE draws the View for you with the changes. So it seems you are trying to have the View query the Model instead of having the Model update the View?

I don't know if that really has to be the case. Looking at the wiki of MVC let's take some information from that and see if we can't relate it to LE. The way I see it, the TEntity is the means on how you notify the view of changes (in LE the views are hidden from the programmer). So by using TEntity and calling PositionEntity() you are telling that view the change you want. LE handles the view for you already and so you really only have to handle the model and controller.

I don't know what he's talking about with that. You can have do the same with physics based. I'm guessing he's meaning doing bounding box checks with a solid shape like a cube. Honestly I'm pretty sure we can do that right now. I think that AABB function is available. We would have to check every entity against these cube shaped "solids" to see if they are in their bounding box. Then maintain the list so you can tell when they leave them also. Unity seems to use physics based objects to do this, but I guess you could do it with "solids" also. I figured it would be easier to do it with physics because I assume the physics library handles the collisions for you, and he'd just have to store some flags per entity to tell if they are still colliding each frame and when they stop colliding.

We see the potential if a few things were implemented in Lua

What do you mean by solids? You mean like something like 3DWS? You could kind of do that right now with Thingoids, it just wouldn't be the easiest to manipulate the cubes since it would have to be done via text properties instead of dragging edges and such. Although you might be able to write a separate editor that connects to the LE Editor that shows the 2D version of the scene and allows you to construct these primitives.

You are a warped person Pixel

I want to run LE on my microwave! It probably has a Linux core.

That's good to know, but I assume that's only because we have to apply the invisible.mat to them. I assume they still take up memory(probably not much though)? Either way they become useless, and it's kind of a pain to have to copy over those models to each new Thingoid I make knowing it's kind of pointless.

1) I hope he was trying to funny 2) Win 32 API programming really sucks. 3) Lumooja, you realize with that code you posted there is a ton of code hidden from you that's doing basically what Josh has above.

I think it depends on how you use this. If you go the route of "Thingoids", reusable Lua "objects", then you could potentially end up with a bunch of junk models hanging around that aren't needed. This is one of the reasons it doesn't make sense to require a script be attached to an actual model. There should just be "game objects", which aren't models, that you can attach scripts to. With this approach a complex scene could end up with a ton of these dummy models, and could affect the fps. Then again, you could probably just hide the mesh, but they would still be taking up memory, probably not much, but they still wouldn't be needed. When I was doing my Thingoids I had probably 15 (?) in one very very basic scene. Add to that the other LE entities like lights and such and it was probably like 20 in a scene that took about 20 seconds to get through. These were basic Thingoids too. No AI stuff, so a scene for a AAA game could end up with a good number of pointless models. It is what it is today, but it could have been and can be made in a better way.

Moving across the world to fast really is the issue with streaming. That's why things like in WoW when you fly from one place to another it takes crazy long routes sometimes. It's to give the world streaming time to load things before you get there. In Mafia 2 when I'm going 100+ mph everything slows down and things are still loading when I get there. That was lame. As for on topic, I wouldn't call the Lua stuff silly. It's actually very powerful and can help extend the editor with new functionality. It's just something you aren't interested in right now is all. It would be nice though if we (the community) could come up with a better LoadScene() method.

What you are saying isn't an opinion it's a fact I 100% agree with you. Sadly I don't think these are considered to be bugs by Josh and will most likely never get done since he's doing LE 3 dev and I guess only bug fixes for LE 2.x?

Oh, I thought I was being innovative with splitting the original sbx file into 2 files on the fly then using LoadScene() on the sbx file that has terrain and vege and a custom LoadScene() on the other sbx file that has all the entities. The splitting of the original sbx file should take less then a second and put in it's own thread so it doesn't cause any stopping. Then once both temp sbx files are loaded delete them.

In code you could pull out the vegetation layer and terrain from the sbx, and make a new sbx file with just those 2 things, then call LoadScene() on the new sbx file to just load those 2 things. Then do the normal looping through the original sbx for all the models.

Unless you undefine the macro, like posted above. Since macros can be used anywhere, it's seeing that as a Macro. It doesn't know if you mean to use the macro or not. Given how macros work, how could it? This is just 1 of the reasons macros are evil. It sucks that Win 32 API is loaded with them. It servers as a good warning to all library creators though.

There were a few threads about trying to do this, but no luck so far. It could be simulated with a custom LoadScene() however.

I have to agree with mumbles on this. Client side prediction is still a must have for multiplayer games, and ignoring that for the only reason I can see is because it's complicated to do correctly is a big mistake and will make the netcode a joke in the engine community. There are a few reasons it works for OnLive: 1) They have many "hubs" around the US. 2) They are only offering this in major cities. 3) They have special logic built in to control where their hops go. Networking is easy, but networking correctly is complicated. If you are serious about adding networking functionality that is really usable then you would hire someone who knows how it's supposed to work.