Jump to content

Juha Holopainen

Member Group
  • Content count

    79
  • Joined

  • Last visited

  • Days Won

    15

Juha Holopainen last won the day on September 22

Juha Holopainen had the most liked content!

Community Reputation

99 Excellent

About Juha Holopainen

  • Rank
    New Member
  1. TopSky plugin public beta

    A few words on using the beta on setups other than EE, FI or SE: In Denmark the SE setup can be used with one adjustment: the information in the TopSkyCPDLC.txt plugin data file is specific to Sweden, so it can't be used in Denmark. For other setups, TopSky.dll and TopSkyCPDLCsound.wav can be used anywhere, but the other data and settings files must be created specifically for the setup in question. For any setup, it is important not to mix the data and settings files between the release and beta plugin versions. The data files for the beta version contain information the release version can't use (attempting to use the beta data files with the release plugin will usually just cause error messages but in some cases even a crash). With the settings files, using the wrong version will lead to missing information and/or functionality.
  2. Scrolling in CFL list in ES

    With "scroll inactive windows" disabled, anyone should be able to scroll the menus as in previous Windows versions. With the setting enabled, the current release version of the plugin can't scroll the menus. The beta plugin can, but the code to achieve that isn't completely foolproof and the scrolling ability is occasionally lost. For anyone encountering this, it can be re-enabled by clicking on the colored square in the top left corner (left of the time value in the Global menu, that is...). The reason for this mess is that mouse wheel events aren't available for plugins so I just try to intercept the messages before they get to EuroScope.
  3. TopSky plugin public beta

    The next version of the TopSky plugin has been in development now for almost two years. Progress has been slow for various reasons, but for a long time now the only thing delaying the release has been a possible crash-causing bug in the code. I've never encountered the crash myself, and the few reports I have of it happening are months apart with so far no clue as to where the issue might be, or even if it is the plugin at fault or something else. Rather than delay the release indefinitely, I've decided to put the plugin into a public beta period, hoping that there are brave souls willing to risk getting a crash so that I could get the necessary information to fix the issue, or if enough time passes and no issues are found, consider it stable enough and release it. For testing purposes, the plugin package contains a command-line utility called ProcDump. It is used to monitor the EuroScope process, and in case of a crash write a memory dump which I can then examine to find out where the problem is in the code. While I can't prevent anyone using the plugin without ProcDump running, I can't stress enough how important it is to use it as a memory dump is most likely the only way to find out the cause for the crash if it happens, as it doesn't seem to be related to any specific action. If you're still interested in helping out, here's the download link. Installation: The beta package contains up-to-date common manual sets, a version history document listing some of the main changes and folders including files for three setups: Estonia (EE), Finland (FI) and Sweden (SE). The instructions here assume the basic controller package for the country is already installed as the beta package only contains the files specific to the beta plugin. It is possible to have both the current release version of the plugin and the beta installed at the same time, and that is the configuration I recommend as you might want to use the familiar and well-tested release version on some occasions. However, here are install instructions for both the "beta only" and "release+beta" setups: Beta-only installation: Put the procdump.exe file somewhere Copy the files in the package's PluginsBeta folder to the Plugins folder of your setup, overwriting where necessary Extract the files in the package's Settings folder to a temporary location Rename the settings files by removing the "_beta" part from each file Copy the settings files to the Settings folder of your setup, overwriting the existing files Release+beta installation: Put the procdump.exe file somewhere Create a copy of the Plugins folder of your setup and rename the copy PluginsBeta Copy the files in the package's PluginsBeta folder to the new PluginsBeta folder of your setup, overwriting where necessary Copy the files in the package's Settings folder to the Settings folder of your setup Create a copy of the profile file you normally use in EuroScope, name it as you want Edit the new profile file using a text editor as follows: Replace all occurrences of "Lists.txt" with "Lists_beta.txt" Replace all occurrences of "Symbols.txt" with "Symbols_beta.txt" Replace all occurrences of "Tags.txt" with "Tags_beta.txt" Replace all occurrences of "Plugins\TopSky.dll" with "PluginsBeta\TopSky.dll" Use: To enable the crash dump generation, the ProcDump utility must be run when using the plugin. It can be launched from the command line if necessary, but it's probably easiest to create a batch file to do it automatically. Here's how: Create a text file wherever you like, and name it appropriately, for example "ES+procdump.bat" Edit the file using a text editor to contain the following: start "" "C:\some folder\shortcut.lnk" cmd /c ""C:\another folder\procdump.exe" -e 1 -ma -w euroscope.exe "C:\yet another folder\dumps"" "C:\some folder\shortcut.lnk" is the shortcut you use to launch ES (you may need to create a new shortcut to use the new profile file if you chose the "release+beta" setup) "C:\another folder\procdump.exe" is where you put the procdump.exe file "C:\yet another folder\dumps" is the folder where you want the crash dumps to be put to. It is optional, but if specified, make sure the folder exists as ProcDump will not create it by itself (if not specified, the dump will be put in the folder the batch file is in). Then just run the batch file whenever you want to use the beta plugin, it'll start both EuroScope and ProcDump for you. ProcDump will open a command prompt window when it's running, don't close it! Note that if you're running more than one instance of EuroScope at a time, the batch file can't be used to launch the second (and subsequent) instances as then the "euroscope.exe" in the command won't be enough to specify the wanted process. Launch the new EuroScope instance as you normally would, then open a command prompt window and type in the following command to attach ProcDump to the EuroScope instance: "C:\another folder\procdump.exe" -e 1 -ma -w PID "C:\yet another folder\dumps" PID is the process ID number for the correct EuroScope process. To see that, open Task Manager and see its Details page for the PID number. Note that you'll have to check the PID of the already started ES instance before you launch the next one so you know which one is the new one. A bit complicated but only necessary when using multiple ES instances and wanting to make sure a crash dump is generated if any of the instances crash. It is possible to create a memory dump file from Task Manager even without ProcDump running. Just right-click on the desired process and select "Create dump file". It will be created into a temporary folder so don't forget to move it somewhere safe before logging off or shutting down your computer. I'm not sure if this dump file provides the same information as the one produced by ProcDump, or if it can be created in all crash situations, but if it can and you've forgotten to run ProcDump, it's better than nothing so try to keep this option in mind as well. I've noticed that opening some file dialogs in EuroScope will for some reason make ProcDump think ES has crashed. It will then create the dump and terminate itself (the only way to spot this is to notice that the command prompt window is no longer displayed on the task bar...). If that happens, ProcDump can be started again and it's probably easiest to have another batch file to do that. Just create a copy of the first batch file and remove the first line from it that launches the ES shortcut. The remaining line runs ProcDump and it automatically attaches to the already running EuroScope process, it won't be necessary to start EuroScope again (which is handy if you're already controlling). It's a good idea to test everything is set up correctly regarding the crash dumps when you've done all this. Run the batch file and wait until ES has started and the plugin has loaded. Then, enter the command ".topskycrash" to the EuroScope command line. It will cause an immediate unhandled exception that crashes the plugin and EuroScope. Check that the dump file was created. If you can’t find the dump file (it's somewhat over 200MB in size and should be named "EuroScope.exe_170424_224756.dmp" for a crash on April 24th 2017 at 22:47:56 system time) where you thought it’d be or anywhere for that matter, something went wrong in the setup. Instructions: If you have any questions about the beta program or how to install and set it up, please post on this thread. I hope I got all the information right, but I wouldn't be surprised if it wasn't 100% correct. I'll clarify where necessary. If the plugin crashes and a dump file is available, let me know where I can download it. Even though the main objective is to find out if there is a problem in the code - and if so - fix it, please report if you find anything wrong, no matter how trivial. All these reports should be posted in a dedicated thread I'll create for this purpose in the Finland FIR subforum. That'll keep all the information in one place, and I have moderator privileges there to keep the thread tidy. Also post there if the plugin crashes regardless of whether a dump is available or not so others get an idea of what's happening.
  4. ES(r15) Crash

    I'd try the e-mail found on the EuroScope website: support at euroscope dot hu
  5. ES(r15) Crash

    Has either of you sent the resulting crash dump to EuroScope support? Gergely is probably the only one who can find out what's causing the issues. If the crash happens so fast that a dump isn't being created, then there's probably not a lot that can be done...
  6. Ground Radar plugin update

    As of today, version 1.1.2 is the current public release for the Ground Radar plugin. Anyone using version 1.1 or newer should see an update message box when starting EuroScope. The main changes of version 1.1.1 from version 1.1 are: Unique settings for each opened radar screen Possibility to have airport-specific settings pre-defined Stand assignment only possible for assumed and untracked aircraft More options for the APP Window (view rotation, prediction lines, history dots, etc.) Raw primary radar data display Possibility to hide the ground mode track label to simulate a very basic system Version 1.1.2 has just some minor fixes to 1.1.1 As this is the first time the update check feature introduced in version 1.1 is used, here's a short description about it: The update can be either: Recommended: In this case there's no deadline and the user's current version can still be used without any restrictions. Mandatory with a deadline: In this case the message box will show the deadline if it hasn't passed yet. The current version can be used until then, but it's still recommended to update without delay. Mandatory: The current version can not be used and (nearly) all plugin features will be blocked until it is updated. The same happens if a "mandatory with deadline" update is not done before the deadline. Currently the update is just recommended so any previous version can still be used, but it will at some point become mandatory to have only one "official" version around. Easier for controller training and technical support. The current version should eventually make its way to the sector file packages, but until that happens, the updated files are available at the URL specified in the update message box. The update package contains the plugin's current manual set, the plugin itself and those plugin data files that can be used globally. The update procedure is rather simple: Download the update package Copy the included plugin (dll) and data files (txt) to your plugin directory, overwriting the existing files. DO NOT delete any files.
  7. TopSky - <ALT> RMB - Radar Menu

    Probably one of four things: 1) You're just too fast for the plugin. Try doing it deliberately slowly, i.e. hold the ALT key down, wait a moment, and then right-click. If it doesn't work after a couple of attempts, speed is probably not the issue here. Read on. 2) The ALT key is defined for something else, for example as a PTT key. In this case the plugin may never get the information that the key is down, and won't be able to open the menu. Free the ALT key from other assignments if possible. If the ALT key isn't assigned to anything else, or if freeing it is not an option, read on. 3) You're running EuroScope on a non-Windows-PC-setup. Apparently the key presses are not transmitted to the plugin in the same way in these cases. Adjusting some computer/software settings may help, but unfortunately I can't help with that. Read on. 4) The stars and the moon are out of proper alignment, and the thing is just never going to work no matter what you do. Fortunately there is still something that can be done: open the TopSkySettings.txt file found in the same folder as the plugin dll (TopSky.dll). Insert the following line: Shortcut_RadarMenu_Combo=0x00 This causes the plugin to stop looking for the ALT+right-click combination. The Radar menu can then be opened by right-clicking on the Global menu bar (the menu bar at the top of the screen). If even that fails, then I'm all out of ideas.
  8. VATSIM Scandinavia ATC Training Director

    So all the talk about our constitution being not fully in line with various VATSIM regulations had nothing to do with the election but instead against something the Founders and/or BoG have decided? I'd say that's an important piece of information to the discussion, why not bring it up from the start to save everyone's time? In all honesty I can't say I'm impressed with how this matter has been handled, but having said that, I appreciate you taking the time trying to explain the actions taken, and I'm still somewhat hopeful for an outcome both parties would feel good about. In case the instruction isn't readily available for the public somewhere, would you mind revealing its exact contents here? Does it really ban elections like this one? I see the point for ensuring qualified personnel in certain key positions, but when the vote is set up so the membership is only given acceptable candidates to vote from, why is it expected to automatically go awfully wrong? Maybe this should be brought up to the Founders/BoG, it's possible they haven't thought of every possible scenario... I'm sure both the Founders and BoG realize that in an organization the size of VATSIM, a situation where some of the rules are written down for everyone to read and others are only revealed when you happen to break them, cannot work. When the rules need changing, let's change them - quickly if necessary, but until then the old rules must apply. I think that if in Aleksander's blood alcohol limit example the limit had been lowered to .2 a week earlier without telling anyone, it would be outrageous to prosecute the poor redneck even if he was technically guilty. The community needs to be able to rely on basic stuff like this to function in the long term. Sometimes the drunk gets away with it on the last day of the old rules, but that's a price that has to be paid. In any case, we shouldn't hurry into any major changes, there's no need to get everything done by tomorrow. If the constitution has been wrong for years, it can surely remain wrong for some weeks until all the necessary updates can be made. The same goes for the training organization. Having a DTD has its pros and cons, we need to decide on what works best and then argue the case further if necessary. And yes, I would happily vote in a Financial Minister election if it only stood in our constitution that a vote must be arranged should the politicians be unable to make a decision
  9. VATSIM Scandinavia ATC Training Director

    Even after taking some time to think about it, I'm still puzzled as to what exactly it was in this situation that caused so much concern in VATSIM staff that they pushed the panic button. It is unfortunate that the board were unable to reach an unanimous decision on the matter, but rather than continuing to spend their valuable time with a deadlock situation, presenting the two qualified candidates for a vote as per our constitution just makes sense (qualified being the key word there, as either of them would - as I understand it - have been chosen had their application been the only one). Like Aleksander above, I'm also curious as to which document or documents - and which specific part/s of it - prohibit a vote like this? Listing some years (at least 2003 and 2004 have been mentioned) and various VATSIM related documents without any clarification just strikes me as odd. You probably know the documents better than most members here, and perhaps even the reasoning behind the text, so a bit more effort in trying to explain your actions and the rules behind them would probably be appreciated by many of our members. If a deputy TD position is decided to be added (I have no idea if we need one or if the position can attract applicants, it all depends on the job description), it may be best to halt the whole process until new job descriptions for both the TD and the deputy TD have been drafted. After that a new application period for both positions, and hopefully there will be applicants... If all else fails, here's my proposal to get things moving again: We go ahead and vote. The vote, instead of deciding who is chosen, is a consultative one. Once the voting ends, the board meets. They review the candidates again, taking into consideration possible new information since their last vote (such as the consultative member vote, if they so choose). Then they vote again, hopefully reaching a decision for us. If not, well, then it's time to think of a new plan.
  10. Fly and See Santa 2015 debriefing

    This year was my first time serving primarily as APP - arrival (EFRO_R_APP) for the first four hours and radar (EFRO_APP) for the last two, with a break including a short time at EFES covering for a toilet break in between. Even though my experience from those positions is rather limited, it seemed that for the first time we were able to pull of the entire event without having to stop arriving traffic to sort out a messy TMA with a similar number of operations as the last two years, I'd say this was a major improvement! The only time I encountered any issues with the number of traffic was when one aircraft suddenly decided to park at six miles final, but fortunately I was able to persuade the pilot to continue moving before I ran out of space to vector the following aircraft. During the shift at EFRO_APP the work was mostly getting aircraft out of the holds and sequenced into a downwind flow. I wasn't completely happy about the idea of using just a single downwind leg before the event, and my opinion didn't change during the event. The way I see it, most of the work in sequencing two arrival flows into one would have been avoided by using two downwinds, and the spared mental capacity could have been used for other purposes. It's not a question of whether a single downwind works, it does (during peak hours the achieved operations rate was pretty much constant at around 25 per hour), but would two have provided better results? There were occasionally long gaps between arrivals that were at least partially caused by the extra effort required to synchronize the arrival flows into one at such an early stage. All in all, after the event was over I thought we had had a lot less traffic as everything went relatively smoothly without the traditional chaos at some point, but the stats tell a different story. EFES and ESOS probably had their hands full with enroute holdings, but I don't think there's any way to avoid them as there are just so many aircraft in such a short period of time. The VFR aircraft was probably a nice challenge for EFRO TWR and it had little or no effect on the total operations rate. At least I'm happy about any traffic regardless of flight rules, traffic doing circuits will just have to expect some delays. I can disable the RAM alert for holding traffic in the plugin, but then it'll be disabled regardless of where there the aircraft is (approaching the hold, holding, or having left the pattern but the controller forgot to terminate the holding...). For the route drawing, without a log I can't say for sure why it behaved like it did, but in any case the route data comes directly from EuroScope and the plugin just draws the lines. I'd expect that at least those planes that didn't have the holding fix in their route would have had the issue since after reaching the holding fix, ES would consider the direct-to point overflown and reverted the route drawing to the original route.
×