macklebee

try CTRL+SHIFT+Right/Left-click.. at least thats what is working for me... that and you need a terrain

Shadowgrounds pack

Downloads

no, i wouldnt say a wild goose chase... it made us take a look at emitters and pointlight/waterplanes in 2.31 and find that there was an issue now. the only thing that was confusing was your ability to get something to work when it just failed no matter what when we would try it in 2.31. who says it doesn't snow in space? you are mighty quan, the creator of your game's world. if you want to make it rain guinea pigs that shoot lasers out their eyes that is your decision.

heck... that explains it! if I was you quan i wouldn't bother with downloading 2.31 until these issues are fixed. right now the version you have doesn't have these issues. What we have been referring to are all issues that belong to 2.31

yeah, it took awhile to figure out the texture orientation in hex vs LE... sometimes I still havent figured it out... i just keep flipping textures in hex' export options until i get what i need The error that you get in uu3d is not really an error but more of a warning. To get the model to "normal" LE size: - After loading model into uu3d, click 'Select-->All' to choose the entire model - Click '3DTools-->Modifiers-->Scene-->Scale' and scale the item as you see fit. One square tile in UU3D is equal to one square meter tile in LE's editor. - Click '3DTools-->Modifiers-->Scene-->Move' and set the origin for your model, keeping in mind that 0,0,0 in UU3D will be your model's origin/pivot in LE. - Add material/textures by using the UU3D's material editor's Maps tab and adding a texture to the diffuse map. Doesn't matter if its anything else, because the LE *.mat file determines how it is used. -Export to gmf keeping in mind if you need to export multiple uv's due to multiple textures, bones, animation... etc...

Actually I only mentioned it to him once. He has supposedly bought LE according to his first post, so he should take the advantage of what the private forums have to offer. He is missing out on some good information by not getting the access that comes with being a SDK owner.

uh i thought Josh just released that earlier today?

aggror, does your modeling program allow you to see which way the normals are facing? If so, i would try that... because looking at the picture above, I would say thats the issue... you can see the outline of the main model through the areas that have the texture problem... which kinda points to inverted normals from what I have seen...

The backbuffer will be the size of your current graphics screen. You could create a new buffer at the size you wanted then render then use the SaveBuffer(yournewbuffer, "c:\esp.png") but there is an issue. A new buffer for some reason is inverted, so your resulting picture would be flipped... which might not make any difference to you if you dont have any text on the screen or are willing to flip the resulting picture yourself in a image program.

If you go to the Forum Access post and follow the instructions, you would see many examples of this in the private forums for the supported language of your choice.

As a bmax user, I guess I could say I am already used to having to convert code since the majority of the LE tuts are c++. Bmax users have a gui module available to them and I cannot imagine that there isn't a c++ gui library available. This isn't fpscreator. Its not Josh's responsibility to code every possible thing you would want in your game for every language. If someone decides not to use lua, that's their choice and they would need to do their own implementation.

Here is a small entity script that will allow you to take a screenshot of your current rendering screen in the editor: screenshot.zip The picture size is based on the current size of your editor window. You can set the screenshot key, the path, the filename, and the file type in the properties dialog.

The Pointlight + Waterplane issue: Simple scene with 1 pointlight, 1 waterplane, terrain, and 1 directional light. Plight.zip Use bmax to load the scene and the program will crash if you try to view the pointlight and water at the same time. Remove one or the other and all is fine.

yes. it only crashes once you try to render a pointlight and a waterplane at the same time.

SetWorld(fw.transparency.world) then create the emitter and set its properties ... SetWorld(fw.main.world) But there is a bigger issue happening here. Any emitter created and saved in an Editor scene will crash a bmax program. Same thing happens with pointlights and waterplanes. Both emitters and pointlights were worked on during this update. So I am hoping Josh just forgot to upload some new files...

yeah, this looks like there are some files that didn't get updated for this update... so far: Emitters (whether created by bmax or loaded from a sbx) will crash the bmax program with blide pointing at an issue at Emitters.bmx (maxide points to the fw.Render()) Any pointlight in a scene with water loaded into a bmax program will crash the program with blide pointing to world.bmx (maxide points to the fw.Render())

As a fellow hexagon user, I found your workflow interesting. I typically just name the material, export as obj, then use uu3d to scale, set the origin, and assign textures. That way I can name the textures whatever I want and its easier for me to get the equivalent LE scale and set the origin in uu3d. This allows me to basically "freehand" my model and not worry about scale or axis while in hexagon. However, your method looks like it works just as well and as as efficient. Appreciate the video. nice work. And I believe many of us here are in the same boat as far as creating a "playable" game. We have families and jobs that take precedent over this. And alot of us do not even program or do "art" for a living. I don't think you have to have a playable demo to actually contribute to this community.

no problem glad to help.

Yes, you can use C#. There is a C# section in the private forums. You need to go to this link==>Forum Access and follow the instructions to get access.

1) From that screen shot you are in the sculpting terrain editor mode, not the object mode, which I suspect is why you have jagged peaks. 2) If you want rounded corners on your road, you have to do what Josh said and rotate the nodes (by the Y axis) until you get the curve that you want. 3) You said line 13 of your road_node lua script doesn't contain the roadoffset value? That means youre not using single state lua or you have edited the road script. What is the very first line of your road node script? EDIT--- actually it looks like if you do not correctly have your road laid out before you hit the 'Align terrain to roads' button, it will cause these jaggies. You need to layout your road on the terrain first. Rotate the road nodes by their Y axis until you get the look you are looking for... and also suggest you increase the offset inside the script to a higher value as suggested. Then when the road is completely laid out, then hit the 'Align terrain to roads' button.

I don't see why anyone would be pissed off about getting any free example (assuming that Josh is actually going to release this to the public). If anyone is making a pure bmax / c++ with no lua, that is their choice and will need to make do. But since this is lua and can be used with bmax/c++, I don't see anyone making a complaint. Especially since if they truly wanted to, they could just convert the lua code to their language of choice.

Its undocumented. There is an example of usage inside the fpscontroller lua script.

These are the classes I am referring to:Entity Classes In bmax its GetEntityClass(TEntity)... in lua its entity:GetClass()

reboot?