Rick

There is a drawing hook that you can assign a Lua method to and inside there you can draw 2D stuff like text. AddHook("Flip", MyFunction) "Flip" is a keyword and for drawing you need that, then the function can be any Lua function. function MyFunction() -- Draw images or text here end

Strange...

I didn't know you could even set that. I only have 1 now, but I didn't do anything different. It happened shortly after I made this post so I assumed "admin" maybe did something to my profile? It just automatically changed for me from what it was doing.

This is what we are trying to say. You can't use any of LE without the machine you load it on having a LE capable graphics card. So the job just got more complicated.

Everything should support .NET

I thought reflective surfaces has to work with multiple worlds and such as well.

What Lum is saying is that you can't use anything LE API related at all without a capable graphics card, so in order to run servers you have to jump through hoops. If you want physics you have to do it yourself with a physics library. If you want to store data and manipulate that data you have to make the structures and methods yourself. You can't have any LE related API stuff without a valid graphics card.

You have to have a graphics card to capable to run LE to use LoadMesh(). Like we are saying any LE commands you cannot use on a server that doesn't have a graphics card. It's an all or nothing thing. There also is no spec for sbx. It's been described as obvious, and for the most part it is.

Very cool. Is that going to be kind of the same for reflection? Seems like it could be. That would be huge!

You would have to parse the sbx file yourself, and load that information into your own structures. You won't be able to load them into any LE structures without having graphics. So if you have a Gun class you can load the information from parsing the sbx file (which is just plain text) and create your Gun class on the server, but your Gun class can't use a TEntity anything like that. The downside to doing this is that you can't use any LE functions on the server if you don't want to init graphics. For example if you want the server to do a PointEntity() you would have to write your own version of it. If you want your server to have collision callbacks you would have to handle that all yourself.

I would think you would need to do that. If the client is just sending user input to the server, then the server controls all unit information and would have to send that data back to the clients to sync.

Is it at all possible to make handling transparency easier than it is today? Screwing around with multiple worlds kind of sucks. It would be nice if we were able to do this easier on our side and you can hide all that world stuff for us. Things like fading objects that we can pick and interact would be much easier if we didn't have to screw around with having 2 objects, one in the normal world and one in the transparency world. There has to be an easier way to handle transparency even if it is a deferred render. Make an easier interface for us and you handle all those details behind the scene. On a side note, isn't BMax basically a C wrapper around Windows C API, and other wrappers on other platforms?

I'd suggest RakNet.

It would be amazing if they could really make it easier for these devices.

That's just Lum being Lum.

If you say so.

Fine. Make the map, and just realize that the sbx file is a simple text file that your friend can edit to do exactly what I said. Honestly, there is no technical difference. If one was making a game they would have sbx files and as far as I remember we don't have to do anything to encrypt the sbx file so nothing stops people from making their own maps from notepad if they wanted to. It would seem more logical that just showing a model would be OK, but giving the source to make logical things (ie able to code) would be what's bad. If anything my suggestion is more safe than Lum's because if you make a game using LE as it is today, anyone can code via Lua because there I don't think there is anything saying you have to protect the Lua files, which means anyone could then program your game. At least with my suggestion you can take the scripting part out of it so people can't do any logic. They can just view the models.

Oh, duh, my bad. I wasn't reading into that correctly Sorry for the brain fart.

Kind of like Lum said, make an exe that reads a file. Inside this file the artist can put the name of his model followed by a location. Then your program would read this file, load each model, and position them where the artist defined. Make the program use WASD and the mouse to freely move around. Now your artist can make sure his art loads and looks good using LE.

But what if I set the function up then sometime during the running of the exe I don't want it to be called anymore when entities are in that specific area I defined? How can I tell LE to stop making the callback when entities are inside that area?

How do you "unregister" the ForEachEntityInAABBDo callback or any of them for that matter? If I call this multiple times will it register all those locations or overwrite the last one and only register one always?

Did how this is calculated change? I have 3 pages when I select "view new content" and a good number of them are things that are older. I've never had 3 pages when selecting "view new content" before.

Am I missing something or does wailingmonkey never move forward?

Can't you just use LE in your DLL just like you would in an exe? Do the same setup of your project and just call Initialize() and not any of the graphics stuff. Then in your exe where you are going to use your dll, use it like anything else?

What are you planning and why do you want to use a different buffer for each component? That seems like it could end up being a ton of buffers. I'm just wondering what advantage you would gain from that?