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).
Earlier this month I posted some working drafts of something I was calling persMaker. It read EVO pilot files and generated plugins that have pers resources in them (along with govt and spob resources, if necessary).
Well, the program was a mess of code. It was more of a proof of principal and a testbed for some new subroutines I'd been thinking of.
I tore the whole thing apart and recoded everything, making everything as modular as I could for use in future projects. The end result is an open beta (url="http://"http://www.hellskitchen.org/~seant/EV/persMaker/PersMaker1.0b.sit")http://www.hellskitc...rsMaker1.0b.sit(/url)
I still haven't implemented some aesthetic aspects, nor have I removed all the modular code I don't need, but I'm looking for feedback on how it works for people and what, if anything people would like to see.
(This message has been edited by seant (edited 09-27-2001).)
well, two problems. first off, it doesent work. has some error and shuts down. second, is that the other two documents that came with it cannot be opened...
------------------ DeAdBoY- (url="http://"http://www.grybs.com/harzius")Harzius Productions(/url) (url="http://"http://www.IcedEarth.com")Iced Earth(/url)
Quote
Originally posted by DeAdBoY: **well, two problems. first off, it doesent work. has some error and shuts down. second, is that the other two documents that came with it cannot be opened...
**
They are .doc files, Microsoft Word reads them. AppleWorks should, too.
You have to put the thing in the same folder as EVO to get it to work.
I have two suggestions: 1) Name the plug-in file after the pilot: e.g. "Dash Riprock's përs file", 2) Make it so you can edit certain things that can't be inferred: LinkSyst, etc.
Nice though. Interesting sound byte: prompted my brother to say to me, "So THIS is why you wanted a cable modem".
------------------ We make no destinction between terrorists and those who harbor them. - President George W. Bush, 9/11/01 (url="http://"http://www.escapevelocity.f2s.com")EV Upcoming Plug-Ins Directory(/url) | (url="http://"http://www.nohate.f2s.com")Don't Hate Me(/url) | (url="http://"http://yoshi.zzux.com/spaceport/")The Spaceport Bar(/url)
(This message has been edited by Starkiller (edited 09-27-2001).)
Originally posted by Starkiller: **1) Name the plug-in file after the pilot: e.g. "Dash Riprock's përs file" **
That's ok if you're only using a single pilot file to make a plugin, but you drag and drop 17 pilot files onto the application, you don't want the plugin named for only one of them.
Originally posted by Starkiller: **2) Make it so you can edit certain things that can't be inferred: LinkSyst, etc. **
LinkSyst can be inferred. It is the system that contains the spob the pilot last landed on. The only things that can't be inferred are STR#s associated with pers (hail quote etc). I'd rather not have any interface for the reason listed above (i.e. processing of many pilot files at once).
Keep the comments coming.
------------------ -STH
What work have you done on dominating planets?
------------------ "DOS Computers, manufactured by millions of companies, are by far the most popular, with about 70 million machines in use worldwide. Macintosh fans, on the other hand, may note that cockroaches are far more numerous than humans, and that numbers alone do not denote a higher life form." --The New York Times, November 26, 1991 (also quoted in MacAddict 4)
Originally posted by Ellmist: **What work have you done on dominating planets? **
There's some information in the documents included with the application, but here's the gist of it: if the pilot has a dominated planet, a novel govt is generated. A spob corresponding to the dominated spob is made in the plugin with the govt=to the newly made govt. The pers made also as the same govt. I need to implement code to change the govt of the system the dominated spob is in.
The syst change in govt is probably more useful, but will have some convoluted code. First it'll have to find a dominatedStellar in the pilot file, then look up the syst it's in. Next it will have to look at the other spobs in that system and whether they are inhabited. If a system is hetrogeneous (has both dominated and non-dominated spobs), the govt of the system will have to be "Contested". If the system is homogeneous dominated, then the govt will = the pers' novel govt generated by the program.
Maybe I can get that done tonight. Maybe.
There are problems when two pilots have dominated the same spob. I address all of this in more detail in the documents with the application, as noted above.
Originally posted by seant: LinkSyst can be inferred.
Generally, though, a përs is found in a Government's system, or anywhere. I suppose that can be easlity edited, though.
Originally posted by Starkiller: **Generally, though, a përs is found in a Government's system, or anywhere. I suppose that can be easlity edited, though. **
Imagine, for a moment, you are playing the mythical EVMP. I imagine that if a player is not on line, or if their connection is suddenly dropped, their ship would behave as a pers. Now the last recorded location of the player is the system of the last spob landed on. It makes a great deal of sense to me for other players to only see that player/pers in the system they were last in.
Of course, PersMaker isn't EVMP, but I'm using a model that this web board has provided: Many different people send messages to one another, but are rarely on the board at the same time. It's a shared space, but not shared time. I'm thinking of PersMaker like that. Multiple pilots share the same universe, but can not be active in it at the same time.
In theory, I could include routines that read what missionBits are set and change the bits set in EVOs active pilot file, but the standard EVO universe missions aren't setup for something like this. Imagine you have a brand new pilot file (never completed a mission) and you use PersMaker to make a plugin that has a bunch of advanced pilots. Since at least one of those pilots must have completed some missions, the results would show up in your game. Very cool when it comes to visBits, but not so cool when you are offered missions that are in the middle or end of a story line, even though you didn't do the things the story line thinks you did.
I could include some code that would allow for a choice for pers location: the pers' can either be in system that the pilot last landed in, appear in the systems of the government that likes them most, or randomly choose between the two. Convince me that it'd be worth it.
On a somewhat related note, I've gotten the subroutines necessary to set a system's govt working. If the pilot has conquored all the inhabited spobs in a syst, the system is owned by them. If, however, they have not dominated all of the inhabited spobs, a new govt called "Contested" is generated and the syst is set to that value. I'll upload the new one tomorrow.
I'm looking for feedback on how to determine who owns a spob if multiple pilots have conquored it. I have two ideas. The first is that the pilot that most recently conquored the spob owns it. Simple, but it doesn't really seem fair. The other idea is if there are pilots who should be enemies (based on the ally and enemy values calculated) these pilots are narrowed down to the four most recent conquorers of the spob in question. Their pers numbers are thrown into the alwaysPers value for that system and the spob govt is set to equal the "Contested" govt. That way, when ever you go into that system you can see pers' kicking each other around the screen.
I think I just like the idea of seeing auto generated pers' kick one another around. If I could guarantee more than 4 pers' in a syst, I'd stick as many as possible in 1 system for a battle royale.
Thoughts?
Originally posted by Starkiller: **They are .doc files, Microsoft Word reads them. AppleWorks should, too.
welll.... i dont have microsoft word, and apleworks doesent read them. put 'em in simpletext format, eh? and putting the app into the same folder as EVO... thats not very helpful...
Originally posted by DeAdBoY: **and putting the app into the same folder as EVO... thats not very helpful...
You just put the application into the EVO folder. That's all you do, and it will work fine.
This new version gives a nil object exception on every pilot I try and drag/drop doesn't work. I can't drag it on to the program.
If you still have my Vionan Pilot, he will crash it ust like the rest of my pilots.
It will creat the plug and play the sound but the plug is empty.
Also I would thread that sound so that it doesn't stop me while it plays. I can't hit the quit button till it stops.
(This message has been edited by ThorPrime (edited 09-28-2001).)
Originally posted by ThorPrime: **This new version gives a nil object exception on every pilot I try and drag/drop doesn't work. I can't drag it on to the program.
It will creat the plug and play the sound but the plug is empty.**
The new version is posted.
I don't understand why things aren't working for you. The previous version handled drag and drop fine (tested with 8 simultaneous pilot files). I still have your Vionan pilot file and have used it in testing.
I guess I need to throw some diagnostic error messages in. It's strange that it makes a plugin file, but there's nothing in it. That means it was able to find the data files, decrypt the pilot file, make the necessary new resources, but crapped out while writing the resources. Something to check: make sure none of the EVO data files or plugins are open in ResEdit or Escape Velocity. I ran into weird problems similar to what you are describing when I forgot to close a data file once.
I'll throw in diagnostic error codes tonight.
Originally posted by DeAdBoY: **welll.... i dont have microsoft word, and apleworks doesent read them. **
What version of AppleWorks are you using? Version 5 includes DataViz translators which handle .doc files just fine. Version 6, sadly, does not.
------------------ world keeps turning
I was really surprised that you had finished the government code already.
I don't want to be nit-picky, but you do need to consider making allies for the governments of the player. This would have to be computed by saying that if a government liked the player(his/her karma), it would be the player's ally. The opposite goes for enemies. You would exclude the government of the player of course.
Not very important, but I just wanted to make sure you didn't miss over something like this as I am sure I would.
Originally posted by Ellmist: **I was really surprised that you had finished the government code already.
I don't want to be nit-picky, but you do need to consider making allies for the governments of the player. This would have to be computed by saying that if a government liked the player(his/her karma), it would be the player's ally. The opposite goes for enemies. You would exclude the government of the player of course. **
Way ahead of you cap'n. The code does something like this: Make an array where index=govt id (0 based) and the array's value is the players legal status in that system. Then look and see what systems have been visited. If a system has been visited, get the players legal status in that system and the govt id of that system. Now, using the govt id, stick average the legal status into the array. Example: if system 128 is visited, the govt id=128-128=0 and the legal status=(let's say) 15. govtArray(0)=15+30/2
Grok?
Anyway. Once all of the explored systems are entered into the array, the array is sorted so the highest legalSTatus is found. That array index is used to look up what goct likes the player most. That value equals the player's ally. Looking up the govt that is the player's ally also yields the player's enemy.
The very limited tests I've run have shown both the govt selection and weapon selection routines to work fairly well.
I have what I think is the final version. There are aspects that I'm not entirely pleased with (like determination of who owns a planet), but it's good enough for an initial release.
I'll post the app tomorrow morning and hope for feedback.
-STH
------------------ "Christ, what if the terrorists' base of operations turns out to be Detroit? Would we declare war on the state of Michigan? I suppose we'd have to." -U.S. Sen. John McCain, misquoted in (url="http://"http://www.theonion.com")"The Onion"(/url)
Originally posted by Phil Barron: **What version of AppleWorks are you using? Version 5 includes DataViz translators which handle .doc files just fine. Version 6, sadly, does not.
appleworks 6.... shrug oh well, i guess i can live without the docs...
Originally posted by DeAdBoY: **appleworks 6.... shrug oh well, i guess i can live without the docs... **
I've saved the docs as text now.
Originally posted by seant: **I've saved the docs as text now.
thats more like it! hands seant a cookie
The reason the translators are no longer included is because they are not Carbon. But they will still work with AppleWorks 6 in OS 9. Haven't tried X.
Originally posted by seant: I'll post the app tomorrow morning and hope for feedback.
Ok, so "tomorrow" turned into a few days. I've been putting in late hours at work, so bla.
Anyway, I think I've chased the bugs that I know about out of PersMaker. I've tested it with all the EVO pilots that are on the (url="http://"http://pftn.evula.net/")PFTN site(/url) as well as with the few pilots I had, or made using PFE.
New version is at (url="http://"http://www.hellskitchen.org/~seant/EV/persMaker/")http://www.hellskitc...t/EV/persMaker/(/url)
There are two docs, plus the application in that folder. You don't need the docs as they are also encluded with the compressed package.
Any bugs, PLEASE tell me, as I want to finish this thing.
On a side note, using the PFTN pilots was fun in that previous work was coming back to haunt me. One bug I ran across was caused by systematic errors introduced into pilot files when they were edited using PFE2b. I also found one pilot file at PFTN that was edited using a beta version of PFE3. Neat.
(This message has been edited by seant (edited 10-04-2001).)