DerRidda

I just don't want to have to slap a script onto an entity just to set its friction values, it's a bit overkill. This should really be in the physics tab as it is a very basic property of any material. EDIT: Also should be added for Terrain as you don't even have the option to add a script there.

In that case, yes, you have a proper backup but version control in and by itself is no backup, anything that's ever used live isn't.

ALERT! ALERT! Version control is no backup! You are never ever connected live to your backups, they wouldn't be backups in that case. Backup means: Throw this version of the files you want to backup in a safe place and hopefully never touch them again because all goes well but be assured that nothing about them has changed and they are there if you happen to need them. Also hardware you have in your house does not constitute a proper backup either, proper backups are off-site. If your stuff gets stolen, like in the case of the Project Zomboid devs, or there is a fire your project might be done for. I'm talking about a built-in solution for off-site backups using readily and cheaply (basically free) cloud offerings. Stupidly convenient, achievable by every rose-cheeked indie dev that just got started and reliable.

I made a very basic script for springs, which ties two objects together and restricts their movement with slider joints, if desired. You can chose whether force is applied to an entity or not. Whatever distance they had when tied together is the spring's neutral position. I haven't tested it a lot except for vertically connecting two boxes in a jack-in-the-box kind of fashion but there it seems to work reliably. Parenting isn't set up except for within the slider joints. I would like for some of you guys to take a look at it and experiment with it some more. Spring.lua I strongly advise against turning of the sliders and this also doesn't work as great using more than one axis and might have issues with local vs global ccordinates.

Just to be 100% clear: We are talking about the Steam client beta here which you can opt-into under Settings>Account. If you did that make sure Steam has actually updated to the latest build, by manually searching for client updates under Steam>Check for client updates.. EDIT: Well, that'll do, I guess.

Seeing Josh's Greenlight concept for SteamBox I though there might be something more tailored to Leadwerks users. The ability for Leadwerks to automatically backup projects to common cloud hosters/FTPs and similar services. The basic idea: In the Project Manager you can mark projects for auto-backups which will be conducted when the selected project is closed for another one or the users wants to exit Leadwerks when using the selected project. You can select the frequency of the backups (on every exit, maximum one per day, maximum one per week, etc.), the way in which the backup is conducted (always ask, don't ask), set up basic encryption or chose not to and (depending on the abilities of the selected online storage) decide how many copies to keep before deleting the oldest one. Backing up yo shizzle is the one of the absolute most important thing in every productive and creative field that uses computers and digital information and cloud hosters especially are a very affordable and indie friendly way with APIs that have been implemented a hundred times over. Google Drive offers 15GB of free storage, which is enough to have a decent number of backups for at least one serious project.

This issue seems fixed in the latest Steam client beta. It is for me under Linux, so please try that out and report here.

The current system requirements for Linux on the Steam store page might lead to some misinformed buyers. The OpenGL 4.0 requirement should be explicitly stated in the graphics requirement, it is under Windows so it should also be under Linux, because if you are only interested in one platform, why would you read the requirements for the other one? There should also be a note that integrated Intel graphics are absolutely not supported under Linux at the moment.

Don't forget to update your project through the Project Manager, so it can get the updated binaries which stop the crashing.

Test this out: https://drive.google.com/file/d/0B3jPhxJap2Y3MFNpa3RSTjBad1E/edit?usp=sharing This truck is simply supposed to keep rolling, which it does, but if you follow it or stay on its back you will notice that the wheels (hinge joints) keep growing with every rotation. Eventually you will end up with a monstrous caterpillar, a devourer of worlds and souls alike rolling over the terrain... My theory here is that there might be an issue with hinges rotating a multiple of 360° which makes them grow. So everyone can share in the absurdity I made a screenshot of Wheelthulu.

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?

That link was send to Kickstarter backers who pledged enough for a license since their keys aren't tied to forum accounts. And yes just "Leadwerks" is the new default install location.

No dice. The Intel drivers for Linux don't support OpenGL 4.0, yet, which is the minimum requirement for Leadwerks.

Wow, any special options tuned on in CCSM, anything out of the ordinary added to xorg.conf? What happens when you completely disabled your integrated card?

I would strongly suggest trying a newer driver version. I still have some issues with corruption in Firefox and LibreOffice that are related to the Nvidia driver even on newer versions, it just seems there are only a few programs that reveal this bug. Grab some bewer drivers from here and see if anything changes: ppa.launchpad.net/xorg-edgers/ppa/ubuntu/pool/main/n/

http://www.leadwerks.com/files/LeadwerksUpdater3.1.win32.zip

What Nvidia driver version are you using?

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.