DerRidda

How would I go about setting up a perpetually rotating hinge joint? Once its reaches the SetAngle value, it will stop and I have no clue how to cleanly reset it without interrupting the process. The dirty way is to use GetAngle to capture the value just as it nears the SteAngle value and add a ton more to the SetAngle value and just add some more on top but that will break eventually as the numerical value reaches the maximum for floats. Which might take a ton of time but I truly hate conceptually broken code. Anyone got any ideas? Script.pin = Vec3(0,0,1) --Vec3 "Hinge Pin" Script.limitsenabled=false--bool "Enable limits" Script.limits = Vec2(-45,45) --Vec2 "Limits" Script.parent= nil --entity "Parent entity" function Script:Start() startrotation = self.entity:GetRotation() local pos = self.entity:GetPosition() local parent_pos = self.parent:GetPosition() local abs_pos = pos + parent_pos self.joint = Joint:Hinge(abs_pos.x, abs_pos.y, abs_pos.z, self.pin.x, self.pin.y, self.pin.z, self.entity, self.parent) if self.limitsenabled then self.joint:EnableLimits() end self.joint:SetAngle(1080) self.joint:EnableMotor() self.joint:SetMotorSpeed(360) self.joint:SetLimits(self.limits.x,self.limits.y) end function Script:UpdateWorld() --feed me! end

Josh, could you explain why it is possible to drag & drop models and prefabs into the 3D viewport but not materials onto something inside the viewport? Wouldn't that information be just one pick away or am I seeing this too naively?

And that right there is your problem, you need to create a LoadWeapon function. You can't call what doesn't exist, ergo you get "nil" value errors. View the tutorial video again and you will see what is changed and where the LoadWeapon function is created.

Interesting stuff indeed.

I believe you but I still did some googling around: http://www.compsci.hunter.cuny.edu/~sweiss/course_materials/csci493.70/lecture_notes/GTK_dragndrop.pdf http://www.manpagez.com/html/gtk2/gtk2-2.24.24/gtk2-Drag-and-Drop.php I know of the alternative methods and in case of the adding entities to the flowgraph it is reasonably fast enough to be considered an acceptable alternative. Adding materials or scripts to a mesh though isn't quite as good. Could we at the very least get a similiar workaround to the one you used for the flowgraph. I'm thinking: Select (multiple) object(s) in the view ports -> go to the asset browser -> right click an material/script -> Select a menu point that would attach the material/script to the object(s). This would be much more convenient than folder diving, especially when you want to attach one and the same thing to multiple different objects.

But that doesn't really work with level geometry.

Following up on this discussion http://www.leadwerks.com/werkspace/topic/10506-flowgraph/ which concluded that you can't drag & drop entities into the flowgraph under Linux. Turns out you basically can't use the drag & drop functionality anywhere, except inside the scene graph for grouping and attaching entities to script parameters. You should be able to drag & drop assets like scripts and materials onto objects in the 3D viewport, right? Well, that doesn't work at all. It simply seems to not be implemented, just like the flowgraph.

Currently, the only way to change the size of a mesh is to mouse it into shape or use the scale values. Mousing is a bit inaccurate and cumbersome and the scale values are, well, just scaling the mesh proportional to its original size. I think an actual field for absolute size in grid units is a no-brainer to add. It would make it so much easier to shape meshes according to the real world dimensions of the thing it represents.

Did you follow the tutorial and actually create the LoadWeapon function? Make sure there are no typos anywhere.

So, I'm not that well versed in matters of graphics APIs but I'm still interested to in it and what OpenGL 4.5 and all extensions that have made up all versions >4.0 could mean for Leadwerks. I think 4.0 is a fine version to target and already a ballsy enough goal seeing how many people are stuck with 3.x or are simply unaware of what OpenGL their card+driver combo supports (which isn't all that surprising seeing how OpenGL information is basically nonexistent on marketing material these days). Would support for OpenGL 4.5 (not as a baseline but rather a "cherry on top") be worthwhile for Leadwerks? Maybe not in regards to actually having a great deal of new features but in utilizing the efforts of having reduced driver overhead and giving the player better performance in return if a supported configuration is detected? "You have an awesome GPU! Here, have better performance and maybe trade it in for running the game with higher graphical settings." I'm genuinely interested, seeing how 4.5 could quite possibly be the last version of "classic" OpenGL because of OpenGL next, but I'm not well versed enough in the matter to lead this discussion.

That's on Linux, isn't it? I think it doesn't really work under Linux (yet), you have to right click it in the scene graph and add it through the menu. But you are right, it totally should work and I don't know why I didn't report it myself yet. Probably forgetinated.

If you are not seeing the fully featured editor in Leadwerks for Linux yet go to "~/.config/leadwerks" delete/rename the old config and let Leadwerks generate a new one, the defaults will enable the full editor again. Sadly the options for changing it aren't yet exposed inside the editor under Linux (again), which i'm sure will come in a future update.

Might be worth changing the offset of the second window, I have a dual monitor setup and thus am not all that concerned as to where my window spawns. And as I said, OpenGL context switching can be awful. I'm using the latest Nvidia beta drivers for Linux (343.13) and Nvidia does OpenGL best. AMD is the worst with OpenGL on every operating system there is, don't know how good Intel is.

Weeee, this is fun. Some more tinkering and the game is displaying in both windows now. You have to manually set the context you want to render each frame, which means your overall fps will be cut in half (at least, because I've heard OpenGL is awful at context switching) as its is split between windows but this is how this works. This might still be useful for something you don't want to update as fast as possible. Also, you might not need the change to FPSPlayer.lua anymore but it is still useful, as you will always have the same window as reference for input events. App.lua

Seems like you kinda can. I tinkered around a bit and at first got two windows, where nothing rendered, though the game was running in the background, then I tinkered some more and stuff now actually runs, in the second window. I tested it with the AI and Events map from the MyGame demo project. I changed App.lua to enable the second window and make it actually sync up but I also changed FPSPlayer.lua to fix the context and window that's used in there, I somehow end up on the incorrect window though but this is just the result of less than 10 minutes tinkering, so go wild and tell me how it went. Might be easier if you start and empty new project just to test. App.lua FPSPlayer.lua

This actually also happens under Linux, just switching to the software tab freezes the entire client. Valve is bad at QA but even worse at cleaning up behind themselves.

It seems to me like you are using the wrong coordinate transformation to begin with. What you are trying to do is place your planet around a sun that's sitting at (0,0,0) while the data you have are the two angles and the distance, right? What you have (yaw, soll_pitch, olanetDistancetoSun) are all the components you need in spherical coordinates, the correct transformation from spherical to Cartesian (x,y,z) coordinates can be found here: https://en.wikipedia.org/wiki/Spherical_coordinates#Cartesian_coordinates r is your distance (so just omit that for your normalized vector, though you can actually skip that and go straight for the full vector) and theta and phi are yaw and pitch respectively, depending on which convention you use ( I recommend the physics convention) What was killing your y (besides being wrong) is the tangent you used which diverges at ±90°, which would place your planet somewhere in infinity, which obviously doesn't work.

I see more than just a couple of things that strike me as odd about your math before we even get to the orbital inclination. Please forget about the code for a moment, explain in words what you are trying to do and why you are doing it like this and lay down your math, step by step. And what exactly is the "error". (Expected result vs actual result.)

http://www.phoronix.com/scan.php?page=news_item&px=MTczNjU I think you might have something to add to LW in the future, Josh?

Yes, the scene tab needs an overhaul. On Linux it is constantly misbehaving in a similar way.

Yes.

Windows and Linux are already in and OS X is to come later (hopefully by the time any larger project is ready to ship).

This might have something to do with my performance issues I reported on recently, I though it was a driver problem but I think I was mistake in that. I still get that issue from time to time and I usually have other programs open while doing so. I never get good fps out of any test run I make under Linux from within the editor. If I run the game directly via the binary inside the project folder I great great fps, unless I still have the editor open or Chromium, even if Chromium is just on the starting tab, it just has to run to absolutely murder my fps. Can you check if you see similar behavior with open applications in the background even though they might not even create a CPU/GPU load? EDIT: Seems like Chromium isn't even that reliable to cause that issue, only the Leadwerks editor itself is sure to simply murder my fps all the time.

Good stuff, just had an insightful session. Would recommend.

I like that you don't buy into into vendor specific bollocks. Nothing good ever comes from limiting some users so you can make a company that isn't even your own more attractive. "Here, have all the negative consequences to push our tech and help in making the PC platform less open. What could possibly go wrong?"