Jump to content

SAS_Storebror

Members
  • Content Count

    938
  • Joined

  • Last visited

Community Reputation

470 Excellent

3 Followers

About SAS_Storebror

Contact Methods

  • Website URL
    https://www.sas1946.com

Profile Information

  • Gender
    Male
  • Location
    Depends
  • Interests
    CFS :-)
    Child Protection
    Animal Welfare
    Programming (Java FTW!)
    Biking

Recent Profile Visitors

1733 profile views
  1. This, or just hoist up, press F10, sit down, press F12, repeat. No need to even disable TrackIR for this. The setting is plane dependent and it will survive restarts of the game. You can really make yourself comfortable with each plane individually that way. Mike
  2. You can always move into your favourite position and press F10 to make that your new default centered location in that particular plane's cockpit. Mike
  3. I see your point, but how does one mission maker's idea on one single multiplayer server mixed with the demand for a new aircraft compare to a completely unrelated plane being on sale right now? Isn't that slightly off topic in this thread and with it, a little disrespectful towards the team sporting this whole thing? I know that this wasn't your intention, but that's what it can easily come around like, especially when people jump the gun on such comment like @77.CountZero just did. I do not wish to offend anybody, I'd just want some of you guys to try to slip into the dev's shoes for a brief period of time and consider what it feels like to them if they have to read such comments on a thread which is just supposed to make customers happy. Mike
  4. I don't know what kind of issue you guys have with the U-2, it's a great plane and endless fun to fly. It serves it's purpose very well. It's not the plane's fault if you judge it by it's survivability against a riot of 109s and 190s in bright sunshine only. If you concentrate on the fastest planes with biggest guns only, you'll miss a whole lot of fun in this game. Just saying. Mike
  5. Thanks @BlackSix, that's exactly what I'm trying to get across all the time: The distance between Airfield and Aircraft is what matters, nothing else. This is consistent throughout the whole takeoff/landing logic, be it when the planes spawns, lands, or decides to land. In @JimTM's great summary this is the only point that was wrong (and carries a note about that fact at the moment, but I take it that it will be changed soon now that there's a corresponding dev comment on that matter): Planes don't take off according to the airfield object closest to the takeoff command, but according to the airfield object closest to themselves instead. Mike
  6. Lucky us the real server isn't concerned. I'm only trying to get my local "test" copy working again like it's been for years. The startup.cfg is fresh from the reinstall. I've compared it to the working file from the public server and there's no difference. Yesterday I've uploaded the whole game folder from my local PC to our server on the internet to see whether it's working there. It does. So this is probably something related to connectivity, but now that all ports are open and the PC can be reached from the internet, I'm scratching my head as to what could keep it from showing up on the list... Mike
  7. With a single airfield that might be true (it makes sense after all), never said any different. However as soon as you have multiple airfields available (for the regarding side that is), the closest airfield will win, regardless what it's taxi points look like or where they are, even regardless whether it has any. Mike
  8. As mentioned earlier, I've tried it and it doesn't work like that. Really. Maybe it should work like that, but it doesn't. Mike
  9. I can definitely rule that out from my testing results. Nevertheless I agree that more tests are necessary. So far, the only reliable solution to me was to give the nearest airfield object a suitable taxi chart. Actually this corresponds to AI's behaviour when it comes to picking up the landing taxi chart of choice (when AI RTB decision is active). In that case it will also be the chart of the closest airfield to the aircraft at the time of landing decision. The distance to the actual chart, the location of the landing command MCU etc. don't matter in that case either. You've outlined that correctly in your summary by the way Mike
  10. Sorry to say but that part isn't correct (or at least seems not to be correct anymore). I have just checked this, because if it was correct, I could have massively simplified a training mission, but unfortunately the truth is: AI planes invariably choose the airfield which is closest to their spawnpoint for taxi to takeoff calculation. If that airfield has no suitable chart (i.e. no chart at all, or the initial park point is too far away from spawn position, like 1km off or so), the planes will run in circles for an arbitrary time, and then take off in an arbitrary direction. The location and/or direction of the takeoff command seems to be completely irrelevant. Mike
  11. Still banging my head on this... Last weekend I've performed some more tests @home. Some things I've found out are: If "ServerIP" gets set to any specific value, it has to be an IP address that exists locally on the PC, otherwise DServer will throw a "mission load error". If "ExternalIP" is set to "1", DServer will always use the PC's IP address assigned by the router locally. For instance, the PC in question has the local IP "192.168.178.2" and external IP "84.46.***.***". It is reachable from the internet on the external IP (e.g. running a webserver on the same PC works and it can be reached from e.g. a mobile phone). Port Forwarding on the router and Windows Firewall are configured correctly. Ports 8991 (remote console), 28000 (game itself) and 28100 (Downloader) are configured for both TCP and UDP protocols. This is my current testing SDS file (it doesn't matter where it's stored by the way, I've tried). It's based on the one we run on our public server, only difference is that this test file has just one single mission configured and it's using a different login. The login is double-checked and if you alter a single bit of it, DServer will not register to the Master Server anymore: // Generated by dserver // credentials login = "********************" password = "**********" // server info ranked = 0 mode = 1 banTimeout = 900 lobbyTimer = 60 coopQuorum = 0 allowMouseJoy = 1 ServerName = "The Flying Ass Clowns TEST" TacviewRecord = true serverDesc = "IL-2 Great Battles TEST Server operated by The Flying Ass Clowns" // connection settings protection = "" maxClients = 50 maxClientPing = -1 ExternalIP = 1 ServerIP = "" DownloadLimit = 50000 UploadLimit = 50000 DownloaderPort = 28100 TCPPort = 28000 UDPPort = 28000 // remote console settings RconStart = 0 RconIP = "" RconPort = 8991 RconLogin = "mastergubi" RconPassword = "elephant" // mission rotation data ShutdownLoads = -1 [rotation] random = false file = "Dogfight\FAC Training No38 Winter\FAC Training No38 Winter" [end] // preset and advanced settings preset = 1 // preset: server related killNotification = 1 friendlyFireReturn = 0 finishMissionIfLanded = 0 lockPayloads = 1 lockSkins = 0 lockFuelLoads = 0 lockWeaponModes = 1 penaltyTimeout = 10 respawnTimeout = 1 coalitionChangeTimeout = 10 finishMissionTimeout = 1 missionEndTimeout = 1 idleKickTimeout = -1 tdmPointsPerRound = 2000 tdmRoundTime = -1 coalitionsBalancer = false // preset: mission related objectIcons = true navigationIcons = true aimingHelp = false courseWeaponsAimingHelp = false padlock = true simpleDevices = true allowSpectator = true easyFlight = false autoCoordination = false autoThrottle = false autoPilot = true autoThrottleLimit = true autoMix = true autoRadiator = true noMoment = false noWind = false noMisfire = false noBreak = false invulnerability = false unlimitFuel = false unlimitAmmo = false engineNoStop = false hotEngine = true This is the router config (you see every entry twice, one is for UDP, one for TCP, left is the PC's internal IP): These are the firewall settings. Additionally the "DServer.exe" is also configured in the firewall to have access to each and everything: This is the SDS with manually configured IP: This is what DServer.exe shows when loading that SDS: Same thing with "External" checked: DServer again is happy: But what does it help when the Server doesn't get listed? This is the Server list, our publically hosted normal server is listed, the locally hosted test instance isn't: Mike
  12. As written in my post right above yours: So yes, I've tried that and it didn't help. Can't confirm that. On our working public DServer, the SDS file is in a completely different location than the remaining parts of the game and it works fine. Nevertheless, I've tried with the SDS in the "bin/game" folder and as expected, it doesn't change a thing. Thanks for your suggestions gents but the mystery is still unsolved. Mike
  13. Thanks for your feedback @Cynic_Al but see, I've tried that in the very beginning already and after the complete reinstall as well, to no avail: Mike
  14. Nevermind, figured it out myself. Attached you can find a working up/down counter group, IMHO in the most simple way. "IN+" increases the counter, "IN-" decreases it. "0->1" output gets triggered when counter value goes from 0 to 1, "1->0" gets triggered when it gets back to 0 again. Only thing is that the counter only works with positive numbers: You must not decrease it when you didn't increase it before and you must not decrease it more times than you've increased it. Mike Up_Down_Counter_Version_1.zip
  15. Unfortunately I'm still stuck on this. You've mentioned a self-made up/down counter. I've tried that with the "modifier add value" and "modifier set value" MCUs on a counter object, but can't seem to get reliable results. Most of the times it works, but when many events happen in short time, the counter seems to run wild. Do you have any good up/down counter group for me? Mike
×
×
  • Create New...