Page 3 of 12
Posted: Fri Feb 08, 2008 10:19 pm
by TGHC
Eric Walch wrote:
Please download it again. I always zip my files with StuffIt. This is the most popular zipper for mac users I think. It ships with the Mac installation disk. But Mac OSX nowadays has itself an menu option to archive files. This also makes a zipfile. By using the same folder as before to zip, it created a 50 kb greater file. So they are different. Please also download this file (I called it version 1.3.2a) and see if this behaves better. When so, I'll switch to this zipper in future, if no difference I stay with the old method that makes smaller files. (The size difference it probably only the addition of mac related stuff).
I left both files for download this time.:
UPS-Courier
Mac and windows use a different file structure and it always has been difficult to make an universal file. When fully windows compatible it will miss certain aspects on the mac. So there is extra information for the mac users. Not all window un-zippers seem to handle this extra information the same way.
1.3.2 still bounces because of the different file size, but 1.3.2a downloaded ok.
I'm surprised that this hasn't been an issue before.
Thanks for the fix, I'm off to give DHL a run for their money now.
Posted: Sun Feb 10, 2008 1:09 am
by Kaks
Weird, got a PC & didn't have any download problems.
Some mac zip files, including 1.3.2, do contain a file (icon)that's 0 bytes long. That's generally really badly handled by pc unzippers. I use 7-zip, and while it complains about a 0 length file, it extracts everything else inside 1.3.2 & 1.3.2a without a problem.
But as far as download goes, with firefox it gets everything without a single problem. Were you using ie when the download stopped early?
Posted: Sun Feb 10, 2008 10:04 am
by TGHC
I'm using IE7.
It was completing the download, but AG antivirus was bouncing it because of "corrupted archive - wrong original size" it was about 50k less than expected.
Posted: Sun Feb 10, 2008 10:35 am
by davcefai
You might be redownloading from your cache and therefore getting the same corrupted file every time.
The only way out is to clear the cache before downloading again, or use a different browser (which will have a different cache).
Good time to try Firefox
Posted: Sun Feb 10, 2008 10:37 am
by Kaks
Very weird: I've got a virtual machine with XP, ie7 and AVG free editon & the download goes smoothly with that setup. No warnings, etc..
My 'real' machine runs on XP, has ie6 & AVG free, and no problems there either.
Maybe it's some specific settings in AG, perhaps there's an advanced option that says something like: 'quarantine downloads when file length is different than expected'.
You could check if that's the case by temporarily disabling AG, tying to download the original 1.3.2 & then re-enabling AG.
Of course, it's a bit of a moot point now, since you've got 1.3.2a, but could be useful to know for future version of this and other OXPs!
Cheers,
Kaks
Posted: Sun Feb 10, 2008 8:10 pm
by Cmdr James
There is a mistake in ups_parcel.js line 210 economy spelled ecomomy
Code: Select all
if(missionVariables.ups_parcel == "NO" && Math.random() < 0.1 && system.government > 3 && system.ecomomy > 3 && missionVariables.ups_tcount > 1)[/cpde]
should be [code] if(missionVariables.ups_parcel == "NO" && Math.random() < 0.1 && system.government > 3 && system.economy > 3 && missionVariables.ups_tcount > 1)
Posted: Mon Feb 11, 2008 4:50 pm
by Eric Walch
Cmdr James wrote:There is a mistake in ups_parcel.js line 210 economy spelled ecomomy
Thanks for the correction. I play-tested all missions, but this is part of an off-mission encounter. It should be rare, but with this bug it is just not happening. It will not effect gameplay and will be fixed in next JS-UPS release. Next version also will have timers to reactivate postponed offers as the JS version now will postpone some offers to a next docking when there are multiple offers.
I also added some conflict warnings with other OXP's. In the legacy version I also detected offering conflicts but just did reset things. Now I will issue a warning so bugs in other OXP's will be noticed sooner.
But next thing will be translating the fifth and last mission series into JS. After that it becomes time to add new features that were impossible under legacy scripting. I already used the possibility to explicit set a NPC-ship temperature in the current version in one of the solar missions.
Posted: Sat Feb 16, 2008 8:31 pm
by Eric Walch
I just uploaded version 1.3.3 of UPS-courier.OXP. The last, and biggest mission series in now translated to JS and tested. (20% translating, 30% testing and 50% bugsquashing). But all mission run fine now.
All mission-offers start a timer now when the page is busy for later access of this page. A "missionScreenEnded" event alone is not enough, but an additional "choicesAreCleared" to stay in control without timers would help. The tickle event is unused except for one conditionchecking that will also be removed when the 1.71 release functions come available.
I think it is just as friendly towards other OXP's than the original version. It will postpone offering when an other missionscreen is displayed or when choices are still open. Some OXP's leave the choices active after reading them out. This makes it impossible for a oxp like ups to do an safe offering. For this reason UPS clears the choices on launch. Version 1.0 already did this, but now it is stored and on the next docking I give a warning. Maybe this helps other writers to clear this thing in time. I also issue a warning when launching from within an offer and when I detect that an other OXP has overwritten my choices. No player should see these screens normally.
The game itself acts exactly like the old legacy version, only the offering screens will follow each other without pause when there are more to display. Started to attach scripts to ships. I see here a lot of new possibilities for future versions that previous were not possible.
Although it runs on 1.65, it will only do the new things in 1.70. Users of 1.69 or older should stay with the 1.2.x version. Both versions are downloadable from:
UPS-Courier
For 1.70 testers a must to test the JS system further.
Posted: Sat Feb 16, 2008 8:45 pm
by JensAyton
Eric Walch wrote:All mission-offers start a timer now when the page is busy for later access of this page. A "missionScreenEnded" event alone is not enough, but an additional "choicesAreCleared" to stay in control without timers would help.
I still need
a clarification on that.
Posted: Sat Feb 16, 2008 9:27 pm
by Hoopy
i get a lot of ups warnings telling me that galactic navy (i think) hasn't cleared the back to business choice.
Posted: Sat Feb 16, 2008 10:10 pm
by Eric Walch
Ahruman wrote:Eric Walch wrote:All mission-offers start a timer now when the page is busy for later access of this page. A "missionScreenEnded" event alone is not enough, but an additional "choicesAreCleared" to stay in control without timers would help.
I still need
a clarification on that.
I mean resetMissionChoice() (not clearMissionScreen()?)
When a choice is present it is possible my OXP reacted sooner on the
missionScreenEnded event than the owner of the screen. That means the other OXP will read out and clear the choices directly after me. But there is now no event that brings me back in control. (currently one now needs a timer or tickle). But an event on
resetMissionChoice() could me also bring back in business. Only a third OXP could get in between. But the only reason for him will be to set up his own page. So eventually he will generate a
missionScreenEnded for me.
Problems stay only present with bad programming of OXP's that don't clear the thing after use. There is nothing to do at that other than I do now by issuing a warning message when it happens so the culprit OXP can be improved.
Posted: Sat Feb 16, 2008 10:27 pm
by JensAyton
OK, implemented as missionChoiceWasReset(oldMissionChoice).
Posted: Sat Feb 16, 2008 10:42 pm
by Eric Walch
Hoopy wrote:i get a lot of ups warnings telling me that galactic navy (i think) hasn't cleared the back to business choice.
I checked it and I can confirm it is Galactic navy. Matt does the same as a lot of other OXP writers. He always resets the
mission choice but not when he is finished himself. The other choices, he has to clear to proceed further himself but after the last he does not need it anymore and just leaves it that way. But it is certainly not the only OXP that does it. On testing UPS I had a few more occasions (2) were I didn't get a offer were I would have expected one. It was always after playing a mission OXP and it was always the final choice that was not cleared.
So already on version 1.0 of UPS I clear the choices on launch as at that time I can know for the first time it is really forgotten to clear. But to do my offer, I have to wait until the player docks again at a station with the right conditions.
A better thing for checking this was a special diagnostic OXP, but I leave it in for the time being.
Ahruman wrote:OK, implemented as missionChoiceWasReset(oldMissionChoice).
Thanks.
Posted: Sat Feb 16, 2008 11:19 pm
by matt634
I will get to fixing this right away. Do I just need to resetmissionchoice when launching from the SecCom?
Posted: Sun Feb 17, 2008 4:24 pm
by Eric Walch
matt634 wrote:I will get to fixing this right away. Do I just need to resetmissionchoice when launching from the SecCom?
No, than there is still a possibility that UPS detects it sooner and still sets up this warning. UPS will clear the thing on launch anyhow now, so players don't have real problems with. But without UPS that clears it, no other OXP can now offer a mission until the next start of Oolite. Than Oolite starts with an empty variable. I never tested it loading a new player also resets this.
Reset the variable where appropriate like all other times you do and that currently needs to do only in one place:
Code: Select all
{
conditions = (
"missionChoice_string equal back_to_business",
"mission_seccom_station equal SECCOM_VISIT"
);
do = ("set: mission_seccom_station DOING_BUSINESS", setGuiToStatusScreen);
},
should become:
Code: Select all
{
conditions = (
"missionChoice_string equal back_to_business",
"mission_seccom_station equal SECCOM_VISIT"
);
do = ("set: mission_seccom_station DOING_BUSINESS", setGuiToStatusScreen, resetMissionChoice);
},