pers activator ready

seant

All-

With the latest upgrade to the EVNgine which allows defense fleets to be correctly calculated for spobs added in plugins, my life became easier and a utility I named BitChanger is usable/ready for testing, but lacks one major ability. I'm asking for the advice of the community as how best to approach the issue. Read on....

As I said in a recent post, BitChanger allows one to activate perses defined in a plugin. What's the big whoop, you ask? Well, pers data is stored as either a 1 (alive) or 0 (dead) in the pilot file. When you start a new pilot file, the game engine reads the data files and plugins and sets all the appropriate bits in the new pilot file to 1. As you kill them off in the game (if they are killable) those bits are set to 0.

The problem is that there is currently no way for the engine to know whether a brand new pers added in a plug in is new and inactivated or is killed. Therefore, if yo are designing a plugin and put a new pers in it, that pers will only show up if a new pilot file is made after the plugin is installed.

Which sucks if you want to write an add on to a mission thread and don't want to have the player have to start over.

As a means around this problem, BitChanger allows the plugin maker to define a configuration file. The configuration file is a text file listing which pers IDs to turn on. The configuration fiel is placed in the plugin folder (I've even successfully tested a plugin in which the data fork contained the BitChanger data and the resource fork contained the actual game mods). With the exception of asking for a pilot file, BitChanger asks for nothing, scanning the plugin folder for the info it needs. It reads the configuration file and makes sure the pers resources defined are turned on in the pilot file selected.

The problem is, how can I make sure BitChanger doesn't accidentially re-activate a pers? In theory, there could be multiple configuration files in the plugin folder. Because BitChanger automatically scans the folder, it would encounter any previously used configuratio file.

One of the ideas I had was to write the name of the plugin and the pers IDs activated to the data fork of the pilot file, but discovered that writing to the data fork when a resource fork is present destroys the resource fork (the converse is not true).

The other idea is to make a new resource stored in the pilot file that saves that data. So, npil 130 would contain BitChanger data. I could even encrypt that data using the same method that the rest of the pilot file.

The final idea is a BitChanger preference file. This would be fine, but would mean that the data on which perses had been previously activated would be seperate from the pilot.

Any sage advice? I'm strongly leaning toward making npil 130 for my use, though I'm sure doing that violates some basic programming ethic I'm unaware of.

-STH

------------------
"Create enigmas, not explanations." -Robert Smithson

mrxak

Quote

Originally posted by seant:
**One of the ideas I had was to write the name of the plugin and the pers IDs activated to the data fork of the pilot file, but discovered that writing to the data fork when a resource fork is present destroys the resource fork (the converse is not true).

The other idea is to make a new resource stored in the pilot file that saves that data. So, npil 130 would contain BitChanger data. I could even encrypt that data using the same method that the rest of the pilot file.

The final idea is a BitChanger preference file. This would be fine, but would mean that the data on which perses had been previously activated would be seperate from the pilot.

Any sage advice? I'm strongly leaning toward making npil 130 for my use, though I'm sure doing that violates some basic programming ethic I'm unaware of. :)**

For the first method, could you simply copy the resource data temporarily into memory, write to the data fork, and then re-write the resource data back in?

As much as the second method sounds like the best way to go about it, I don't think it would be. It seems risky to be adding new stuff to a pilot file. Of course, the first method would have this same problem.

I think a preference file might be best. It keeps the pilot file clean, and so long as you make sure that the preference file keeps tabs on which pilot file has which bit states changed, it would work fine. It also provides an easy way to start over. Perhaps the user wants to reactivate those përses. Or maybe they want to share that pilot file with somebody else. The only issue would be to ensure that as many pilot files as possible are kept track of. It would also be nice to get a listing of pilot files stored in there and be able to reset (delete) their state data individually.

Zacha Pedro

Make a pref file. Pilot files are not meant to be traded (though they are), and even if they are, it won't make a big difference. The best thing would be to make a pref file containing one resource type (päpt, or pers activator plug tracking), and as many resources as there are pilot files for which information needs to be tracked down, identified by their name, identical to the one of the pilot (there can't be two pilots with the same name since it's the name of the pilot file, that are hopefully all in the unique pilots folder in the unique install of Nova). Then, inside each resource, you put the names of the plugs for which pers have already been activated for the pilot.

Wierd that writing to the data fork nukes the resource fork (goes check Inside Macintosh: Files).

------------------
The (url="http://"https://secure.ambrosiasw.com/cgi-bin/store/hazel.cgi?action=serve&item;=breakdown.html&BREAKDOWN;_SKUID=1480")Ambrosia Mac CD(/url) with other registrations - 5$. Paying for (url="http://"http://www.ambrosiasw.com/games/evn/")EV Nova(/url) as it's such a great game - 30$.
The (url="http://"http://www.ambrosiasw.com/games/evn/tshirts.html")1337 EV Nova T-shirt(/url)(url="http://"http://www.ambrosiasw.com/webboard/Forum25/HTML/000003.html#ZachaPedro05-18-200409:42AM") (/url) - 22$. The (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) by wOOtWare to tinker with your Nova - FREE!
The feeling you're a Nova geek - priceless.
There are things money can't buy or that are free, for everything else, there's indeed Mastercard.

seant

Quote

Originally posted by mrxak:
For the first method, could you simply copy the resource data temporarily into memory, write to the data fork, and then re-write the resource data back in?

Yeah, that would work, but seems like a waste of time, ya know?

Quote

Originally posted by mrxak:
As much as the second method sounds like the best way to go about it, I don't think it would be. It seems risky to be adding new stuff to a pilot file.

In the tests I've done, the EVNgine is quite forgiving of mucking with pilot files. I can throw in other resources without problems. I was leaning toward the method of making a new resource mainly because I was also looking to solve an identification problem I was facing in relation to (url="http://"http://www.AmbrosiaSW.com/webboard/Forum9/HTML/004663.html")another project(/url).

I guess I'll go with the pref file idea. I don't like that the data is stored seperately from the pilot file that is modified, but oh well.
-STH

------------------
"Create enigmas, not explanations." -Robert Smithson

SpacePirate

Meh, I liked the additional resources idea. Unless Matt makes some weird change to the engine, it should not affect the game at all.

~ SpacePirate

(edit)Did you ever do anything with the shared universe anyways? I'd still like to see something like that implemented sometime. :p(/edit)
------------------
Fear the SpacePirate,
He made a (url="http://"http://www.evula.org/infernostudios/search.html")plug-in search page(/url)...
And he'll board your ship! -mrxak

(This message has been edited by SpacePirate (edited 06-07-2004).)

rebelswin_85

Quote

Originally posted by seant:
The other idea is to make a new resource stored in the pilot file that saves that data. So, npil 130 would contain BitChanger data. I could even encrypt that data using the same method that the rest of the pilot file.

This sounds the most practical to me... as Zacho Pedro mentioned, if the data is external to the individual pilot files then if you had pilot files with the same name stored in seperate places they might become confused. A similar problem might occur if you changed the name of your pilot file... for instance, I rather like to make duplicates of my pilot file when I've gotten a ship outfitted a way I like or have reached a major mission branch. (Purists may sneer if you wish, but I prefer not to waste time playing through the whole game multiple times to experience all of the missions...) If I understand the use of the preferences file correctly, your application would see any pilot file whose name was not in its records as a new file, and set pers bits accordingly, which would be a bit annoying. An extra resource within the pilot file itself would solve this, and to me seems a much neater way of handling the problem... unless MBurch has some sort of objection to it, I think that is the way to go. Or I could be totally wrong about all of this, as my programming experience is very minimal...

------------------
Pinky, are you pondering what I am pondering?
I think so, Brain, but if they called them sad meals, kids wouldn't buy them.

Zacha Pedro

Quote

Originally posted by rebelswin_85:
**This sounds the most practical to me... as Zacho Pedro mentioned, if the data is external to the individual pilot files then if you had pilot files with the same name stored in seperate places they might become confused. A similar problem might occur if you changed the name of your pilot file... for instance, I rather like to make duplicates of my pilot file when I've gotten a ship outfitted a way I like or have reached a major mission branch. (Purists may sneer if you wish, but I prefer not to waste time playing through the whole game multiple times to experience all of the missions...) If I understand the use of the preferences file correctly, your application would see any pilot file whose name was not in its records as a new file, and set pers bits accordingly, which would be a bit annoying. An extra resource within the pilot file itself would solve this, and to me seems a much neater way of handling the problem... unless MBurch has some sort of objection to it, I think that is the way to go. Or I could be totally wrong about all of this, as my programming experience is very minimal...

**

Nope, you're right, I did not think about the possibility of people duplicating pilots and giving them different names (however, have identically named pilots in different places is weird and not worth of being supported). All of a sudden, I'm not quite sure of what should be done, except that I don't think it's a good idea to put it in the data fork, we may as well put it in the resource fork (of the pilot file), but maybe make not a npil, another resource kind, with ID 128.

------------------
The (url="http://"https://secure.ambrosiasw.com/cgi-bin/store/hazel.cgi?action=serve&item;=breakdown.html&BREAKDOWN;_SKUID=1480")Ambrosia Mac CD(/url) with other registrations - 5$. Paying for (url="http://"http://www.ambrosiasw.com/games/evn/")EV Nova(/url) as it's such a great game - 30$.
The (url="http://"http://www.ambrosiasw.com/games/evn/tshirts.html")1337 EV Nova T-shirt(/url)(url="http://"http://www.ambrosiasw.com/webboard/Forum25/HTML/000003.html#ZachaPedro05-18-200409:42AM") (/url) - 22$. The (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) by wOOtWare to tinker with your Nova - FREE!
The feeling you're a Nova geek - priceless.
There are things money can't buy or that are free, for everything else, there's indeed Mastercard.

seant

Quote

Originally posted by Zacha Pedro:
**Nope, you're right, I did not think about the possibility of people duplicating pilots and giving them different names (however, have identically named pilots in different places is weird and not worth of being supported). All of a sudden, I'm not quite sure of what should be done, except that I don't think it's a good idea to put it in the data fork, we may as well put it in the resource fork (of the pilot file), but maybe make not a npil, another resource kind, with ID 128.
**

In the end I made a npil res ID 130 that I encrypt using the same method as the other resources. More to follow.

------------------
"Create enigmas, not explanations." -Robert Smithson