Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
And before I start - yes I searched, but all I found was a post from Kame from last year that said dont lock Nova Files but never mentioned the reason.
I mean, the game-engine doesnt write into any of the data files or plug files, so why should locking them cause Nova (1.0.5) to barf? The reasons I wanted to lock a plug were; 1) to keep myself from messing up a final version accidently; 2) I thought it might be a good idea to lock plugs that were posted to the add-ons pages. But when I tried locking a plug file it become non-functional, but evidently some part of it triggered enough game-engine logic that Nova went into a hang condition on Quit. I command+ctrl+powerButton rebooted, unlocked the plug, and everything worked fine. Then tryed locking the plug again - same problem, same symptoms. I noticed when I first started developing plugs last year that locking the data files in the Nova Files folder also causes Nova (1.0.2, I think) to not work as well (Ive forgotten the specific symptoms).
Oh, and please, Im not interested in any guesses. Educated and reasoned surmise is OK, but no pure guessing please. Thanks.
(edit: forgot to state versions) ------------------ "There are no bugs in my code, ... only undocumented features." - corollary #3 Please use the (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/search.cgi?action=intro&default;=9")SEARCH(/url) feature before posting a new question. For EV:Nova development questions, please read the (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=guides&display;=name&file;=bible_and_tmpls.sit.bin")EV Nova Resource Bible(/url) first. Provided by bit-banger Arturo: a (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=utilities&display;=name&file;=ResourceInterdependence.hqx")Resource Interdependence table(/url) and the (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=plugins&display;=name&file;=ShieldBubbles1.0.hqx")Shield Bubbles 1.0 plug(/url)
(This message has been edited by Arturo (edited 06-12-2003).)
Quote
Make a backup or two of your plugin every time you make major changes. Also, don't keep all of your backups on the same disk, use a zip disk or a CD-RW to keep a copy of the plug in case your HD fails.
Anything that you do to stop people from editing your plugin can easily be undone if they know what they are doing.
------------------ Eat blazing electric death! (url="http://"http://www.evula.org/infernostudios/ept/")Unofficial EV and EVO Ports(/url): Both currently in FC1. Please post any bugs (url="http://"http://www.ev-nova.net/forums/viewforum.php?f=26")here(/url).
i know you said no guesses please, but... i think that maybe locking the files also prevents evn from reading them. so evn sees the plugin, but just stares at it and doesn't know what to do.
just think of a box with a lock on it on your desk. you have it, but all you can do is look at the outside.
------------------
Originally posted by SpacePirate: **Make a backup or two of your plugin every time you make major changes. Also, don't keep all of your backups on the same disk, use a zip disk or a CD-RW to keep a copy of the plug in case your HD fails. **
I'm an experienced programmer, I always maintain two online backups and 1 off-line backup of all development projects.
Originally posted by SpacePirate: **Anything that you do to stop people from editing your plugin can easily be undone if they know what they are doing. **
I'm not trying to stop anyone from intentionally editing the plugs. I'm trying to prevent inadvertant corruption.
Oh, and thanks for answering my question.
Originally posted by HandsofDeath: **i know you said no guesses please, but... i think that maybe locking the files also prevents evn from reading them. so evn sees the plugin, but just stares at it and doesn't know what to do. <snip> **
Nope, you're wrong. All that locking any Mac file prevents is writing to that file. Try an experiment yourself and see. You can read it, copy it, duplicate it, just not write to it. That's whay I asked the question in the first place, since the Nova game-engine doesn't write to any of its data files nor does it write to any plug files. The only files the game-engine writes into are the debuglog.txt and pilotlog.txt files, thats it.
(edits: bloody UBB) ------------------ "There are no bugs in my code, ... only undocumented features." - corollary #3 Please use the (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/search.cgi?action=intro&default;=9")SEARCH(/url) feature before posting a new question. For EV:Nova development questions, please read the (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=guides&display;=name&file;=bible_and_tmpls.sit.bin")EV Nova Resource Bible(/url) first. Provided by bit-banger Arturo: a (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=utilities&display;=name&file;=ResourceInterdependence.hqx")Resource Interdependence table(/url) and the (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=plugins&display;=name&file;=ShieldBubbles1.0.hqx")Shield Bubbles 1.0 plug(/url)
Hopefully this qualifies as an educated guess
As Arturo stated, locking a file prevents it from being written to, but do you know for a fact that plugins are not being opened with write permission (fsRdWrPerm in C)? What is possible is that Nova is trying to open the plugins with fsRdWrPerm for some reason, but since they are locked, the system is opening them read-only (fsRdPerm). I can not say exactly because I have never run into a bug like this, but Nova may be calling something that tries to write to the file, like UpdateResFile, which fails because Nova wrongly assumed they could be written to. Note that calls like UpdateResFile would not actually change anything, so the plugin developer would not think the file was being written to.
Of course, mburch is the only one who could know for sure why it is crashing...
------------------ (url="http://"http://www.ariossoftware.com")Arios SoftWare(/url) (url="http://"http://www.ariossoftware.com/programs/evone/")EVONE 1.0.0 - the plugin editor for EV/EVO/EVN(/url)
(This message has been edited by AriosSw (edited 06-12-2003).)
maybe your right about my guess...
but...how about this...
locking a file makes so you cannot move it, right? evn is trying to copy data from the plugin to its memory. having the plugin locked means it cannot copy the data, so it just freaks and crashes.
Originally posted by AriosSw: ** <snip> What is possible is that Nova is trying to open the plugins with fsRdWrPerm for some reason, but since they are locked, the system is opening them read-only (fsRdPerm). I can not say exactly because I have never run into a bug like this, but Nova may be calling something that tries to write to the file, like UpdateResFile, which fails because Nova wrongly assumed they could be written to. Note that calls like UpdateResFile would not actually change anything, so the plugin developer would not think the file was being written to.
Of course, mburch is the only one who could know for sure why it is crashing... **
This is exactly my suspicion. That the game-engine opens all files with read and write permission. But why? I can't think of any logical reason why the game-engine would need to write into any of those files. And if system calls for writing were executed, then the file's modification date would be updated. Is a puzzlement. Maybe mcb will see this and respond.
Originally posted by HandsofDeath: ** locking a file makes so you cannot move it, right? <snip> **
Nope, incorrect. The ONLY thing that locking a file with the Get Info dialog (or ResEdit, or a system call from within another app) does is prevent writing data into that file. You can still move it all over the universe and it can still be read by any application capable of dealing with its inherent data.
------------------ "There are no bugs in my code, ... only undocumented features." - corollary #3 Please use the (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/search.cgi?action=intro&default;=9")SEARCH(/url) feature before posting a new question. For EV:Nova development questions, please read the (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=guides&display;=name&file;=bible_and_tmpls.sit.bin")EV Nova Resource Bible(/url) first. Provided by bit-banger Arturo: a (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=utilities&display;=name&file;=ResourceInterdependence.hqx")Resource Interdependence table(/url) and the (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/show.pl?product=evn&category;=plugins&display;=name&file;=ShieldBubbles1.0.hqx")Shield Bubbles 1.0 plug(/url)
Originally posted by Arturo: Maybe mcb will see this and respond.
I pointed this topic out to him a while back. He's looking into it.
------------------ Moderator- (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=9&SUBMIT;=Go&mrxak;=cool")EV Developer's Corner(/url) | (url="http://"http://www.ambrosiasw.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=69SUBMIT=Go&mrxak;=cool")Uplink Web Board(/url) | (url="http://"http://forums.evula.com/viewforum.php?f=18")mrxak's Assorted Webspace Forum(/url) | (url="http://"http://forums.evula.com/viewforum.php?f=48")Starcraft Forum(/url) | | (url="http://"http://directory.perfectparadox.com/profile.php?id=00008")My Profile(/url) | (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/postdisplay.cgi?forum=Forum10&topic;=007599-2&whichpost;=mrxak11-06-200203:22PM")mrxak(/url) (url="http://"http://www.evula.org/mrxak/")mrxak's Assorted Webspace(/url) | (url="http://"http://www.evula.org/mrxak/Haikus/haikuarchive.html")The Haiku Archive(/url) | (url="http://"http://www.evula.org/mrxak/EV/N/mbspt/mbspt.html")mrxak's Big Secret Plug-in/Tutorial(/url) | (url="http://"http://www.evula.org/mrxak/EV/N/amtc/amtc.html")A mrxak TC(/url) | (url="http://"http://www.ambrosiasw.com/cgi-bin/vftp/dl-redirect.pl/TheChallenge102.sea.bin?path=evn/plugins&file;=TheChallenge102.sea.bin")The Challenge v1.0.2(/url) (url="http://"http://www.AmbrosiaSW.com/cgi-bin/ubb/search.cgi?action=intro")Search First(/url) | (url="http://"http://www.modlink.net/guides.php")Uplink Guide(/url) | (url="http://"http://www.evula.com/survival_guide/")EV/O/N Guide(/url) | (url="http://"http://www.ambrosiasw.com/cgi-bin/ubb/forumdisplay.cgi?action=topics&number;=31&SUBMIT;=Go")Plug-in Guide(/url) | (url="http://"http://www.AmbrosiaSW.com/webboard/Forum9/HTML/003091.html")Plug-in Testers(/url) | (url="http://"http://www.AmbrosiaSW.com/webboard/Forum9/HTML/003196.html")Developers(/url) | (url="http://"http://www.AmbrosiaSW.com/games/evn/addons.html")Nova Addons(/url) | (url="http://"http://www.resexcellence.com/support_files/resedit.shtml")ResEdit(/url) | (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) If it's just a game, and life is all a game, then isn't the game real life?
Originally posted by Arturo: **Nope, incorrect. The ONLY thing that locking a file with the Get Info dialog (or ResEdit, or a system call from within another app) does is prevent writing data into that file. You can still move it all over the universe and it can still be read by any application capable of dealing with its inherent data.
**
umm, ok but i made a quick text file, locked it, then i tried moving it into a folder and it said i couldn't.
mrxak: Thanks.
Originally posted by HandsofDeath: **umm, ok but i made a quick text file, locked it, then i tried moving it into a folder and it said i couldn't. **
sigh What type of Macintosh are you using? What OS are you using? What did you use for a text editor? How specifically did you lock the file? (if you used OSX permissions, that may be why it won't move) How specifically did you try to move the file? What folder were you moving the file from? What folder were you moving the file to? What was the specific message that told you the file was immovable?
Because if you lock a SimpleText file with the Get Info dialog it can be copied, read, duplicated, and moved from folder-to-folder and volume-to-volume at will.
Just to clarify for mrxak, Matt Burch is now aware of this, and is looking at the situation. As far as I can tell, locking a plug-in is not intended to break Nova in any way.
Fear not! Our top mind is now examining the issue.
all the best,
Dave @ ATMOS
------------------ Co-creator of EV Nova
Originally posted by Arturo: **I mean, the game-engine doesnt write into any of the data files or plug files, so why should locking them cause Nova (1.0.5) to barf? **
This will be fixed in a future update.
mcb
------------------ "If it's not on fire, it's a software problem."
Originally posted by mburch: **This will be fixed in a future update. **
Thanks for taking the time to look into it Matt.
Originally posted by mburch: This will be fixed in a future update.
Fear syntaxian personage.
Originally posted by Arturo: **mrxak: Thanks.
ok then...
1> flat panel imac with super drive 2> osx 10.2.6 3> TextEdit 4> get info and hit the "locked" option 5> click and drag 6> desktop 7> right into the HD 8> "the operation cannot be completed because you do not have sufficient privileges for some of the items."
so those are your answers about what i did. i didnt try opening it, because i know you can. i know you can copy all the text within it as well.
Originally posted by HandsofDeath: **ok then...
1> flat panel imac with super drive 2> osx 10.2.6 3> TextEdit 4> get info and hit the "locked" option 5> click and drag 6> desktop 7> right into the HD 8> "the operation cannot be completed because you do not have sufficient privileges for some of the items." <snip> **
Right. It's the Mac OSX permission settings that are preventing the move, not the locked status. I don't run OSX, but I am familiar with unix, so I can't tell you how to get at the file and directory permissions settings control panel (or whatever it's called under OSX). Try using your built-in help facility and see if it has anything about the subject "privileges" or "permissions". Each file or directory has an owner (you), belongs to a user group (I don't know how that's implemented under OSX), and contains permission bits (these may or may not be associated with the Finder's lock function). There are three types of access: read , write (w), and execute or search (x). Evidently some of those permissions are set for either the file or the directory such that you are prevented from moving the test file where you want to move it.
Try this, unlock the file and see if it can be moved then. If it can, then what's happening is that the Finder lock setting is being translated into a permissions setting. You have to figure out how to diddle the permissions settings to mimic previous Mac OS9 behaviour. Ah... try that too. Run your same experiment in the OS9 environment and I'll bet that there's no problem with moving a locked file around.
Maybe an experienced OSX user will see this and be able to clarify better than I can.
Originally posted by Arturo: **Maybe an experienced OSX user will see this and be able to clarify better than I can.
OS X will not let the user move a locked item between folders. It will let you reposition the item within the same folder. HandsOfDeath is seeing correct behavior.
Edit: Hmmm, to me that came across as sounding mean - don't take it that way.
(This message has been edited by AriosSw (edited 06-13-2003).)
Originally posted by AriosSw: **OS X will not let the user move a locked item between folders. It will let you reposition the item within the same folder. HandsOfDeath is seeing correct behavior. **
Thanks, that clears up that little misunderstanding. I just love it when they change usage definitions like that. And that makes yet another good reason for me NOT to change to OSX.
(This message has been edited by Arturo (edited 06-13-2003).)
Originally posted by AriosSw: OS X will not let the user move a locked item between folders. It will let you reposition the item within the same folder. HandsOfDeath is seeing correct behavior.
That's... odd... You should be able to move a locked file between folders you have write access to, as moving a file is changing directories, not files. Locking a file (or setting permissions to 444 for UNIX geeks :p) should only prevent execution and writing to that file, not moving, deleting or anything.
I'll look more at what OS X does when I'm back on my iMac, there's obviously something deeper than UNIX permissions at work there.
------------------ --sitharus (url="http://"http://www.sitharus.com/")Me, online!(/url) Insults are the arguments employed by those who are in the wrong. Jean-Jacques Rousseau
Originally posted by blackhole: **That's... odd... You should be able to move a locked file between folders you have write access to, as moving a file is changing directories, not files. Locking a file (or setting permissions to 444 for UNIX geeks:p ) should only prevent execution and writing to that file, not moving, deleting or anything.
I agree that it is odd. It may very well be a Finder-enforced "feature" that has no bearing on the UNIX permissions.