Jump to content
Lunarovich

Can't attach script to object

Recommended Posts

I'm using the Ubuntu distribution of Linux. Everytime I try to attach a script to an object via the editor, the script appears to be attached and I save the map. When I select another object and select the object in question again, there is no script attached anymore. Likewise, the runtime completely ignores the script.

Link to post

I've started a project in Windows and the project is on the NTFS partition. Other modifications do get saved.

 

EDIT: It's definitely a NTFS partition issue. Linux version of LE cannot handle it. On the ext4 partition, scripts get attached as expected.

Link to post

I don't even know how file paths in separate drives work on Linux? That would be my guess, if you have multiple drives you are working with.

Link to post

They work just like every other file path: It's mounted into the same tree:

 

For example: '/path/to/a/file'

 

Let's forget that partitions are a thing for a moment and call everything drive, you can substitute drive for partition in this example.

 

'/' is on your boot drive of course, let's call that drive1 for example while the 'path' folder of '/path' might be on drive2, the 'to' folder of '/path/to' might even be back on drive1 and the 'a' folder of '/path/to/a' might be an a different drive entirely like drive3. The file 'file' naturally must be on the last drive in that hierarchy.

 

 

Bottom line is: You usually do not need to care about what drive you on right now, it's completely transparent. The one thing that doesn't work is hardlinking across different partitions even.

 

The important thing with this issue is the file system: NTFS doesn't store permissions in a compatible way with the side effect of not being able to execute file on NTFS partitions and is not case sensitive, that alone is enough to throw a serious curve-ball your way.

 

So yes, anything more than read-only file storage isn't recommended to do with NTFS on Linux. Nice to cut down on redundant storage when using a dual boot, useless for working with.

My guess is that's the reason why OS X only ships a read-only NTFS driver, so you don't even get tempted to try stuff that wasn't meant to work.

Link to post

As what regards execution, from my experience, it's sometimes possible to execute a file on the NTFS partition and sometimes it's not. For example, I was able to run a LE game executable on an NTFS drive in Linux.

 

P.S. The reason I was using NTFS was having a dual boot. I needed to store files on the partition that's accessible both to Linux and Windows. An Ext4 partition is invisible, as if it was inexistant, in Windows.

Link to post

I've run into this issue myself on Debian Linux. One thing that seems to make this work is to manually navigate to the file's absolute path in the browser, i.e. /media/<yourDrive>/path/to/file

 

It seems to be related to cross-device symlinks.

 

I tend to keep all my work on an external HDD, which is partitioned as ntfs just so windows can read it with minimum hassle myself. There are tools to browse ext partitions, but they are slow and kind of a pain :/

Link to post

Huh, this maybe why I had trouble when I tried to run Linux on my main machine.

 

I think the best way I've found to cross-develop is to have 2 machines with the project on a git. Of-course, not everyone has 2 PCs, and the only need to cross-develop is if you're building applications for each OS.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...