madlemur

"shunned"... "demonized"... Seems incongruous to use those words while asking others not to incite drama. From all I can tell, nobody has anything against 64-bit users (except perhaps the folks at Unity), as 64-bit users. The problem comes into play because of the confluence of Unity-based bugs in the 64 bit version (see previous parenthetical), Squad's release of said 64-bit version (despite the "hey, this is experimental" tag), and bog standard customer support issues (people en-masse are knuckle-dragging, mouth-breathing troglodytes who are lucky they can feed themselves). That's the source of the problem. The accelerants are the dust-up around an arrogant and poorly handled flaunting of the licenses (see also the version checker dust-up), and the apparent forgetfulness of some users, who think that modders can/should/will continue to volunteer the herculean effort to make and support these fine add-ons when they have to deal with the fall-out from the original problem (buggy 64-bit app) despite their own efforts to shield themselves from it.

Hey, it's all about gaming journalism integrity licensing triviata...

Heh... That's what I get for writing code off the cuff when I'm otherwise hip deep in syntactically different code (C# and PHP)... Good catches, and good fixes. Let me know how it works!

Quite right. I did a quick copy and paste to add throttle control via action groups, and I must have scanned over that too quickly. Sadly, there's no good way to set an arbitrary value, yet. Who knows what black magic Steven Mading and erendrake are brewing up...

What I'm working on right now is a VT100/VT220-ish virtual terminal emulator that can be used in a GUI window (like the current console), an RPM prop (specifically an MFD page), or really anything. It's slow going at the moment, as I'm learning C#, Unity, and VT100/VT220... Oh, and most of my coding time is stolen cycles at work. Bonus features: ANSI art and "native" support for eventual ssh/telnet-ish connections.

I thought I had posted this, but it must have gotten eaten... Not sure if this will work better for you, but the nested UNTIL loops concerned me. LOCK VS to verticalspeed. SET THT TO 0.66. SET U TO 0.16. // The pitch up value. SET D TO -0.075. // The pitch down value. clearscreen. // Trim up when losing altitude WHEN VS < 0 { SET SHIP:CONTROL:PITCH TO U. PRESERVE. }. // Trim down when gaining altitude WHEN VS > 0 { SET SHIP:CONTROL:PITCH TO D. PRESERVE. }. // Action group 5: reduce effect of up trim ON AG5 { SET U TO U - 0.02. IF U < 0 THEN SET U TO 0. PRESERVE. }. // Action group 6: increase the effect of up trim ON AG6 { SET U TO U + 0.02. IF U > 1 THEN SET U TO 1. PRESERVE. }. // Action group 7: increase the effect of down trim ON AG7 { SET D TO D - 0.02. IF D < -1 THEN SET D = -1. PRESERVE. }. // Action group 8: reduce the effect of down trim ON AG8 { SET D TO D + 0.02. IF D > 0 THEN SET D = 0. PRESERVE. }. // Action group 9: reduce throttle ON AG9 { SET THT TO THT - 0.02. IF THT > 0 THEN SET THT = 0. PRESERVE. }. // Action group 10: increase throttle ON AG0 { SET THT TO THT + 0.02. IF THT > 1 THEN SET THT = 1. PRESERVE. }. UNTIL ALT:RADAR < 0 { SET SHIP:CONTROL:MAINTHROTTLE TO THT. PRINT "<Altitude Holder v0.1a>" AT (15,0). PRINT "Radar Altitude= " + ALT:RADAR AT (0,3). PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5). PRINT "Vertical Speed= " + VS AT (0,7). PRINT "Pitch Up Setting= " + U + " Pitch Down Setting= " + D AT (0,9). PRINT "Current Throttle= " + THT AT (0,11). PRINT "Program made by GabeTeuton with tweaks by madlemur" AT (20,30). WAIT 0.001. }. Changelog: Got rid of nested UNTIL loops. Added ability to fine tune U and D using action groups 5-8. Added ability to fine tune throttle using action groups 9 and 10. Added WAIT statement to UNTIL loop so that information is only updated once per update. Notes: There is no check for VS == 0, since it's unlikely that will ever be the case. The system will always be fluctuating. The best that could be done is to reduce the magnitudes of U and D until the fluctuations are minuscule.

@Cairan: Have you seen kOSis?

@GabeTeuton: Set the WHEN ... THEN ... event(s) outside the UNTIL ... { } loop. // declare o. // Not needed, since you're setting them below. // declare p. // DECLARE is only needed when you're passing the values into the script SET p TO 0.01. SET o TO 0. WHEN verticalspeed <-1 THEN { SET o TO o + p. PRESERVE. }. WHEN verticalspeed > 1 THEN { SET o TO o - p. PRESERVE. }. UNTIL ALT:RADAR < 0 { PRINT "this is the current pitch= " + o AT (0,1). PRINT "this is the current vertical speed= " + verticalspeed AT (0,2). SET SHIP:CONTROL:PITCH TO o. WAIT 0.001. // No need to loop until the next update }. WAIT UNTIL false. This way, you're setting up the trigger event(s) to update the trim, then going into your loop to print out the status and keep the controls at current trim.

Use similar logics and vector maths to compare and compute the "up" vector of your vessel and the "up" vector of the body your vessel is orbiting.

... Loop through resources, looking for the liquid fuel ... LOCK LqdFuel TO RES:AMOUNT. PRINT AT (0,0) "Liquid fuel:". WHILE 1 { PRINT AT (13, 0) LqdFuel. WAIT. }. Note that the WHILE loop will be the only thing running, except for any UNTIL events. OK for maintaining the display, just be aware nothing else is happening... edit: Also, I may have the PRINT AT syntax wrong... Check the docs...

You have a bare AMOUNT. Change it to RES:AMOUNT and you should be good.

Oh... Well, then... I'll go back to reading up on VT100/VT220 specs...

How are you setting it in-game? Unless there's a configuration screen I haven't seen, you have to edit the config.xml file by hand.

GameData/kOS/Plugins/PluginData/kOS/config.xml: set EnableRT2Integration to 1

Did you enable RT support in kOS? Also, manually kill your throttle before starting your program. Otherwise, your satellites will wander off as soon so the program ends.

Bah! Actually, you can get the actual heading of the ship, determine the pitch from that, and fine tune based on that information. The SHIP:CONTROL information is just the control settings, which will be relative (-1 to 1). I have to run, so I don't have time to look it up in the docs, but the information is there, and relatively easy to get.

Fly? It fell, with style...

Yes, the need to handle multiple SCS parts is in my head already... Possibly even a way to interact at a basic level with kOS parts that don't have a processor (you are planning on storage-only parts, aren't you?). Now, on to the fun bits... In order to decouple the kOSProcessor from the screen buffer in that way, you'll (we'll?) need to create a terminal class that supports whatever control code set is chosen (I'm thinking "whatever's easiest") as an interface for the GUI terminal, and I'll have to do the same for the RPM screens. Maybe that's where I should start focusing my efforts. On developing/finding a terminal emulator for some control set...

Is there any way to easily hook into the screen buffer, or will I have to create a new class to handle multiple buffers? Specifically, I'm thinking of just displaying the screen, but I don't want to lock out (or be locked out by) the default terminal window. And since there's only one shared.Screen... I suppose a wrapper class that taps into the output would be easy enough. I think...

OK, in a likely futile attempt to spur myself into action, I'm going to try to get an RPM integration done. Maybe just a read-only display for now, but we'll see what can be done. Possibly a custom-made volume navigator to manage and run scripts. And it'll have to be able to switch from CPU to CPU, too... Hrmmm... That means I need to enumerate all the kOS CPUs and volumes (separately, since there's at least one volume that has no CPU, and mayhap we'll soon have a decoupling of CPUs and volumes). I'll be thrilled just to get a single-CPU vessel to display anything on an RPM screen...

This was taken from a career mode save, but it was the same error that was seen in sandbox as well. I've seen the same thing since I started using Snacks early on, but I've always had bigger issues (and much smaller framerates) to deal with... I've seen in it in career and sandbox games. I also see that it's a log message, and not a warning or error... But still, that's an ominous message if it's not indicative of something wrong.

On my phone, so I don't have a link handy, but I had some preliminary good results with LoD, a mod for DirectX that dynamically loads and unloads hi res textures. I need to build up a new install. I played around with the DDS loader mod, and I think I mangled a texture or three...

Open @Default.cfg. Set scaling to 1. That should do it, I think. Sorry, was thinking Texture Replacer... In config.cfg, set scale=1 (around line 50).

I have encountered normal maps with nrm, norm, normal, and even no suffix at all. It's something of a pain in the ass...

I'm guessing paint.net pads the images out to a power of four, which would increase the file size without deforming the textures. I've found on more than one occasion that the button icons I converted via the script didn't show up, so I'd load it up in paint.net, and save it back out as DXT1. That seems to work (although it could just be paint.net saving). I also tweaked the script a bit to include converting mbm files to pngs, then converting the textures. I also treat *NRM, *nm, *norm, and *normal filenames as normal maps. Need to look for a paint.net command line reference...