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).
Regarding (url="http://"http://www.AmbrosiaSW.com/webboard/Forum9/HTML/001140.html")http://www.AmbrosiaS...TML/001140.html(/url), I've been playing around with some things and found out a little more about how the EVO engine works:
1.) EVO doesn't play well with other children. By that, I mean it doesn't listen to AppleEvents (as far as I can tell) and uses a lot of processor power. I'm assuming this is to give the game usable speed. Example: launch EVO, go to the Finder and try to shut down. Won't happen. 2.) It is possible for an AppleScript aplt to run in the background and watch the pilot file for desired changes, but the aplt can only check when the player is at the screen where they can open pilot files, set prefs, etc. All other times the script is suspended. 3.) I have found NO WAY to get external apps to do anything when the player is flying around in their ship, or on a spob surface.
All that having been said, I've a rough example of something that might work. I'm calling it Grigori. It sits in the EV-Plugins folder, along with another file "Grigori Data". You edit Grigori Data to define what it is you want to watch for, and what you want it to do if true.
There are several different ways to watch a variable. Let's say you want Grigori to watch a misnBit. You can say do something if misnBit=1,*1,<1,>1, 1 u list (1 within a list), 1 n list (1 not within list). Right now the math operators work well. U and N aren't totally working now, and would only be useful to see if the user had a certain weapon, outfit, etc.
In the example I've worked on, Grigori watches to see if misnBit 100 is set. This is the misnBit which is set by the first "U.E. Delivery Recruitment" string of missions. Once you complete the misn and hit "esc" to go to the intro control screen, Grigori will be able to launch the targeted OpenDoc file, in this case the OpenDoc file included with EVO (also stored in the Plug-ins Folder.
This is kind of kludgy, but with some modifications, could be made believable. Example: Alter the intro screen so it has more to do with the game. Change what the buttons are called and make the screen look like a computer interface where one can receive messages. Next, make a pers that appears only when misnBit 100 is set. This pers is a satelite a la Frozen Heart that has to deliver a certified message. It could hail with the message "Certified message in que. Please press 'esc' to transmit ID verification and receive data."
Of course, when you go to the intro screen Grigori can evaluate the pilot file and then launch the OpenDoc file.
Is this the kind of thing you were interested in?
I can post what I have done so you can look at it. I've been trying to set up an example mission string that would work as I've described, but have been unable to make a pers appear 100% of the time after a misn is done. I could do it with visBits, but what a pain :frown:.
There are many more things that need to be done, like adding the ability to watch for multiple things, and give the ability to alter the pilot file. Unfortunately, the player will have to manually reload a modifed pilot file as EVO can't be told to do it (EVO is ROWM: Read Once, Write Many). Also, Grigori has no memory of what it has checked and acted on; it will keep opening the target file for a long as misnBit 100 is set. I need to script something that will allow it to know when it has already acted on a true evaluation.
-STH
(This message has been edited by seant (edited 12-12-2000).)
Just a random thought: What if you could use EVO's buggy quicktime implementation to induce a non-fatal crash? That would quit EVO and let the script go ahead and launch the Docmaker app...
------------------ "Oh crap. I'm going to hell - I put the Bible next to Mein Kampf again." -Her Holiness, Pope Jenne "Kirby" Hubbs
Quote
Originally posted by Regulus: **Just a random thought: What if you could use EVO's buggy quicktime implementation to induce a non-fatal crash? That would quit EVO and let the script go ahead and launch the Docmaker app... **
I've never seen EVO die gracefully when dealing with a QT movie. Any specific ideas?
------------------
No... it was just a random notion. Dang.
Actually, that sounds like you've gone way beyond what I was thinking about. If it's possible, that would be an excellent way of working.
I was actually still at the level of sending the player out of EVO to look at a DocMaker document, which then launches the applet at the end which adjusts the pilot file.
Nobody has (yet) complained about being told to exit EVO to unencrypt files.
However, being able to do something by just exiting to the Entry Screen would be immense.
Can I have a play with Grigori?
Regards
Martin
------------------ M A R T I N T U R N E R
Only problem, since EVO doesn't allow background processing, you'll never be able to get this system to work very well, say it could watch bit 100, but while you are flying around you could do a mission that sets it, and then do another mission that clears it and your app will never know the difference, also the part of telling EVO what to do, because it doesn't respond to apple events. So to achieve this you'll have to tell the player what to do, and hope he does it right, you can't do it automaticall.
Chamrin
seant, this may be just the way to change syst #128. i've been working on a plug where, for part of the storyline, the player always gets returned to earth as normal, but after a certain stage is instead "rescued" somewhere else. the only way i've managed it is either to make a starting point nearby earth and then tweak the hyperspace routes (which makes the map look messy), or to have the player quit the game at a certain point and then load part 2 of the plug (which only changes syst #128)--which looks better but is more cumbersome.
------------------ Impeach Scalia!
Originally posted by Martin Turner: ** Can I have a play with Grigori? **
Of course. There's a major bug that makes it hang up if there isn't already a pilot file. I'm going to try and track down the problem tonight and will upload a rough draft if successful. I'll leave a message with the url in this thread.
Originally posted by Chamrin (edited a bit by seant): ** Only problem, since EVO doesn't allow background processing, you'll never be able to get this system to work very well. Say it could watch bit 100. While you are flying around you could do a mission that sets it, and then do another mission that clears it and your app will never know the difference. Also the part of telling EVO what to do, because it doesn't respond to apple events. So to achieve this you'll have to tell the player what to do, and hope he does it right, you can't do it automaticall. **
Notice the use of the word "kludge" in my initial post. This is an imperfect solution, but one that does work. Your criticisms are valid, but I have no way of getting around these limitations. The correct functioning of this thing relies entirely on the actions of the player. If they get a message in the game saying "press 'esc' to receive data" and then they don't, then they don't get the data and lose out on potentially useful plot info (if the setup I outlined was used). Too bad for them.
I wish the EVO engine could be told to do things via apple events, but it can't, and there's no way mburch will change it. Maybe EVN will be different since it can run in a window.... Probably not.
Originally posted by astro: ** this may be just the way to change syst #128. i've been working on a plug where, for part of the storyline, the player always gets returned to earth as normal, but after a certain stage is instead "rescued" somewhere else. the only way i've managed it is either to make a starting point nearby earth and then tweak the hyperspace routes (which makes the map look messy), or to have the player quit the game at a certain point and then load part 2 of the plug (which only changes syst #128)--which looks better but is more cumbersome. **
The initial reason I became interested in figuring out how to read pilot files is I wanted the ability to make custom plugins based on values set in the pilot file. One of the things I want to implement in Grigori is the ability to write to the pilot file. In this way the player, after meeting the criteria defined, could suddenly find themselves in a new ship or have new weapons or be a totally new system if they reload their pilot file (note: I think most of these things will be controlable via misnBits in EVN). As for putting a pilot onto a new spob after being rescued...I don't know. There isn't a flag saying when a player had ejected from his ship. There's a strictPlay flag, but that doesn't help. Unless you could come up with a sure-fire way of checking for an eject event, it wouldn't work. Also, you wouldn't be able to just appear in the rescue system as usual. You'd have to reload the pilot file. As much as I wish I could say otherwise, I don't think this is possible.
Grigori could be made to include the ability of moving plugins around automatically, however. That way, when certain conditions are met, part 2 of your plugin could be put into the Plug-In folder while part 1 is moved to a disabled plugin folder. The player would still have to quit and reload EVO, but this would work.
A feature like this is a long way away right now, though.
Originally posted by Martin Turner: Can I have a play with Grigori?
Martin-
I haven't forgotten about promising to get you a copy of Grigori to play with; I've been chasing down bugs. The biggest problem was that it would work fine as an AppleScript run through Script Editor, but wouldn't work correctly once saved as a stand alone application. It would seem to work fine, but when EV Override was quit, Grigori would continue running; It's supposed to quit.
After adding some resource editable speech routines that helps tell the player what is going on (as well as helping me trouble shoot), I've tracked down the problem (I think). I don't know if you know AppleScript, but the quit command was inside a "tell application 'Finder'" command, so I think Grigori is confused as to what to do. If I say "tell application me/quit/end tell" it should work. I'll try it this evening.
Originally posted by Martin Turner: **Can I have a play with Grigori? **
Martin Turner, please reply here so I know you got this message. It's been a while since I said I'd try and track down bugs.... I tracked down all the bugs I kept running into (including a mysterious one that turned out to be memory related) and Grigori is ready for you to look at. Yea!
Adopting Ambrosia/ATMOS' definition of beta as being something with all features implemented, Grigori is very alpha. I've tested it only on a 8600 PowerMac running OS 9 and won't get a chance to test it on anything else until I go to work tomorrow (Powerboo(OS9) and a 6100(OS8.6)). It works here, but no guarantees elsewhere.
Let me know if you (or anyone else ) tries this out and how it works (if it works :frown: ).
I must say I was starting to think it wasn't do-able, but I sat down this weekend and cleaned up my script. That increased the speed and allowed me to make actions more easily editable by the user.
Again, let me know. (url="http://"http://phair.rit.edu/~seant/EV/Grigori.sit.hqx")http://phair.rit.edu...Grigori.sit.hqx(/url)
Hmmm....if you guys know any C/C++ you could probably write an app that would stay in the background and watch for MisnBit changes. This would only work if EV actually writes to the pilot file every time you land, and not just when you switch to the "Open Pilot" screen. Once it detects a MisnBit change, it can probably simulate an escape-key-press, though I don't have the foggiest clue how to do that part. It should be possible though, there are even some OSAXen which allow AppleScripts to simulate key-presses. One thing that could be a problem is the amount of time it take to check that the bit has changed...if it takes long to check, it could be pretty weird, making the player suddenly jump for no apparent reason to the "Open Pilot" screen. Oh, another problem would be if it detects the MisnBit change while the user's in a dialog or on a planet...I guess you could have it hit return a few times before hitting escape.
If you really want to get dangerous, you could have a C program scan EV's memory space to see where the pilot file is stored in RAM, and then edit that directly (and very unsafely). It could actually work, but it depends on a lot of things (is the pilot data stored differently internally? is it accesses with a pointer or a handle? etc).
Toodles!
vasi
------------------ "Hey, who took the cork off my lunch?" W.C. Fields
A couple of things: EV does save every time you land, I can hear my HD writing
Also, none of these things will work before EV:N (and then only if the user selects an option in the prefs). For the technical view, you have to understand that Mac OS 9 and below use co-operative multi-tasking. This means that for runtime to be avalible to a background app, the foreground app has to release it. EV does this to smooth gameplay - the app gets all the runtime, so on older computers it still plays well.
All this means that no application can run while EV is active, so any watching will not work. You have to get the user to exit EV
------------------ --sitharus (url="http://"http://www.evp.f2s.com/boards/")The Alternative EV/O Boards(/url) (url="http://"mailto:sitharus@ureach.com")mailto:sitharus@ureach.com(/url)sitharus@ureach.com
Originally posted by blackhole: **A couple of things: EV does save every time you land, I can hear my HD writing;)
All this means that no application can run while EV is active, so any watching will not work. You have to get the user to exit EV **
Hmmm. Your post isn't totally correct (unless by "You have to get the user to exit EV" you mean the user has to be at the intro screen. If that's what you meant, then you are correct). Given, I'm not mburch, but I've been trying to figure this out for a while now and have conducted a fair number of experiments to try and understand how and when EVO deals with pilot files.
EVO hogs all the runtime when you are actually flying around or "on a spob," but when you exit to the start screen by pressing 'esc' EVO gives some runtime back to background applications. This can be demonstrated if you have two monitors set up for your machine. Run any given application that will produce some minimal change on the screen on your secondary monitor, and then launch EVO to run on the main monitor. If EVO ate up all the runtime, all the time, the user would not be able to launch the "Register" program.
Grigori takes advantage of EVO's start/prefs screen "friendliness" toward other applications to do all its work. To repeat what I said above, if you don't exit to the pref screen from the game by pressing 'esc', Grigori will_not_work. If you do exit to the start screen, Grigori does work.
In regards to writing something in C/C++ that would do what Grigori does: one could rewrite Grigori in C, but it wouldn't work any differently. EVO would still monopolize the computer's processor while actually playing the game. As far as I know, there is no way around this (until, as has been pointed out, EVN comes out. Since EVN is supposed to be able to run in a window, it might share processor time).