John just helped me to pin down the crash issue Scriptdaemon was experiencing in certain obscure situations of the INI file in OpenTTD Portable on Windows 7. Replacing the new, kernel32::GetPrivateProfileSection ForEachINIPair.nsh with the old, FileRead etc. ForEachINIPair.nsh stopped it from crashing. So I've gone back to the old ForEachINIPair macro plus a couple of extras which I should have had earlier to make it behave as expected, whitespace trimming and quotation mark parsing; this means that a line like `foo = " x"` evaluated to `foo ` and ` " x"` with the old ForEachINIPair macro, but with the new GetPrivateProfileSection one and my update to the old one (i.e. the current one in the repository and what will be in the next release), it'll be `foo` and ` x` as expected.
This means that launcher.ini can no longer be encoded in UTF-16LE, but I ahve yet to see a case where that will be necessary, anyway. At some point in the future I'll get round to making it capable of dealing with either (I'll refer back to Gringoloco's patch) but for the moment it's ASCII-only.
Now I'm happy to release a Release Candidate (but I'll wait for Simeon's . registry issue if he's quick).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
1. OpenTTD Portable no longer crashes.
2. After launch, the language remains what was previously selected in-game if I launch from my desktop.
3. DefaultData seems to be copied over correctly now.
Bad:
1. Environment variables aren't evaluated if inside quotes (launching from PA.c menu after deleting Data folder).
As for the not parsing of %PAL:LanguageCustom%, what that actually indicates that the environment variable PAL:LanguageCustom is not defined. That will be a side-effect of the new language-switching code; I'll take a look at it now (or after tea). If I haven't resolved it by the time you see this message, it might help if you'd post your [LanguageFile] section.
At some point I should get you to write a few worked examples for the manual. Seems to me you should be good at that.
Edit: ah yes, I see the issue, PAL:LanguageCustom will only be set if PAP is missing, will commit fix after tea.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Scriptdaemon: the important thing in your report that language switching isn't working properly is that it's saying that the environment variable PortableApps.comLocaleName is empty (set, but empty). The problem is, I can't work out why that would be. Can you see anything wrong with this code?
ReadEnvStr $0 PortableApps.comLocaleName
${If} $0 == ""
ReadEnvStr $0 PortableApps.comLocaleWinName
StrCpy $0 $0 "" 5 ; Chop off the LANG_
${SetEnvironmentVariable} PortableApps.comLocaleName $0
${EndIf}
That's all the code that there is for PortableApps.comLocaleName. I presume PortableApps.comLocaleWinName is LANG_GREEK? (Refer to Process Explorer to inspect the environment, could be useful if you could tell me the values of all of them inside OpenTTD.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
It seems to switch a couple vars around at some point before that, most importantly PortableApps.comLocaleWinName to PortableApps.comLocaleID instead, so when that code removes the first 5 characters from it, it removes everything.
As far as the screenshot: the one on the left shows the vars before that debug message, and the one on the right shows as that debug message appears.
I think I worked out why it was doing it; I was pushing $0, but then using it as a variable and so messing up the macro variables when $0 was one of the parameters. I've fixed that, I think that should fix your problems but I don't have time to test it thoroughly just now (if you haven't by tomorrow I should be able to test it then).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
The following will fix the symbol, GeneratorWizard.nsi, line 61:
!ifdef NSIS_UNICODE
BrandingText "PortableApps.com - Your Digital Life, Anywhere®" ;UTF-8
!else
BrandingText "PortableApps.com - Your Digital Life, Anywhere®" ;ANSI
!endif
Another option is to convert the script to UTF-16LE, but this will break ansi NSIS compatibility!
The PA.c InstallerU & AppCompactor scripts are converted to UTF-16LE so it deals with this symbol !
Any of the launchers do not include the BrandingText, although you have to watch the EULA's, they could get messed up, just convert them to UTF-16LE (e.g. with Notepad++).
I'm experiencing rather strange behavior with the current tip. I'm trying to package Bos Wars Portable and these are some of the things I've crossed:
- DirectoriesMove doesn't seem to be working as it should (well, at all).
- The launcher doesn't exit when Bos Wars is closed. (Is it possible that it is hanging?)
- I've noticed the previous point when trying to regenerate the launcher, it seems that it doesn't regenerate the launcher though gives no warning that the launcher actually cannot be generated since the file is still "in use," so as far as the developer knows the launcher was successfully generated when it was not.
- I've not been able to pinpoint this one yet, but sometimes the launcher won't launch Bos Wars while with other generations of the launcher (using the same revision of the generator) it does.
Edit: Wooow. Practically nothing works in PAL from the tip. Trying with Marble Portable:
*Nothing* gets put into the Data directory (except MarblePortableSettings.ini) and everything is left behind.
Also, launching from the final generator window it doesn't launch, but it does when running MarblePortable.exe directly. The launcher for Marble Portable also doesn't exit as it should.
Edit 2: I actually *thought* about what I was reporting, and it's no wonder nothing works since the launcher doesn't exit as it should (d'oh). That seems to be the main problem, along with the other things I have not crossed out (and the fact that the previous language switching bug wasn't fixed).
Edit 3: Something else has also occurred to me. Since Unicode NSIS Portable seems to have the same crash OpenTTD Portable did, would that affect PAL's ability to generate a launcher?
If I understand you right, 'PortableApps.comLauncherGenerator.exe' doesn't run Unicode NSIS launcher at all, but immediately runs 'makensis'. So that couldn't be a problem.
GeneratorWizard.nsi, line 110:
BTW: I will update Unicode NSIS launcher soon, but have to test today if PAL is in a state to actually do an update. (Sorry have been away for a week, but am all available again for the comming month)
Don't update yet until I (or Chris) figure out what's going on, and possibly where the bugs started appearing. (Although, I downgraded to Beta 4 and I still seem to have the same problem... so frankly, at the moment, I have idea what's going on.)
Edit: Actually, go ahead and update it just to test it at least. The more testing the better.
Edit 2: Correction, doing a clean install of Beta 4 fixes everything (except the bugs that were reported for Beta 4, of course).
This also seems to have somehow fixed the language variable bug.
Chris, you can go ahead and revert the last change before applying these fixes.
Also, I have a question. OpenTTD Portable doesn't use the registry, yet the debugger tells me "Registry sections enabled." Why?
Edit: Looking back at the link I gave (which Gringoloco showed me), it puts quotes around much more than you do. Is that necessary? (I don't know how quotes work in NSIS.)
Edit 2: Now LanguageFile doesn't seem to be working. Sigh.
What Gringoloco reports is quite clearly an NSIS bug, though whether in their documentation or their code implementation I can't really say. They say that $\t is a variable, not a definition (and the style fits too, $\t rather than ${\t}), and so by rights that means it doesn't need quotes. However this makes it clear it was turning it into StrCmp $R2 0 +3 - and you can follow the code through to see then that it will never get out of its checking.
As for quotes, they're not necessary unless you've got whitespace in a string (or quotes at the start/end of a literal). I tend to avoid quotes where I can in NSIS code, though whether that is wise or not I begin to wonder. It's normally neater, and when a parameter is being passed as an output variable putting quotes in just confuses matters.
I did see that leading/trailing whitespace removal function, mine was very loosely based on it (i.e. I looked to see what it was doing and saw that it was doing just what I was planning on doing). I didn't use it verbatim though because it's messy. I mean really, using functions rather than CallArtificialFunction...
I've committed that fix, anyway. As for LanguageFile, I don't think I've applied any change to that file which could affect it in the least. I'll check a bit later though. How's your environment looking when it's not working? And the debug messages?
A test suite seems to be to be becoming more and more important.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I think I was confused when I last tested it, going through it completely when set to Greek it actually remains Greek. However, which what may have had me confused before, is that all the language variables are English (launching from desktop, not the menu) and there are no debug messages whatsoever regarding LanguageFile as far as I can see.
Edit: You skipped my question about the "Registry sections enabled" debug message.
I noticed and fixed the "Registry sections enabled" message last Wednesday.
Concerning the LanguageFile stuff, when you run OpenTTDPortable.exe without the PortableApps.com language variables being around (in which case you should get "PortableApps.com Platform language variables are missing."), you should be getting a message "Reading the language from $1, section `$2`, key `$3`, with ReadINIStr." (naturally, values inserted) and then "Setting PAL:LanguageCustom to $8 based on the [LanguageFile] section." (ditto). What does the debug output (see OpenTTDPortable\Data\debug.log) look like?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
2. None of that happens (debug.log at end of post).
3. I have CleanTemp=false. Does it really need to set %TMP% and %TEMP% anyway?
4. I just noticed something interesting. When running from the generator ("test launcher" option) the first debug message I get is "Setting language code to 1033," but when launching it from the desktop that debug message doesn't appear.
Here's debug.log:
RunAsAdmin/.onInit (line 186.10.3.23): [Launch]:RunAsAdmin value is
DriveLetter/Init (line 192.10.4.23): Current drive is C:, last drive is C:
Language/Init (line 194.10.22.13.23): Environment variable expansion on $0:
Before: `%PortableApps.comLocaleName%`
After: `ENGLISH`
Language/Init (line 194.10.37.13.23): Environment variable expansion on $2:
Before: `%PAL:AppDir%\OpenTTD\lang\%PAL:LanguageCustom%.lng`
After: `C:\Users\Kenny Williams\Desktop\OpenTTDPortable\App\OpenTTD\lang\english_US.lng`
Registry/Init (line 195.10.2.23): Registry sections enabled.
InstanceManagement/Init (line 200.10.29.23): WaitForProgram is set to false: SecondaryLaunch set to true.
Temp/Pre (line 208.10.17.23): Setting %TEMP% and %TMP% to C:\Users\KENNYW~1\AppData\Local\Temp
ExecString/Pre (line 210.10.1.23): Constructing execution string
ExecString/Pre (line 210.10.7.23): Execution string is "C:\Users\Kenny Williams\Desktop\OpenTTDPortable\App\OpenTTD\openttd.exe"
ExecString/Pre (line 210.10.48.23): Finished working with execution string: final value is "C:\Users\Kenny Williams\Desktop\OpenTTDPortable\App\OpenTTD\openttd.exe"
WorkingDirectory/PreExec (line 234.10.4.13.23): Environment variable expansion on $0:
Before: `%PAL:DataDir%\OpenTTD`
After: `C:\Users\Kenny Williams\Desktop\OpenTTDPortable\Data\OpenTTD`
WorkingDirectory/PreExec (line 234.10.5.23): Setting working directory to C:\Users\Kenny Williams\Desktop\OpenTTDPortable\Data\OpenTTD.
Global (line 254.23): About to execute the following string and finish: "C:\Users\Kenny Williams\Desktop\OpenTTDPortable\App\OpenTTD\openttd.exe"
Global (line 268.23): "C:\Users\Kenny Williams\Desktop\OpenTTDPortable\App\OpenTTD\openttd.exe" has finished.
Looks to me like you're not using the hg tip but rather an earlier release (RunAsAdmin when not set is also hidden now since Friday or so). I think I'll try putting the release version and hg revision into the debug file... that would explain very clearly why LanguageFile isn't working.
(Edit: as for TMP and TEMP, TMP overrides TEMP so it's needed, and some things manually use TEMP. It's best by far to set both.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Either something is wrong with TortoiseHg, or PAL just hates me. I pulled the tip from a couple hours ago (after you added the quotes) and was using that when I posted last, but just to make sure I pulled the tip again and now I'm getting the correct debug messages. -.-
My question about CleanTemp=false still stands though.
Edit: No I meant why does it set them at all? Doesn't Windows do that automatically?
The only real reason I always set TMP and TEMP is because it's easier to do it that way than to only do it if it's changed. There's no harm in it. So ignoring that point possibly, you're issue is now resolved?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
For those that can't be bothered getting Mercurial, they can now try out the hg tip by downloading an archive in bzip2, gzip or zip format, from the development repository; see the "bz2 | zip | gz" links near the top.
No excuses now.
(Explanation: I finally got round to adding the [web] value allow_archive = gz zip bz2 to .hg/hgrc in the SourceForge repository.)
A new release (an RC) is due some time soon. I think the only remaining known issues are with the registry plugin (and not very serious issues at that, missing Wine 1.0 support and registry keys with a dot (.) in them not working). Any last issues people have which I've missed (I was not present over the weekend and quite a bit happened over the whole site during that time...), please report them now or they probably won't be fixed for RC1.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I would like to be able to close all the open portableapps applications (and their open files) via the portableapps launcher, so the usb drive can be safely removed.
Apparently the language switching bug still exists. I think when I updated the tip again I only checked from the desktop. Still doesn't switch from the platform (the variables get switched around for some reason, like mentioned before).
I finally tracked down the issue with the language variables. Relative jumps don't just skip over !defines which !insertmacros, so it was landing in the middle of the SetEnvironmentVariable macro call, and so its pushing for use by kernel32::SetEnvironmentVariable was not complete yet, and it lost one of its variables and was left with an empty variable (because I'd pushed $_LOGICLIB_TEMP which was empty though there was no need to).
I tested this thoroughly with OpenTTD (hey, don't those Greek characters look strange... [explanation to avoid misunderstanding: funny little characters, not incorrect characters]) and it's all working now.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
John just helped me to pin down the crash issue Scriptdaemon was experiencing in certain obscure situations of the INI file in OpenTTD Portable on Windows 7. Replacing the new, kernel32::GetPrivateProfileSection ForEachINIPair.nsh with the old, FileRead etc. ForEachINIPair.nsh stopped it from crashing. So I've gone back to the old ForEachINIPair macro plus a couple of extras which I should have had earlier to make it behave as expected, whitespace trimming and quotation mark parsing; this means that a line like `
foo = " x"
` evaluated to `foo
` and `" x"
` with the old ForEachINIPair macro, but with the new GetPrivateProfileSection one and my update to the old one (i.e. the current one in the repository and what will be in the next release), it'll be `foo
` and `x
` as expected.This means that launcher.ini can no longer be encoded in UTF-16LE, but I ahve yet to see a case where that will be necessary, anyway. At some point in the future I'll get round to making it capable of dealing with either (I'll refer back to Gringoloco's patch) but for the moment it's ASCII-only.
Now I'm happy to release a Release Candidate (but I'll wait for Simeon's . registry issue if he's quick).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Does this also fix the issue with DefaultData not being copied over correctly?
That's another issue which I just can't reproduce on XP or Wine. Nor can I see any issues in the source code. Try it again.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Good:
1. OpenTTD Portable no longer crashes.
2. After launch, the language remains what was previously selected in-game if I launch from my desktop.
3. DefaultData seems to be copied over correctly now.
Bad:
1. Environment variables aren't evaluated if inside quotes (launching from PA.c menu after deleting Data folder).
Launcher .ini
openttd.cfg
Thanks, I'm glad of the first three working.
As for the not parsing of %PAL:LanguageCustom%, what that actually indicates that the environment variable PAL:LanguageCustom is not defined. That will be a side-effect of the new language-switching code; I'll take a look at it now (or after tea). If I haven't resolved it by the time you see this message, it might help if you'd post your [LanguageFile] section.
At some point I should get you to write a few worked examples for the manual. Seems to me you should be good at that.
Edit: ah yes, I see the issue, PAL:LanguageCustom will only be set if PAP is missing, will commit fix after tea.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Yeah, I can certainly do that.
Scriptdaemon: the important thing in your report that language switching isn't working properly is that it's saying that the environment variable PortableApps.comLocaleName is empty (set, but empty). The problem is, I can't work out why that would be. Can you see anything wrong with this code?
That's all the code that there is for PortableApps.comLocaleName. I presume PortableApps.comLocaleWinName is LANG_GREEK? (Refer to Process Explorer to inspect the environment, could be useful if you could tell me the values of all of them inside OpenTTD.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I don't think the bug lies in that bit of code, but rather before it.
http://dl.dropbox.com/u/1442139/Untitled.png
It seems to switch a couple vars around at some point before that, most importantly PortableApps.comLocaleWinName to PortableApps.comLocaleID instead, so when that code removes the first 5 characters from it, it removes everything.
As far as the screenshot: the one on the left shows the vars before that debug message, and the one on the right shows as that debug message appears.
I'll see if I get time to look at it today or tomorrow. Something weird is going on (as you have noticed!).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I think I worked out why it was doing it; I was pushing $0, but then using it as a variable and so messing up the macro variables when $0 was one of the parameters. I've fixed that, I think that should fix your problems but I don't have time to test it thoroughly just now (if you haven't by tomorrow I should be able to test it then).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Problem still exists.
Btw, the copyright symbol in the bottom of the generator shows as a "?" when compiling with Unicode NSIS.
The following will fix the symbol, GeneratorWizard.nsi, line 61:
Another option is to convert the script to UTF-16LE, but this will break ansi NSIS compatibility!
Formerly Gringoloco
Windows XP Pro sp3 x32
Is that how it's handled by the PA.c Installer (your unicode build)? Because I don't have that problem with any of the apps I package.
The PA.c InstallerU & AppCompactor scripts are converted to UTF-16LE so it deals with this symbol !
Any of the launchers do not include the BrandingText, although you have to watch the EULA's, they could get messed up, just convert them to UTF-16LE (e.g. with Notepad++).
Formerly Gringoloco
Windows XP Pro sp3 x32
Yeah, I already do that with Revo Uninstaller Portable.
I'm experiencing rather strange behavior with the current tip. I'm trying to package Bos Wars Portable and these are some of the things I've crossed:
- DirectoriesMove doesn't seem to be working as it should (well, at all).- The launcher doesn't exit when Bos Wars is closed. (Is it possible that it is hanging?)
- I've noticed the previous point when trying to regenerate the launcher, it seems that it doesn't regenerate the launcher though gives no warning that the launcher actually cannot be generated since the file is still "in use," so as far as the developer knows the launcher was successfully generated when it was not.
- I've not been able to pinpoint this one yet, but sometimes the launcher won't launch Bos Wars while with other generations of the launcher (using the same revision of the generator) it does.
Edit: Wooow. Practically nothing works in PAL from the tip. Trying with Marble Portable:*Nothing* gets put into the Data directory (except MarblePortableSettings.ini) and everything is left behind.Also, launching from the final generator window it doesn't launch, but it does when running MarblePortable.exe directly. The launcher for Marble Portable also doesn't exit as it should.
Edit 2: I actually *thought* about what I was reporting, and it's no wonder nothing works since the launcher doesn't exit as it should (d'oh). That seems to be the main problem, along with the other things I have not crossed out (and the fact that the previous language switching bug wasn't fixed).
Edit 3: Something else has also occurred to me. Since Unicode NSIS Portable seems to have the same crash OpenTTD Portable did, would that affect PAL's ability to generate a launcher?
If I understand you right, 'PortableApps.comLauncherGenerator.exe' doesn't run Unicode NSIS launcher at all, but immediately runs 'makensis'. So that couldn't be a problem.
GeneratorWizard.nsi, line 110:
BTW: I will update Unicode NSIS launcher soon, but have to test today if PAL is in a state to actually do an update. (Sorry have been away for a week, but am all available again for the comming month)
Formerly Gringoloco
Windows XP Pro sp3 x32
Don't update yet until I (or Chris) figure out what's going on, and possibly where the bugs started appearing. (Although, I downgraded to Beta 4 and I still seem to have the same problem... so frankly, at the moment, I have idea what's going on.)
Edit: Actually, go ahead and update it just to test it at least. The more testing the better.
Edit 2: Correction, doing a clean install of Beta 4 fixes everything (except the bugs that were reported for Beta 4, of course).
Gingoloco narrowed the problem down to ForEachINIPair, and it appears it's specifically in TrimWhite.nsh (infinite loop).
Commenting lines 1, 60, and 61 in ForEachINIPair.nsh fixes the problem.
Also, have you seen this http://nsis.sourceforge.net/Remove_leading_and_trailing_whitespaces_from... ? (You just might have, but I've not run through your trim whitespace code thoroughly.)
It is quite odd, but simple to fix:
TrimWhite.nsh, lines 16 & 23, quotes are needed around '$\t':
Formerly Gringoloco
Windows XP Pro sp3 x32
This also seems to have somehow fixed the language variable bug.
Chris, you can go ahead and revert the last change before applying these fixes.
Also, I have a question. OpenTTD Portable doesn't use the registry, yet the debugger tells me "Registry sections enabled." Why?
Edit: Looking back at the link I gave (which Gringoloco showed me), it puts quotes around much more than you do. Is that necessary? (I don't know how quotes work in NSIS.)
Edit 2: Now LanguageFile doesn't seem to be working. Sigh.
What Gringoloco reports is quite clearly an NSIS bug, though whether in their documentation or their code implementation I can't really say. They say that $\t is a variable, not a definition (and the style fits too, $\t rather than ${\t}), and so by rights that means it doesn't need quotes. However this makes it clear it was turning it into
StrCmp $R2 0 +3
- and you can follow the code through to see then that it will never get out of its checking.As for quotes, they're not necessary unless you've got whitespace in a string (or quotes at the start/end of a literal). I tend to avoid quotes where I can in NSIS code, though whether that is wise or not I begin to wonder. It's normally neater, and when a parameter is being passed as an output variable putting quotes in just confuses matters.
I did see that leading/trailing whitespace removal function, mine was very loosely based on it (i.e. I looked to see what it was doing and saw that it was doing just what I was planning on doing). I didn't use it verbatim though because it's messy. I mean really, using functions rather than CallArtificialFunction...
I've committed that fix, anyway. As for LanguageFile, I don't think I've applied any change to that file which could affect it in the least. I'll check a bit later though. How's your environment looking when it's not working? And the debug messages?
A test suite seems to be to be becoming more and more important.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I think I was confused when I last tested it, going through it completely when set to Greek it actually remains Greek. However, which what may have had me confused before, is that all the language variables are English (launching from desktop, not the menu) and there are no debug messages whatsoever regarding LanguageFile as far as I can see.
Edit: You skipped my question about the "Registry sections enabled" debug message.
I noticed and fixed the "Registry sections enabled" message last Wednesday.
Concerning the LanguageFile stuff, when you run OpenTTDPortable.exe without the PortableApps.com language variables being around (in which case you should get "PortableApps.com Platform language variables are missing."), you should be getting a message "Reading the language from $1, section `$2`, key `$3`, with ReadINIStr." (naturally, values inserted) and then "Setting PAL:LanguageCustom to $8 based on the [LanguageFile] section." (ditto). What does the debug output (see OpenTTDPortable\Data\debug.log) look like?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
1. I still get it.
2. None of that happens (debug.log at end of post).
3. I have CleanTemp=false. Does it really need to set %TMP% and %TEMP% anyway?
4. I just noticed something interesting. When running from the generator ("test launcher" option) the first debug message I get is "Setting language code to 1033," but when launching it from the desktop that debug message doesn't appear.
Here's debug.log:
Looks to me like you're not using the hg tip but rather an earlier release (RunAsAdmin when not set is also hidden now since Friday or so). I think I'll try putting the release version and hg revision into the debug file... that would explain very clearly why LanguageFile isn't working.
(Edit: as for TMP and TEMP, TMP overrides TEMP so it's needed, and some things manually use TEMP. It's best by far to set both.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Either something is wrong with TortoiseHg, or PAL just hates me. I pulled the tip from a couple hours ago (after you added the quotes) and was using that when I posted last, but just to make sure I pulled the tip again and now I'm getting the correct debug messages. -.-
My question about CleanTemp=false still stands though.
Edit: No I meant why does it set them at all? Doesn't Windows do that automatically?
The only real reason I always set TMP and TEMP is because it's easier to do it that way than to only do it if it's changed. There's no harm in it. So ignoring that point possibly, you're issue is now resolved?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Yeah, OpenTTD Portable has been updated.
For those that can't be bothered getting Mercurial, they can now try out the hg tip by downloading an archive in bzip2, gzip or zip format, from the development repository; see the "bz2 | zip | gz" links near the top.
No excuses now.
(Explanation: I finally got round to adding the
[web]
valueallow_archive = gz zip bz2
to .hg/hgrc in the SourceForge repository.)A new release (an RC) is due some time soon. I think the only remaining known issues are with the registry plugin (and not very serious issues at that, missing Wine 1.0 support and registry keys with a dot (.) in them not working). Any last issues people have which I've missed (I was not present over the weekend and quite a bit happened over the whole site during that time...), please report them now or they probably won't be fixed for RC1.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I would like to be able to close all the open portableapps applications (and their open files) via the portableapps launcher, so the usb drive can be safely removed.
And while you're at it, force all the developers to read this:
http://msdn.microsoft.com/en-us/library/bb756917.aspx
Bob Bagwill
The former has nothing to do with the launcher. That would deal with the menu (and as far as I recall, I think that was in planning).
The latter has nothing to do with PortableApps.com packages as far as I can tell, but rather the base apps themselves.
Apparently the language switching bug still exists. I think when I updated the tip again I only checked from the desktop. Still doesn't switch from the platform (the variables get switched around for some reason, like mentioned before).
I finally tracked down the issue with the language variables. Relative jumps don't just skip over !defines which !insertmacros, so it was landing in the middle of the SetEnvironmentVariable macro call, and so its pushing for use by kernel32::SetEnvironmentVariable was not complete yet, and it lost one of its variables and was left with an empty variable (because I'd pushed $_LOGICLIB_TEMP which was empty though there was no need to).
I tested this thoroughly with OpenTTD (hey, don't those Greek characters look strange... [explanation to avoid misunderstanding: funny little characters, not incorrect characters]) and it's all working now.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
[DirectoriesCleanupForce]
Shouldn't this backup/restore any local folders of the same name? It doesn't seem to at the moment.
[DirectoriesMove]
Folders specified here seem to be created by PAL automatically. Wouldn't it be better if they weren't?
I'm just locking this thread so repost it in the RC1 thread and I'll explain why I've done it the way I have in both cases.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Pages