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 needs testers!
With the help of Guy, I have been secretly developing an update to SpacePort. In fact, unless it got leaked, the only people who knew for sure that I was doing this were Guy, SpacePirate (the original author), and myself. I have hinted at this, as some of you may recall, but I never explicitly stated it; in fact, there was even some question as to whether or not I was developing a "competing" application. Suffice to say, I don't have the attention span to do that...but I can edit other peoples' code (however ugly it may be - trust me, SpacePort's code was pretty ugly when I started, and now is much, much worse). It's probably a good thing I took over maintenance of SpacePort - SpacePirate no longer even has any clue what half the code in the application does.
For those not in the know, SpacePort is an application that will take any Escape Velocity or EV Override plug-in (with a few exceptions; see below) and convert it into an EV Nova plug-in. It doesn't just change the creator and type codes, however; it actually goes through the resources and converts the data into a format accepted by EV Nova , adding modifications as necessary to best replicate the behavior of Escape Velocity and EV Override. It can convert single files or entire folders, and even include special plug-ins if the latter.
There's no way I'm posting a changelist here; far too much has changed, and it will take a long time to compile a list of it all. I can, however, list its shortcomings, which are now vastly fewer in number than they were prior to my obtaining the source:
- Doesn't recognize pre-1.0.2 EV Override plug-ins; will cause garbage values in fields specific to EV Override 1.0.2 - Doesn't convert oopses with a spob set to -2 into crons as it should, and doesn't convert the corresponding strings - Doesn't interpret jamming flags, as doing so would be way too much work and would not work in all situations*); instead lists jamming values in the output log to ease conversion to EV Nova -friendly jamming
I'm sure there's more, but I can't think of anything right now.
Please note: This is a beta version. While I do not expect it to be unstable in any way, I have modified the code heavily, and any number of potential problems could occur. Please report any problems you encounter, other than those listed above. If you have any shortcomings found in the previous version of SpacePort (1.1.2), check to see if they are still present; if so, please let me know.
With that out of the way: Download SpacePort 1.2.0b1here.
System requirements: - Mac OS 8.6 or later (including OS X - in fact, OS X users get additional aesthetic features) - A registered copy of EV Nova (not actually required, but without it the plug-in is of little help) - A text document to record bugs
*Specifically, if the developer uses all four jamming types and includes a second ModType/Val, there is no way to include all five ModType/Vals.
This post has been edited by orcaloverbri9 : 25 March 2006 - 10:52 AM
Thanks for doing this, Orcalover. You help to make certain that the vast library of creative work made by people in the decade+ that EV's been out is not lost.
I'll have to test it with Oreste.
Edit: Okay, tried Oreste. None of the outfits are named and all of the new graphics are tinted some color or other. Also tried Pale; landed on Levo and got a mission with no mission text (i.e. just the yes/no buttons) and the custom target graphics were all similarly tinted.
This post has been edited by Derakon : 23 March 2006 - 01:07 AM
@orcaloverbri9, on Mar 22 2006, 08:16 PM, said in [ANN] SpacePort 1.2 Enters Beta:
- Doesn't convert dudes with a spob set to -2 into crons as it should, and doesn't convert the corresponding strings
Shouldn't that be "oopses"?
Anyway, assuming this works well, it should be a great help for those times when people ask for released TCs, especially if this beta test results in a fair number of converted TCs.
@Derakon: That is a result of the various bugs with PICTs in Nova 1.0.9. Run the plug through BlitZen, transforming the PICTs into 16-bit with no compression, copy the resulting PICTs into the converted plug, and everything should work.
@orca: You may wish to put a warning about the 1.0.9 PICT bug in your documentation, along with a link to BlitZen.
Edwards
You two did very well hide what you were doing (that explains the lack of updates for plug-in archiver...). I have an offer for you: I test this version of SpacePort (and, incidentally, resume working on Rezilla, but that was already on schedule, and beta test a certain ambrosia game as always), and you test the second custom version of Rezilla and you get back to work on plug-in archiver. How about that?
Well, I'd like to say that this is awesome, and actually something I sometimes wish for. Keep up great work.
Unfortunately, I am too busy right now to be a tester. I just wanted to give you kudos on your project.
I'll DL this when I get home.
I've always wanted to see an update to SP!
Woohoo! Testing now...
Okay, here's my initial findings: - Govt jamming flags still aren't being interpreted (it was just outfit jammers that would be a problem, right?). - "Remove prepaid outfit item" should add Dxxx to OnFail as well as OnAbort. - I seem to be getting random values for GuidedTurn like 29292 or 30309 (should be 20 default then +20 and +40 for the two flags). - Mission flag 0x1000 "Critical Mission" should be interpreted as a higher DisplayWeight, like 10 maybe (or was this to be added in a later version?). - weap resources are somewhat larger than they should be :huh: - Derakon is right - something's wrong with the descs. When I open them in NovaTools they're all blank even though their size seems okay. The intro text (20000) came out okay except that it indicates a weird moviefile and flags. - Always get NilObjectExceptions if I cancel when choosing a destination.
And a couple of suggestions: - Make "Zero armor regen" checked by default. - For shield regen outfits, multiplying by -4 gives very good results. These are the values I used in the EVO port but they work very nicely for EV too. - For any documentation or whatever you might include, mention something about putting ships, outfs, govts, junks, (anything else?) together in the same file with STR#s and STR s so that it can pick them up during the conversion. - For the sake of compatibility with Rezilla Custom, set unused outf modtypes to -1 instead of 0. - And what happened to the new EV Basics I sent you?
Aside from all that, this a seriously cool app folks and does way more stuff than the old version ever did. I highly recommend it
This post has been edited by Guy : 24 March 2006 - 12:23 AM
If the debug log that is created when it finishes processing a plug has no errors, then will the plug work properly? i dont have time to test the evn version of the plug i converted now.
@edwards, on Mar 23 2006, 01:24 AM, said in [ANN] SpacePort 1.2 Enters Beta:
Yep. I'll fix that.
Quote
Good idea; I'll put that in the readme when I release the full version.
@zacha-pedro, on Mar 23 2006, 07:01 AM, said in [ANN] SpacePort 1.2 Enters Beta:
I have an offer for you: I test this version of SpacePort (and, incidentally, resume working on Rezilla, but that was already on schedule, and beta test a certain ambrosia game as always), and you test the second custom version of Rezilla and you get back to work on plug-in archiver. How about that?
Deal.
@guy, on Mar 23 2006, 04:56 PM, said in [ANN] SpacePort 1.2 Enters Beta:
- Govt jamming flags still aren't being interpreted (it was just outfit jammers that would be a problem, right?).
Dammit. I know for a fact I added a check that would output the flags to the output log; does that work?
- "Remove prepaid outfit item" should add Dxxx to OnFail as well as OnAbort.
Agh. I could've sworn that was one of the first things I did...<_<
- I seem to be getting random values for GuidedTurn like 29292 or 30309 (should be 20 default then +20 and +40 for the two flags).
?!?
Probably an offset error or something silly like that. I'll look into it.
- Mission flag 0x1000 "Critical Mission" should be interpreted as a higher DisplayWeight, like 10 maybe (or was this to be added in a later version?).
I don't think I ever actually added that. I'll make sure it gets done.
- weap resources are somewhat larger than they should be :huh:
?
Odd. I guess I'll look into it...
- Always get NilObjectExceptions if I cancel when choosing a destination.
Ooh, that's bad. Why was it asking for a destination? Because it failed to automatically make one, or because you had debug mode on?
- Make "Zero armor regen" checked by default. - For shield regen outfits, multiplying by -4 gives very good results. These are the values I used in the EVO port but they work very nicely for EV too. - For any documentation or whatever you might include, mention something about putting ships, outfs, govts, junks, (anything else?) together in the same file with STR#s and STR s so that it can pick them up during the conversion. - For the sake of compatibility with Rezilla Custom, set unused outf modtypes to -1 instead of 0. - And what happened to the new EV Basics I sent you?
Alright, I'll be sure to do that. As for the EV Basics, it's in the project folder, but I forgot to replace the one in the application folder. Beta 2 should have it.
@orcaloverbri9, on Mar 23 2006, 06:35 PM, said in [ANN] SpacePort 1.2 Enters Beta:
Ah, it does indeed (with all this difficulty of getting logs to work I didn't immediately notice that).
It asks if I drag-n-drop.
Did you get this one? I think I added it while you were replying.
@guy, on Mar 23 2006, 10:56 AM, said in [ANN] SpacePort 1.2 Enters Beta:
- Derakon is right - something's wrong with the descs. When I open them in NovaTools they're all blank even though their size seems okay. The intro text (20000) came out okay except that it indicates a weird moviefile and flags.
All right orca, I took an EVO plug-in in which I participated, Dark Station, and that I wanted for a long time to port to the EVO port but never got around to actually doing it. So I dropped it to SpacePort, opened the output with Rezilla Custom, the original with ResEdit (though I switched to Rezilla Custom for the original as well, since it contains the EVO templates that override for this file which is quite practical...), both Bibles, and compared every single resource. Here is what I found (intersects a bit with Guy's remarks):
One tiny, funny thing: the log gives me the conversion date in French (because that's my default language in OSX). You'd think I'd like it, but in fact having to switch from my English parser to my French parser, and back, more than offsets the benefit of parsing native language for so short
dëscs: 36 bytes are indeed added, but you seem to be having problems with copying or something like that: it's all NULs (00 in hex) instead of the text in the converted file...
düde: saw that you were adding "generic govt hail", and then realised it didn't exist in the first place in EVO (by the way, having Rezilla with Nova templates in one side, and ResEdit with EVO templates on the other, and two versions of the Bible at the same at the bottom of the respective sides will make your head spin); do you add it systematically (even if there are other InfoTypes), and does EVO show generic govt messages if it has something else to show set in the düde? Can't check right now.
mďsn: incredible the things that are well converted. The plug I tried with isn't particularly mission-intensive, but even in the single mission there are pitfalls (say, with hypering in of special ships) that are avoided.
oütf: usually putting 0 for fields that didn't exist in Override works well. But it's not the case with ModTypes, you'd better put -1 for unused ModTypes (this is the case in all Nova Data outfits, as well as outfits from the EV port and Override port); I don't know if Nova likes the 0 value or not, but it's obviously not the thing to do when no one's been doing it before (and as an aside, it means Rezilla can't open it with my templates, since it can't find the keyed section for 0 :-). Also, the lowercase name, for player info, is not filled using the STR at ID 3200-3327, but the short name for outfitting (using STR ID 3000+) and the lowercase plural (from STR ID 3400+) are... Another thing: oddly enough an outfit from the plug I was trying to convert had a ModType2 of weapon (which is forbidden), but with a ModVal2 of -1; this doesn't seem to have given any problem to EVO. SpacePort may not be meant as a plug checker and censor, but you might wish to filter out these into -1 ModTypes and output a mention in the log.
PICT: perhaps you shouldn't even touch PICTs. As a matter of fact, they are. Also, you might wish to advise in the log to convert PICTs to rles, especially for ships (but SpacePort shouldn't do it itself, of course).
shďp: I've heard (never tried myself, but it is said to create the problems with the cloaking device in the EVO port) that TechLevels of 32767 do not work well in Nova. I fear you'll have to remap that to something else (even if that something else might in fact be used, so output a mention in the log), such as 9999 (same for oütf). Perhaps indeed "no armor recharge" should be made the default. The Explode2 field should get a 10xx value if, and only if, DeathDelay is 60 or more; as we're into ship explosion, I wonder why there is no "ship explosion" bööm (one with the ship explosion sound) in the EVC or EVO ports, but you can't do anything about it, so you should put 0 for Explode1, and 2 or 1002 (depending on DeathDelay) for Eplode2. Also, it happens that I am converting a plug that was made at the time of EVO <1.0.2. As you all know, Matt added some features and resource fields in the Override 1.0.1->1.0.2 transition. And in the converted Nova version, I have garbage in these fields new to 1.0.2, as if you tried to read past the end of the resource and put whatever was there. My advice: get the length of the resource and do not try read past its end, and put sensible values by default (just as you would with EVC). Unfortunately, it is quite hard to come by pre-1.0.2 documentation since Ambrosia doesn't carry around the previous versions. If that can help, Dark Station contains the EVO 1.0.0/1 templates, for you to see what wasn't there back then (for instance, shďp ended with the flags field). By the way, which twisted formula do you use for the shďp's Strength field? Speaking of formulas, ShieldRech should be rounded to nearest.
spďn(&shďp)->shän: where are you getting your non-turret Y coordinates values from?
spöb: why put a daily tribute? You might as well leave -1, which will give the default (which was the case since EVC, if my memory serves me well) of TechLevel*1000
s˙st: you give AlwaysPerses only 25% probability?
wëap: why the heck do converted wëaps have 192 bytes of data? That's 134 normally, you know. I'm also getting a mysterious 50 vulnerability to type 1 jamming when there was none originally - nevermind, it was with type-2 guidance weapons (originally EV missiles, smart homing), which are supposed to be vulnerable to jamming in EVC. We also have the problem of flares; this is probably the single biggest missing feature in Nova, all others (say, in-space ship appearance depending on mission bits controlled at the düde level, allowing finer control of progressive appearance) are neglectable compared to it; I understand you probably don't want to solve it automatically, but then put a clear message in the log that you converted a flare into an useless freefall bomb! Also, you might wish to set weapons that are decoyed by flares to be suceptible to point defense and have 1 Durability (while weapons that are not decoyed by flares originally should be set not to be targeted by point defense and have 0 Durability), that way if there are no PD weapons (as there should be in a stock converted scenario) there is no difference, and it helps the job of the converting guy if he decides to go the most obvious way for converting his flares: he will just have to cater for the decoy flares themselves; at any rate, also output messages for every weapon that has this "decoyed by flares" flag so that the guy can know where he needs to change things. As with ShieldRech, MassDmg and EnergyDmg should be rounded to nearest. Perhaps guided weapons with guidance 2 (don't ask me how there are 2-type guidance in an EVO plug, I wonder how the hell it worked in the first place) should exit from the ship's guided weapons exit points. I have a type-1 guidance weapon, with +=60°/sec turn speed, shouldn't it get 90, that is the 30 value in the GuidedTurn field once converted? You seem to be putting 20 every time. Weapons with 2 ExplodType should be converted to 1002. Also, there is the whole issue of converting beams (that seems to be correctly handled, from the only example I have), but Guy knows a whole lot more on the subject than I do.
That's all... for now.
Well I can answer some of these.
@zacha-pedro, on Mar 24 2006, 12:25 PM, said in [ANN] SpacePort 1.2 Enters Beta:
Generic govt is enabled only if there are no other info types.
Another thing: oddly enough an outfit from the plug I was trying to convert had a ModType2 of weapon (which is forbidden), but with a ModVal2 of -1; this doesn't seem to have given any problem to EVO. SpacePort may not be meant as a plug checker and censor, but you might wish to filter out these into -1 ModTypes and output a mention in the log.
Personally, I really wouldn't bother. If EVO doesn't mind it I don't think EVN would either.
Er, is that second sentence supposed to mean something? I don't think any of the PICTs are actually modified, as such, however if it finds explosions picts in the same file as their spins then it will do something very cool and actually reverse the order of the frames for you.
shďp: I've heard (never tried myself, but it is said to create the problems with the cloaking device in the EVO port) that TechLevels of 32767 do not work well in Nova. I fear you'll have to remap that to something else (even if that something else might in fact be used, so output a mention in the log), such as 9999 (same for oütf).
I pretty sure ships don't matter but he did say something about setting outfs to 32766. However it doesn't appear that this has actually happened yet.
The Explode2 field should get a 10xx value if, and only if, DeathDelay is 60 or more; as we're into ship explosion, I wonder why there is no "ship explosion" bööm (one with the ship explosion sound) in the EVC or EVO ports, but you can't do anything about it, so you should put 0 for Explode1, and 2 or 1002 (depending on DeathDelay) for Eplode2.
Okay, this is a good point actually. In the current EV Basics there are only 4 booms but in the new one there are 5 booms. All ships should have 3 for Explode1 and 4 or 1004 (depending on DeathDelay) for Explode2. Yes, there's a compatibility issue here with the official EVC/O ports but it's not the only one. Compatibility is assured for my EVO port - I guess I should do an EVC one too (shouldn't take long once all these bugs are worked out ;)). Then put links to them in the documentation.
By the way, which twisted formula do you use for the shďp's Strength field?
Crew*5. This is correct, is it not?
Ship nose (y-size/2). This is how EVO works.
I'm also getting a mysterious 50 vulnerability to type 1 jamming when there was none originally - nevermind, it was with type-2 guidance weapons (originally EV missiles, smart homing), which are supposed to be vulnerable to jamming in EVC.
Hm, I don't think that should be happening anyway - this is an EVO plug, right? The weaps in the EVO data convert okay, with jamming according to their flags even though most of them are type-2.
We also have the problem of flares; this is probably the single biggest missing feature in Nova, all others (say, in-space ship appearance depending on mission bits controlled at the düde level, allowing finer control of progressive appearance) are neglectable compared to it; I understand you probably don't want to solve it automatically, but then put a clear message in the log that you converted a flare into an useless freefall bomb! Also, you might wish to set weapons that are decoyed by flares to be suceptible to point defense and have 1 Durability (while weapons that are not decoyed by flares originally should be set not to be targeted by point defense and have 0 Durability), that way if there are no PD weapons (as there should be in a stock converted scenario) there is no difference, and it helps the job of the converting guy if he decides to go the most obvious way for converting his flares: he will just have to cater for the decoy flares themselves; at any rate, also output messages for every weapon that has this "decoyed by flares" flag so that the guy can know where he needs to change things.
The log does indeed make a note of any flares.
I have a type-1 guidance weapon, with +=60°/sec turn speed, shouldn't it get 90, that is the 30 value in the GuidedTurn field once converted? You seem to be putting 20 every time.
Actually no, one of the bibles is wrong on this point. Correct values are multiples of 20 rather than 30 (as I mentioned in my post above). Funny that you were getting 20 though - I was getting random values.
Oh dear, have I gone and submitted the EVO port with weaps that should be explode=1002 but aren't? Nuts.
(EDIT): Hm, 10 quote limit.
This post has been edited by Guy : 24 March 2006 - 11:50 PM
@guy, on Mar 24 2006, 07:43 PM, said in [ANN] SpacePort 1.2 Enters Beta:
EVN does not care if any ModTypes other than 1 are weapons or ammunition. It will simply ignore them.
I rechecked what I found out in light of Guy's comments:
@guy, on Mar 25 2006, 04:43 AM, said in [ANN] SpacePort 1.2 Enters Beta:
For ModVal2=1, if Nova ignores them just as Override did, then I have no problem with them (other than difficulty opening them with Rezilla Custom
Well, sorry, but all PICTs have had their data completely changed, almost all of them (especially B&W ones, i.e. masks) increasing in size. I don't think that Nova (except 1.0.9, but that's expected to be fixed) is more picky on PICTs than EVO and that the PICTs needs to be fixed, do they?
In this case, please tell out loud in the documentation that the converted plugs are expected to be run with your EVC/O port, and since the "official" ports are still quite mainstream, perhaps have an option to behave compatibly with the official ports even if this stupid ship explosion behavior can be considered a bug.
Oh yeah, did not make the connection with Crew; Crew*5 is correct (I think, I did not fully study the matter, especially of the internal multiplier) for the purposes of the combat rating, but Strength is also used by the AI to decide whether to attack or not, and it would be silly to have a Crescent Warship flee before a Turncoat. Of course, in EVC/O no ship ever cared that it was trying to attack a ship that was a hundred times more powerful, so to replicate this behavior (which is the most reasonable thing to do) I hope you're setting all gövts to be infinitely suicidal, aren't you (or as much as possible, that is 32767, though it might be possible that by putting -1 the engine decides that the ships of the govt will be suicidal, though I wouldn't count on it)? I don't know since the plug I'm converting doesn't have any gövt.
Yeah, I thought this had to be more or less coming from the ship sprite, though I don't understand your (y-size)/2
Well, I do get 50 vulnerability to type-1 jamming from Guidance-2 weapons with all jamming flags set to 0. Perhaps the EV code gets mistakenly invoked since the wëaps have EVO 1.0.1 size (and not EVO 1.0.2 size). On the matter, the plug I'm converting is a little wierd since most resources are of EVO 1.0.1 size, and all the included templates are, while oütfs and s˙sts have EVO 1.0.2 size, and incidentally thus do not match the included templates.
As for the log, I was reading a wrong one, that was coming from an age-old conversion with SpacePort 1.1 (I did not even react on the old date, proof that my French parser wasn't completely up when I tried to interpret it...), SpacePort 1.2.0b1 did not overwrite this old log as it should have done. The actual log I obtained by rerunning it after removing the old one indeed mentioned the flare.
Well, if one of the Bibles is wrong, what is right then? Who can we trust? Is the truth out there? No, seriously, what data do you have?
@zacha-pedro, on Mar 25 2006, 10:32 AM, said in [ANN] SpacePort 1.2 Enters Beta:
I should note that my port is made by SpacePort - SpacePort has not made to conform to my port. Yeah, in hindsight maybe SpacePort should have been changed to conform to the existing port and then my port based off that but unfortunately I've already released the port. Still, I don't see a lot of point in making plugs for a buggy port. Links to compatible ports in the docs should be sufficient. (specifically, I'm talking about govt classes - one of them is 0-based and the other is 1-based, I forget which is which)
Ah yes, you're right there. Currently it gets set to 500 for all. I guess this is to allow converted plugs to take advantage of some of Nova's new feature but if we're going to be strict about it should indeed be set to 32767.
The top of the sprite is located at a distance of half the sprite's height from the center of the sprite. If the sprite is 100 pixels high, giving the exit points a y-value of 50 will make them fire from the nose.
Ah yes, I see that now - only with pre-1.0.2 plugs. You're probably right about the EV code getting executed instead - the weapon I was testing it on had 50% vuln. to type-4 but the conversion gave it 50% type-1. But unless pre-1.0.2 support actually gets implemented, we can't really complain about that.
Well the Nova bible doesn't actually say it's in degrees, so I guess neither of them are wrong. We'll just say that a value of 20 in GuidedTurn is equivalent to 30°/s. This comes from my own measurements.
Keep up the awesome work, guys. More power to your collective elbows.
Dave @ ATMOS
There's a good chance I don't understand what I'm talking about, but....
If Spaceport is having problems with EVO 1.0.0 and 1.0.1 plugs and it's difficult to build support for those formats into the program, would it be easier to make an external utility app -- perhaps based on Rezilla -- that automatically chugs through an EVO plug, opening every resource and re-saving it in accordance with the 1.0.2 template?
It strikes me that people are going to have trouble figuring out whether plugs they want to use were built with the 1.0.2 templates, especially since (1) the add-ons collection submission dates for all pre-8/12/04 plugs have been lost and (2) as ZP found, there are apparently "mixed" plugs out there.
Thanks Dave.
ZP: I think the PICTs are modified because rather than just re-storing the data on a byte-by-byte basis, it creates an internal image and then writes that image to the Nova file. I could change this easily, but it's probably best to keep it for consistency with modified explosion sprites.
As for the date, I'll fix it so it outputs in English.
Dr. T: I actually considered something like this; I think if I were to implement pre-1.0.2 support, I would probably do it by converting the resources to the 1.0.2 format.
SpacePort uses the length of the resource to determine which game it's from, so any manner of unpredictable things can occur if you use pre-1.0.2 plug-ins, and treating it as an EV resource is absolutely one of these.
At some point I'll work on these issues. I think I fixed the NilObjectException when you cancel bug; I definitely had a look and found the culprit. I'd work on them now, but I'm posting from church.
@guy, on Mar 26 2006, 05:29 AM, said in [ANN] SpacePort 1.2 Enters Beta:
Yep. If people actually want to get advantage of Nova's "reasonable AI" feature, then they might as well do it by hand since giving actual relative strengths to ships cannot be done automatically anyway.
Oh yeah, I get it now. Guy, never ever put hyphens in expressions. Most people will read it as minus, and I originally read it a "Y minus SIZE divided by 2". Say "Y coordinate of", "size.y" (in C/java fashion), Yof(size), whatever, etc, but never with an hyphen (unless maybe if it's followed by >, making an -> arrow, though the leftward <- arrow isn't a good idea since it might be parsed as "less than minus something").
This is the reason why I get 20 everytime as well: it's the EVC code being executed.
@orcaloverbri9, on Mar 26 2006, 06:45 PM, said in [ANN] SpacePort 1.2 Enters Beta:
Amen.
For the PICTs, if that works that's no problem for me. Heck, if I want I can always copy back the original ones with Rezilla ;).
As for EVC/EVO<1.0.2/EVO 1.0.2 support, I think the best course of action is the following: - decide whether the EVC or EVO code will be used on a file-by-file basis, using the file type and creator (be careful with TCs that can get the file type of the data files, not to mention the data files of the base scenario themselves, in fact only using the creator code would be best) - then once it's decided, use the resource size only in order not to read past the end of the resource, which obviously reads garbage when it doesn't crash with a segmentation fault (never seen it because you're not reading past the end of the resource by any important amount, but still can very well happen, trust me). If ever when reading it is realised that the resource is shorter than what was expected for an EVO plug, then assume sensible data in the missing part (say -1 ModType, or 0 for most everything else) in the body of code that reads the resource, and feed that sensible data to the algorithms as if it was actually there, instead of reading past the end of the resource. That's probably what EVO 1.0.2 does when confronted with an EVO 1.0.0/1 plug.
This post has been edited by Zacha Pedro : 26 March 2006 - 04:47 PM
@zacha-pedro, on Mar 26 2006, 10:43 AM, said in [ANN] SpacePort 1.2 Enters Beta:
Oh right, sorry about that, guess I didn't read what I had typed. Lets just call it ySize.
That's probably what EVO 1.0.2 does when confronted with an EVO 1.0.0/1 plug.
Actually, I think it distinctly separates 1.0.2 from pre-1.0.2 by simply checking if the resource is shorter than a 1.0.2 resource. I remember removing all the "unused" fields at the end of some resources only to find that all 1.0.2 specific fields/flags were ignored.