Pete Dowson

Well, it may make sense for whatever it is you want to do it for, but it doesn't in terms of simulating a real engine. I don't think there's any way to set the outputs/results of simulation without simply doing no simulation, which seems to wreck the whole point of a simulator. If you want to simply fake the controls you can have your own gauges and so on with fake values. If the spool up time is too slow there may well be some parameters you can change to adjust that (for less realism, effectively?) in the AIRCRAFT.CFG file. You may need some advice from an FS aircraft designer for that, but check the documentation in the Microsoft SDKs in case it is clear there. Regards, Pete

N1 and N2 values are results of simulation, not control inputs. You don't control the turbine or propeller revs directly, but by control over fuel injected and so on. Of course. Engine thrust is controlled by thrust levers, also known as throttles. Offsets 088C etc. For props you also need to control mixture and propeller pitch to set the thrust appropriate to your environment and phase of flight. Regards Pete

Good. Evidently something was gumming up the works somewhere. There's so many things running in Windows these days that it's often hard to work out what is going on. Thanks for letting me know. Regards, Pete

Try to attach the log again, as I don't see it here. Please close FS first -- a complete log is important. If it's too big to attach here, send it to petedowson@btconnect.com. Zip it up first -- and include your FSUIPC.KEY file please (also from the FS Modules folder). Regards, Pete

Sorry, I don't know. I really don't know anything about any of that stuff -- the values themselves were located in earlier FS versions by other folks, I just documented them. I have cross-checked some of them against the values saved in the Flight files, so that I can re-identify them from FS version to FS version, but that's all. Maybe someone else reading this will have sufficient knowledge of the FS modelling to be able to comment. Regards, Pete

There's no offset you can read to tell you FSUIPC cannot supply the contents of the offset because if you have no connection it cannot tell you,if you see what I mean. :wink: The timeout of the message request either indicates FS is too busy doing something else and therefore didn't process the message in time, or that FS has crashed or been closed. So, if you continually get timeouts over a period, you can only assume something's wrong. What it is you can't tell very easily. If you are using the C library I supply in the FSUIPC SDK, it uses a timeout of 2 seconds and tries up to 10 times, so if the FSUIPC_Process call returns a timeout failure, you know it has failed to get any response for 20 seconds. This error is FSUIPC_ERR_TIMEOUT. If FS just disappears so that its Window handle is no longer valid, I would expect the SendMessage to fail, so in that case the error should be FSUIPC_ERR_SENDMSG. I hope that the other language libraries or support packages provide similar results, but you'd need to check the sources and headers. Regards, Pete

See READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys above. Pete

No, you are reading the table incorrectly. Each field has the length specified. Unlisted offsets are just that -- they may access parts of the Sim which we haven't worked out yet. You may not have noticed, but things do get filled in gradually as more useful data is identified and documented. This applies to all unlisted offsets below 4000. From 4000 upwards it is nearly all FSUIPC-local memory, used for applications, excepting the 6000 ff area which I used to map into the GPS data owned by FLIGHTS.DLL. You were writing to unknown parts of SIM1 as well, believe me. Since this crashes FS in the end, one of the values you overwrote was very likely a pointer or a value used as an index on a pointer. Regards Pete

This is offset 3380 we're talking about, right? Where do you find "read only" after 33FF? The offsets 3400-347F could do anything. I think only a few are marked read-only in my tables. The others either write to the listed values, or else write to weird untested as yet unknown places in SIM1. If you write 256 bytes to offset X, and the first field at X is 128 bytes long, then the first 128 bytes will be used for that field. The remaining 128 bytes go to whatever fields follow. The whole offset area is treated as continuous memory, although it is nothing like, to maintain that illusion, as that was indeed what was happening in the original FS6IPC with FS98. The only truncation going on is FSUIPC putting a zero in the 128th byte, hence truncating a 128 byte non-terminated string to 127 bytes. Your writes to offsets 3400 and following are regarded as totally separate "commands" to FSUIPC. Every separate field is a separate command, but the whole lot is simulating a contiguous expanse of "memory" (which it most certainly is not). Regards, Pete

As explained in the WideFS documentation, that happens when the Client is not getting messages from the server and times out the connection. When it re-connects the count increases. The disconnection at the server end is more generous with its timeout -- eventually, when the server sees no activity on one of the connections it will close that end, and the count will decrease again. But this will only happen when the Server is able to talk to the client so that it doesn't keep timing out. It sounds like something is keeping FS from running so much that WideServer isn't able to get messages out to the Client (it only needs one frame every two seconds to keep it happy, so that's pretty serious). With both WideServer and SB3 both presumably trying to use the Network (?) maybe they are somehow blocking each other. Where's the Internet connection? Over the Network on a router or on the non-FS PC? If so, you are definitely putting a big load on the Server Network connection when AS2004.5 is in full flow, as it will be initially, and SB3 is also trying to sort stuff out with its server. Why SB3 works better on the non-FS PC I'm not sure -- maybe it's the Internet connection -- but I would have thought that would be the better approach in any case. You ought to leave the FS PC as free of extra clutter as possible. FS is very hungry, especially using weather from AS2004.5. Regards, Pete

Hmmm. Good luck! Try also using the interim version 3.471 of FSUIPC I sent, just in case it makes any difference. Kepp me posted. Regards, Pete

All this really shows is that there's something wrong. I really have no way of finding out what. There is certainly nothing in WideFS you can change for this. It will be something to do with the network, or more likely some program interfering or blocking things. I'm really not able to help much more. I assume you've been all the way through all the hints and suggestions in the WideFS document? That contains summaries of all I've learned about Networks over the last 7 years of WideFS. If it isn't in there I haven't a clue I'm afraid. There are only two other suggestions I can make. One is to use the Task Manager (CTRL_ALT_DEL) and delete every unknown or unwanted process in turn. Maybe you'll find the cause that way --- eg. an anti-virus or other blocking type program. Some processes to terminate may crash the system -- just re-boot and remember to leave that one alone next time. This process has found culprit processes before now, so I think it is your best course of action. The second suggestion is to see if there's any further advice about Networks you can get from folks who really know them. The expert I usually rely on is Katy Pluta, who you can reach either via PM support or sometimes over in the FS2004 Forum. Currently there are over 1000 registered WideFS users and none of them have reported anything quite like your problem, not in the 6+ years WideFS has been going. It's a real puzzler I'm afraid. Regards Pete

I've now tested with paths as well. Basically, what happens when you write zero to 3F00 is that FSUIPC checks to see if there's a path in the string provided at 3F04. If there is, it sends it to FS unchanged. If there's no path, it pre-pends the full default path -- the one to the My Documents place for Flight files. I tried it with the full path to FS's supplied Flights, i.e. D:\FS9\flights\ etc and that works fine too. If you just use a partial path, like Island\FSUIPC doesn't add anything, but FS doesn't know what it means either. So you either have to provide the complete path or just the filename for the default user path. I'll clarify that in the programmer's guide. I'm sorry I'm unable to help with whatever it is crashing your FS. I cannot seem to make anything crash here, even with bad paths and/or filenames -- in the latter cases FS simply does nothing. Do you have any other Add-Ins in FS? i.e. other DLLs? FSUIPC posts a message via the FS window when you write to 3F00, as it must make sure FS is in a message-processing loop when it tries to call Fs's load and save routines. This also prevents FSUIPC callers timing out because of the Load taking too long. To send this message, FSUIPC uses a WM_USER+n message number. I'm wondering if something else could also be making use of such. However, if that were the case, FS would crash in the same way when you saved a flight too. Anyway, just to make sure that nothing I've changed in FSUIPC recently has affected things, I'll send you an interim version soon -- probably tomorrow. This is not a solution, just a "making sure we are using the same code" exercise. Regards, Pete

Sorry, I'm lost now. I've never heard of a problem like that. By default FS certainly doesn't automatically change the fuel mixture. How did you "take out all the assignments"? What "button" -- you mean the "Y" key? If that is what you mean, I don't know. It isn't possible really. Something's got really screwed up in your system somehow. Now you are confusing me. I notice your subject line is "button offset" -- what did you mean by that? Whay has any of this to do with buttons (I thought you were talking about the Y key, on the keyboard), and what exactly do you mean by "offset". If you haven't changed the assignment, the fuel full lean is Shift+Ctrl+F1 and full rich (fuel on) is Shift+Ctrl+F4. I assume you have no joysticks connected which are setting mixture full lean? Try disabling the joystick in the Options menu. Otherwise I think it's time you visited the FS2004 forum, see if anyone there has this sort of problem. Pete

I've tried loading a flight through FSUIPC with no path, just the flight name, and it loads it from the default flights path successfully and carries on okay. I've tried it with all sorts of different flight names. I'm just about to test with paths in the string too, to see if it only selects folders within the default folder, or whether I can get it to load those in the main FS flights sub-folders. There's really nothing in FSUIPC which can cause that crash you are getting. The save and load flight actions are simple calls to the routines in FS which do those things. It sounds as if something else is conflicting with the flight loading somewhere. Is your program perhaps trying to access something before the flight is loaded? (Mind you, FSUIPC traps its own errors, so you wouldn't get FS crashing if you asked FSUIPC to do anything for you when it shouldn't). What else do you have running? Can't you get any information about where the crash is occurring? Incidentally, it also just occurred to me that Radar Contact version 4 (I'm in the Beta group) has been using the Flight Loading facility through FSUIPC for many months now. It certainly never seems to cause a crash either. Regards, Pete

If you set 3F00 to 1 first, there would have been two flights saved -- it is the writing on something to 3F00 which triggers the action. you always need to write the string to 3F04 first. Er, but the log shows the flight being loaded: That is the flight name that I am trying to load. Looks fine to me?? The line at time 185390 is FSUIPC independently detecting the loading, by FS, of a new flight. This part of the code operates on all flight loading, no matter where from. Try loading it from the Flights menu, you'll get the same entry. If FS9 then crashed it's something to do with what it loaded, as that will be some time later. How is it that FSUIPC managed to continue and log the time etc if FS crashed? Normally if a process crashes all of its main thread crashes with it. There's no sign of a crash in the log. can you explain a bit more about what actually happened? Pete

Sorry, what "initialisation" report? I don't understand why anything of FS is initialising when you are booting into Windows afresh, unless you have FS booting as part of windows start-up. You save you get an "initialisation report" when shutting down the PC too? I have no idea how it is possible to persuade Windows to actually load FS when you are closing Windows down. Can you explain how you have set that up? Regards, Pete

Both of those result from the same FS control -- fuel mixture full lean for props is also the fuel cutoff action for jets. Somewhere you have the Y key assigned for this function too. As you have no add-ons, nothing else running, that is a bit of a puzzle, but go to FS Options-Controls-Assignments and restore defaults. There's a button for it. Do this for both normal and slew modes. Another way to do it, which may be more decisive, is to delete your FS9.CFG file before loading FS, so it will make a completely new one. You'll find that in the Documents and Settings\\Application Data\Microsoft\FS9 folder. Regards, Pete

Just entering slew mode (Y) and exiting it (Y again) turns the engines off? What actually happens -- fuel cut, magneto off, what? Can you see? All aircraft or only one? More information may help. Regards, Pete

This can happen if the previous run of FS has not completely closed down, so FSUIPC is still running in an existing process. There are some problem add-ins which sometimes cause this -- ActiveCamera was one, for example, though I think that's been fixed in the latest version. What happens is that you close FS and the Window disappears and everything seems okay, but, because one DLL is not terminating, the whole process is still active and running -- probably just that DLL stuck in a loop or deadlocked on some FS or Windows resource. To check this, after closing FS, use the Task manager and see if the FS9.EXE process is still listed in the Processes list. If so, you make have to terminate it forcibly there before attempting to reload. You will then need to identify the culprit added DLL by a process of elimination. When re-booting Windows? How is Windows having anything to do with FS on start-up? Do you have FS as part of your startup options for Windows? Whatever is not terminating is doing this -- presumably there's some relationship between the 4 attempts and whatever resource it is loacking up on. Possibly, then, one of the SB3 DLLs (there are several I understand) is the one hanging and refusing to terminate, once in 4 tries. I don't know if they can work on their own, but it gives you are start to try to find out what is going on. Meanwhile, check the Process list after terminating FS each time. Regards, Pete

but this doesn't appear to be the Client log matching the Server log above. The server said: whilst the Client says: As it is, the logs merely show that the Network isn't working correctly, but I'm afraid they don't tell me why. Pete

I don't unserstand what you are saying at the end there, but you should know that "UseSendInput" was added for TeamSpeak and doesn't need or use "directed" KeySends -- i.e. the ",Run1" part at the end is not used with SendInput. The SendInput works in one of two cases: 1) the program intended to receive the keypress has the keyboard focus, or 2) the program is grabbing the Key in any case as a Windows Hot Key. TeamSpeak is of the latter type. I do not know what SB3 are doing so I cannot tell you how to make it work, but you could try removing the UseSendInput parameter and leaving the rest intact. I have also been assuming, of course, that you actually do have something programmed in the Server or FSUIPC to send KeySends 3 and 4? You've not shown me that part. In the end I think you may have to get help from an SB3 user or programmer who knows how to use its PTT. Regards, Pete

You have only managed to explain your problem sufficiently well for me to understand you differently in your last email. I'm sorry if I misinterpreted you before, but your original complaints were actually rather ambiguous and did point to the opposite of what now appears to be the case. Regards, Pete

The last point seems to indicate that you paid for and registered FSUIPC. Is this correct? If not then you don't have access to the battery extension facility. If you have a correctly registered installation, just run FS, try NAV or FlightMax, then close FS and show me the FSUIPC.LOG file (from the FS Modules folder. Pete

It's direct from FS, but I very much doubt that it calculates it from the IAS. It will be working the other way round. Since it always knows the position relative to the ground and the wind speeds it can more easily derive TAS than IAS. Pete