Dunbaratu

The KSP API is internally inconsistent with which axis is which sometimes. (Don't get me started on trying to deal with CelestialBody, which can't make up it's damn mind and keeps swapping them depending on what method you're calling). So it's entirely believable that rotational velocity it's messed up this way. It could very well be. So my question is this: I could make it be consistent with ship:raw. I could make the change but then it would be a while before it got released. So, are you the only one who has used it? If its just you, then I think I should change it. If there's a lot of people who used it the broken way then there's backward compatibility problems.

I might be on there later tonight. [ Edit: Those sorts of vague promises are really annoying aren't they? Let me change that to, I WILL be on. I'll make a promise. how about, say, 6:00pm CDT (that's timezone UTC-6, for those not familiar with US timezone namings).] I've always thought that it should in principle be possible to compile some other languages down into the opcodes, but only in a seriously limited way that's missing half the language (the opcodes we currently have can't support user-defined structures, for example, or classes, etc.) I'm glad to see someone is giving it a try. It sort of forces us to kick ourselves and get going on making kerboscript itself better. I'd be curious to see how you're doing local variables like the "var q = 20;". The variable dictionary is currently one large global namespace and that's it. I suppose you could fake it with name mangling, but those solutions tend to create problems for recursion (since there's not *really* a stack of namespaces). To a large extent the reason kerboscript doesn't support a lot of stuff is because what's under the hood in the opcodes doesn't either. I'd be happy to work on adding better stuff to the underlying opcodes so support such things, but lately I've had my head wrapped up in other parts of kOS. kOS is a project that *could* go on forever if you want it to. (There's a zillion things it would be cool to implement, and not enough time to do them all.) For the last few weeks I've been dealing with the terminal and making it less hard-coded and more remote-worthy, and Erendrake has been just waaaay too busy to do much on it himself, so progress has been slow the last few weeks.

I like it.

Glad you like it. I hadn't done any C# before kOS, mostly because I didn't like the prospect of a programming language where whatever Microsoft says just de-facto becomes the standard because they said so. They really didn't have a good track record with that sort of thing before C#. But I had used a lot of other languages a LOT before C# and I have to admit that it's a lot better than I expected it to be. There's still cases where I get annoyed with it, but I do recognize that the things I get annoyed by are not *really* embedded inside the language definition itself. They're the social conventions on top of it, and as such they're not really the language's fault itself. (Things like people's idea of the "right" way to indent things, or when there's 2 equivalent ways to write the same statement, which one is "better", etc.) These aren't built into the language, but they do tend to be built into IDEs and refinement tools like Resharper, and as such the whole community of C# programmers have become trained to take those conventions as gospel. If you're someone with a long history using other languages before C#, some of those conventions don't quite feel right. It would help, but I can imagine it would be an enormously hard thing to create because of how the CPU executes in kOS. So much of what kOS is doing is coming from querying the actual game's API that stepping through your code a line at a time would give drastically different results. (i.e. you have 4 lines of code that query your ships' position, velocity, status, etc. If you step through them one at a time, you either must freeze KSP *itself* as you do so, or you'll end up getting values from different physics tics when debugging which isn't how it behaves when run live.)

If you are referring to the classes like the OneArgsSuffix, TwoArgsSuffix, and so on, they just only went up to 2 because at the time that was all we needed. There's no reason you can't subclass and add a ThreeArgsSuffux, FourArgsSuffix, and so on that follow the same general pattern. If you are trying to create a function that operates the older way (as a direct function call, without being a suffix member) with more args, look up how the function vecdrawargs is implemented. It takes lots of arguments. It's just a matter of popping them from the stack in the reverse order of how they got pushed (last argument first).

Agreed. Noted. By the way I happen to be in the middle of implementing kOS terminal make/model abstraction, to work with the telnet feature (so it detects your terminal type and then loads one of a number of mappers designed to translate from a generic set of made-up control character codes kOS will use internally into /out of the character codes that terminal happens to use). As part of this I could implement the use of the ASCII(7) Character for old-school style "beep"ing when you are working on a telnet terminal.

Maybe you didn't see my update edit to my previous post in time. There is a bug I think in the mod's code. Does your camera vessel have any stages on IT? If not, then I think I know the cause. It's trying to stage on the current vessel you're looking at (the camera vessel) instead of staging its own vessel. The clicking is the result of your camera vessel not having anything to stage. (I think). - - - Updated - - - Patches: SHIP:PATCHES returns a List() of orbit patches the ship is predicted to enter, assuming no maneuvers (assuming it's just going to ignore maneuvers and just go on current momentum only). Nodes: You're correct that there doesn't seem to be a way to access this at the moment. There should be. Make an issue for it on the github. (I'm knee deep in telnet right now and really don't want to switch gears).

Your script has lots of places where it issues a staging command. Could you be more specific about exactly which of them is the one that's just going "click"? (at which point during that script are you switching the camera to your second vessel? ----- [EDIT - never mind. I see the problem. It's a bug and I'll report it. I don't normally do a lot of the actual flight control stuff, so I probably won't be the one to fix it, but you are absolutely correct that it doesn't correctly deal with the case where active vessel differs from the vessel the CPU is currently running on.] I just made an issue for it here: https://github.com/KSP-KOS/KOS/issues/548 If you absolutely need to do this, you could try to fiddle with the PartModules feature and find the "decouple" event on the decoupler parts and activate them one by one, but that would probably be a bit ugly. It's probably better to wait for the official fix if you need this in the generic case.

This is a very important question: Is the craft on which kOS is 'failing' near the craft you are viewing, or is it far away from it? In stock KSP the magic range is about 2.5km (it varies slightly but it's about that much). Some mods can change this range. But regardless of what the range actually is, if the ship is past that range then KSP unloads all its parts and collapses the ship to just a dot in space, ready to reload the dot later. So anyway, if the ship is in that state - where it's just a dot and doesn't fully exist, then there's just not much kOS can do about it. The base game prevents kOS from working in that state. On the other hand, if the ship is closer than that and the script still isn't working, then there might be a bug.

The CPU is part of the physical part that's on the ship. Therefore it has to exist within the loading limit of KSP (2.5m of the camera in default stock without mods that change it). It doesn't have to be the current ship, but it has to be near enough to the current ship to remain fully "loaded". If you leave the scene and move more than 2.5km away from the CPU, it will unload and stop running the script, but keep it nearby and you can switch between two vessels and have both keep running scripts.

This is awesome. But just be warned that the stuff I'm working on at the moment in kOS is specifically terminal related, in such a way that there's a risk it might affect whatever method calls you're making use of. You'll need to be careful to keep track of updates to the development platform of kOS over the next several weeks. Specifically, I was working on making the terminal remote-able through telnet, which in turn means making it resizable and other stuff. In the long run it will be better for rasterpropmonitor stuff, but it may mess up the API a bit. Getting this system in place is one of the main reasons we haven't implemented proper keyboard input to scripts yet - I want to make sure I know how the remotable input works first, and then funnel key reading through that system, however it ends up looking in the end.

One place where this would be very useful is when running the DMP multiplayer mod. It has a chat window for you to talk to the other players, but rather annoyingly it's set up in such a way that the chat window loses keyboard focus whenever the DMP system prints out a system notification to the chat window, which can happen any time a player joins or leaves the server. As these are not events under your own control, that happen "randomly" as far as you can control, it's very annoying the effect this has on the game. You type a sentence with spaces in it like "hello, everybody, come see this neat thing I made" into the chat and partway through typing it a player joins the game making the chat window print the join message, and steal focus away from the typing line. If you don't IMMEDIATELY notice this and stop your finger within about 0.1 seconds as it was on the way down to the next key, you're now controlling the craft, staging it when you hit spacebar, and so on. It's not *quite* the problem the mod was designed for (the inability to lock out certain keys in KSP is different from a mod author *choosing* to steal focus from the chat window on an async event like a player-join), but it's a good workaround for it anyway.

It's a combination of a design decision I made in kOS and the user interface chosen by Infernal Robotics. The problem with opening up any script manipulation of any of the KSPFields in any way the player feels like is that it would have made a bug support nightmare for the other mod makers and I didn't want to do that to them. I was worried that people could complain about other mods being "buggy" when the "bug" they experience is their own fault - the result of them changing a variable the mod is using in a way that would never have been possible under normal operation of that mod. So I went with the following rule: kOS will try as hard as it can to only allow you to make the *same exact* changes to a KSPField you could have made via the user interface, and no others. That means for any slider-based field, if you try setting the value in a kerboscript, the actual value it ends up getting is whatever the nearest possible value is that the slider would have allowed a manual user to set it to. Not only does that mean you can't set it to a value outside the slider's range, but you also can't set it to a value in-between the "detents" that the slider's "resolution" allows. (i.e. if the slider is defined to have a minimum increment of 0.5, between values of 0 and 10, and you try to set it to, say, 8.43, you'll end up setting it to 8.5 instead, just like what would happen if you had tried to set the value using the mouse.) So all that's happening here is that kOS is obeying the rules set by Infernal Robotics's decision as to what to allow via the user interface. If Infernal Robotics has decided that users should never be allowed to change the value above 5, then kOS will honor that decision and obey it. If the makers of IR decide that the limit of 5 is really unnecessary and it should be allowed to be higher, then they can change it by just altering the parameters of the tweakable on that KSPfield, and kOS will automatically follow whatever rules they set. The number is not embedded that deeply in the code. It's at a pretty high level, at the point in the MuMechToggle part module where you define the user interface KSPFields. I can't read the minds of IR devs and know *why* the limits are what they are, but if you convince them to change the limits, that's where they'd be changed.

The only reasons it hasn't been done already is: 1: free time to implement it 2: we're not too happy with RUN program being the way to de-facto do functions, so we really need to make essentially two systems: local to program and local to function. 3: indecision over whether to implement global functions first, then implement user structures, then turn user structure into user classes by adding functions to them to become methods, or to do it the other way around: implement user structures first, then user methods, then say that all user functions must be class methods. It really does need something, though, so that indecision is just an excuse delaying things.

A dot ends the statement. An else cannot exist as a standalone statement - it needs to be a clause hanging off of an if. Therefore don't have a dot after the closing brace of an if when it's followed by an else, because doing so makes the else hang off on its own as the start of a new statement, and it's not allowed to be the start of a new statement. (I'm reacting to your comment in the pastebin code about how it called it an error to have an else if where your second if goes.) I have good news for you, there does already exist an established language in which you could write an autopilot for KSP, and in fact people have done so. The established language is called Csharp. In fact, the proof that this is possible is called mechjeb. The problem with making it work in Lua is at that point all you're *really* be doing is just making an API bridge to a new language, and at that point you may as well make THAT be the project, rather than autopiloting being the point of it. People in fact *have* tried doing that sort of thing before, and it ends up having to be done as some sort of bridge between KSP and software that runs as a separate executable *outside* of KSP. There was a project to turn key KSP API calls into RPC calls so you could hook into them from whatever external program running whatever external language you like. I haven't heard much from it lately - probably because the project is a lot bigger than it looks at first and it's easy for a programmer to lose interest in a project when that happens. The thing that kOS does uniquely is that it tries to run inside the game, using the limitations of the game engine itself, by simulating a virtual machine, running virtual opcodes, that executes a number of virtual machine opcodes per unity update so the programmer making the script is presented with the illusion that it can just run code straight through endlessly without having to make everything it does be a quick hook that exits fast. While it is in *principle* possible to support other languages that way, doing so for any arbitrary language requires making that virtual machine a heck of a lot more complex than it currently is. People mistakenly think, for example, that the reason kerboscript doesn't have local variables is because it's hard to add to the syntax. No. It's easy to add to the syntax. What's hard is making the underlying fake machine language more versatile so there's actually something to compile the kerboscript INTO that will do it.

At one point I do the following up front (before the main loop starts). At this point, myPort has already been selected to be the Part for the port, picked by using SHIP:PARTSDUBBED("whatever") where "whatever" is the name you see me typing into the nametag for the "this" ship (rather than for the "other" ship). // Find axis of rotation, and angle around that axis, to rotate from my ship:facing to my myPort:PORTFACING. set rotAngle to VANG( SHIP:FACING:VECTOR, myPort:PORTFACING:VECTOR ). set rotAxis to VCRS( SHIP:FACING:VECTOR, myPort:PORTFACING:VECTOR ). set rotAxis to rotAxis:NORMALIZED. // Splitting the rotAxis into its 3 component parts, in a reference frame that is oriented // to match my ship:facing: set rotAxisX to VDOT( rotAxis, SHIP:FACING:STARVECTOR ). set rotAxisY to VDOT( rotAxis, SHIP:FACING:TOPVECTOR ). set rotAxisZ to VDOT( rotAxis, SHIP:FACING:FOREVECTOR ). // Then, further down, constantly being updated in my loop, I do this to get the information about the target port: set otherPortRot to otherPort:PORTFACING. set otherPortInverseRot to ANGLEAXIS(180,otherPortRot:TOPVECTOR)*otherPort:PORTFACING. Then further down, I use that to work out what direction I should be steering my nose at to make my port orient with the other port: set otherPortInverseRotAxis to otherPortInverseRot*V( rotAxisX, rotAxisY, rotAxisZ ). set myPortRotRelToOther to ANGLEAXIS(-rotAngle,otherPortInverseRotAxis)*otherPortInverseRot. At this point, you should be able to LOCK STEERING TO myPortRotRelToOther.

This is true and how I worked around it in my script from the video was this: I don't do a "control from" my docking port. Instead I calculate which rotation Direction goes from ship's control orientation to my docking port's orientation. Once I know that rotational offset, I can use it to point my nose rotated the opposite way to that without using "control from here". (In other words, if my docking port is rotated 45 degrees yawed from my control orientation, then when I discover the orientation I want my docking port in, I should point my nose -45 degrees yawed from that. The new Direction suffixes and constructors make this possible.) - - - Updated - - - I assume KAS is a mod of some sort? If so, then the answer is most likely yes, because kOS now allows you to generically access many of the things other mods enable you to do. Basically, if it appears on the rightclick menu of a part, or is a thing you're allowed to assign into an action group, then kOS should be able to access it in theory. But you have to jump through a few hoops to do it.. Start here for reading how: http://ksp-kos.github.io/KOS_DOC/general/parts_and_partmodules.html Note, there's a bug in those docs I didn't fix yet: At one point the docs say this: IF somevessel:PARTSDUBBED("my favorite engine"):LENGTH == 0 { PRINT "There is no part named 'my favorite engine'.". }. And he double-equals "==" is wrong for kerboscript syntax. It should be a single-equals "=",

In principle it should be possible to lock steering, because with a lookat and a lookup vector (the blue arrows in the second half of that video), you can construct a Direction and LOCK STEERING to that. My only reason for not doing that was that I was *also* setting myself the task of testing out the raw controls and wanted to get them working, so I do everything with SHIP:CONTROL. I do think that LOCK STEERING for the rotation, combined with raw controls for the translation, should be a viable tactic.\ Incidentally, before I added LOOKDIRUP(v1,v2) as a function, it wouldn't have been a viable tactic because you could only have controlled the aim of the central axis of your ship with LOCK STEERING, and in order to put your own ship's offcentered port where you want it, you need to put the roll just how you want it too. That may have also influenced my decision. I was writing the script *while* adding the new Direction methods, and LOOKDIRUP wasn't there yet when I started. I added it largely because of the deficiency of the system I found while trying out this task.

I realize that what I posted was a giant wall of text that it was easy to miss stuff in, but that actually is what I was suggesting doing. (The bit where it says: The challenge starts with a sandbox-mode saved game, made available for public download, in which there exists a space station in orbit around Kerbin.) (Later on I mentioned that if you want percentage of cost returned back (for SSTOs) to be part of the challenge scoring it would have to be a career-mode saved game instead of sandbox, just because KSP won't show you the amount of recovery refund in sandbox mode.) That's sort of why I split it into two parts. I'm unsure whether or not I *should* show the script yet if there might be a contest going on, and I'm still waffling on that.

I'd prefer just giving people direct control over all the parts of screenmessage - the position, the delay, etc. Maybe as a function: hudtext( "Hello World", "top", 5). // top position, for 5 seconds. - - - Updated - - - Here's a demo of some docking maneuvering:

I was thinking that kOS has hit a new maturity point where it's probably worth it to have another Challenge contest like the ancient one from over a year ago. That contest really helped spur kOS on because it made people try areas the mod wasn't so good at, which helped explore the edges of what it could do, and helped figure out what things would be helpful to add to it. I had a lot of fun back then being a participant in it, although some things were a lot harder than they needed to be. Things have gotten a lot more mature and I think it's time for a new challenge contest. I had an idea myself for a nice one but I don't want to post it for the following reasons: 1: The challenge forum has the rule that you shouldn't make a contest for which you haven't posted a proof of your own ability to succeed at it (i.e. your own entry into your own contest, so to speak). This rule was established because there had been a few cases of people being jerks posting contests they knew cannot be done, designed to trick people into wasting their time trying. They would often say "oh trust me it can be done, I've done it, but I won't show you my solution until you start posting yours", when they know it can't actually be done. The purpose behind the requirement was to prove a minimal entry is possible. It doesn't have to be your best entry, and you can re-enter a second, better scoring entry later on. It's just meant as the proof of concept to prove you're not lying about the challenge being possible.) 2: I decided that I should really recuse myself from participating in any challenge contests about kOS after I became more heavily involved in helping develop it. I've got too much ability to change the mod to make it into what I need it to be ("Oh look the mod is missing a feature I'd need to do this task - so I'll go and add it in and get that feature into the next release, and get the release out in time for my contest entry..."). I've also got too much "inside information", as in "Oh, this feature's not documented that well, but no worries, I'm the one who wrote it, so I know how it works without the docs." I've also got more "lead time' than others do. I can start writing scripts using new features before the new features are publicly mentioned. It's the combo of #1 and #2 that I think mean I can't really lead a Challenge Contest myself. To lead the contest I need to show my own entry into it. But I don't think I should be entering myself into a challenge. That being said, this is the idea I had for a potential contest: kOS Space Station Crew Exchange Challenge The challenge starts with a sandbox-mode saved game, made available for public download, in which there exists a space station in orbit around Kerbin. The space station has the following things on it: A port with nametag="Easy Port" - a docking port along the station's main central axis, at one end, clear of obstructions. A port with nametag="Medium Port" - a docking port located not along the station's main axis, at a weird diagonal angle, and aligned askew from its center of mass. A port with nametag="Hard Port" - a docking port similar to "Medium Port", but not only is it at a weird angle and not central, it's located in a dangerous way with breakable solar panel obstacles around, making it likely that you'll break the solar panels if you just try to dock straight at the port clumsily. Crew onboard. You're allowed to build whatever docking ship you like to dock to the station, but depending on the design of its docking port, it may be worth more or less points. It should have crew space for at least 1 crew. It can have more but it's actually detrimental to your score to do so, as you'll be scored based on least monoprop used, and larger ships are going to use more - you're best to go with just 1 crew capacity. The challenge is to start from that saved game and attempt to do the following: 1. Launch your craft from KSC to orbit. must be automated by script 2. Rendezvous your craft with the station. must be automated by script 3. Dock your craft to the station without breaking anything (like a solar panel). must be automated by script 4. Exchange 1 crew member between the craft and the station - move one crew out of the craft and one crew into it. You are allowed to do this step manually with the stock crew transfer mouse interface. 5. Undock your craft from from the station. You are allowed to do this step manually with the docking port's right mouse button menu 7. Move your craft away from the station safely without breaking anything (like a solar panel). must be automated by script 8. Return the crew member to Kerbin intact, trying to land close to the KSC if you can. must be automated by script You are allowed to use the interactive terminal for file and run commands: COPY, SWITCH TO, RUN, etc, at any point during the mission, and doing so will not count as "doing things manually" (thus if you can't fit the entire sequence of scripts on the ship at once, that's fine - you can swap files in and out.). THIS mission is not intended to be a signal-delay challenge mission where you can't type commands. It all takes place within near-Kerbin orbit. Things that could be used as criteria to affect your score (although I haven't really thought through which of these are more important, and how they should balance against each other, or which of them should be dropped. A good challenge should really only contain about 4-5 scoring criteria. Too much more and it gets messy to track): more points for docking to the harder ports on the station. more points for using a harder docking port on your own ship (one not just easily aimed out the nose of your ship, but one that you have to calculate directions from weirdly, like the harder ones on the station described above). less points the more monopropellant fuel was consumed. Docking with mechjeb can be monopropellant-hungry, and I'd like to think a specialized kOS script can do it better. less points the more torque power the docking craft had (more points for doing it all on RCS). (Yes I know there's a bug about using ships that don't have torque, but there's also a supposed fix donated by github user soulsource that should come out the next time there's a release). less points for more time elapsed (on the gameworld's clock, not the user's time) between start of the savegame's timestamp to the timestamp of the final landing. This will effectively reward people for managing to get a good rendezvous quickly. More points the closer to KSC the landing site was. Reusability ratio: Compare the recovery cost of the amount of your craft that landed on return to the initial cost of it at launch. Better reusability ratios mean better scores. (The purpose of adding this scoring criterion would be to give a boost to the scores of people who managed to do it with an SSTO. SSTO's present harder scripting challenges and should be rewarded for it. This would do so because they're landing the whole ship again and only payed for the fuel.)) (For this to work you probably need the initial save game to be a career mode game so it can calculate funds. I can show you how to set up bogus data to make a career mode game have lots of funds and upgraded buildings. The only reason for making it career-mode would be to turn on KSP's calculation of ship cost so you can perform this scoring. Again, I don't recommend all the above be used, but they're a clue as to what could go into the scoring criteria. Is anyone willing to set up a thing like this, and take the lead on it in the forum? (Or, to make it all your own idea, to counterpropose a different challenge). I just like the idea of there being a kOS challenge in the forums. It's been a while and I'm thinking about it. I'm thinking about docking because that's the most recent scripting I was working on.

However, the system for remembering the state of a variable in a saved game and bringing it back (or even bringing it back after leaving the scene and coming back to it), has some problems right now. The original system is ancient and was designed for when it only had to deal with integers, floats, and strings. A lot of the newer data types don't "serialize" properly into the savegame file. At the moment, you need to either keep the entire run contained in one 'scene', or make it so that nothing it remembers is important when leaving the scene, so it can re-run code again from scratch and recalculate everything when you return to the scene. - - - Updated - - - If you thought all variables were global to the *entire game*, then you misunderstand what's happening. They're only global in the sense that if you run a script on the vessel, and then that script in turn contains a command to run another script nested inside itself, the second script will be working in the same variable namespace as the first script was. It does not mean that if vessel A is running a program that its variables will be seen by vessel B. THAT is kept separate. There is one variable namespace per Vessel. Actually, it's even more separate than that. There's one variable namespace per CPU on the vessel. If you attach two CX-4151 Comptronix parts to the same vessel, each one will have its own separate namespace.

There's a bandwidth issue if you try to make them too big. An animated GIF requires a lot more bytes be sent to the browser than a still one, and that rises faster the bigger the dimensions of the GIF. So most of the time an animated gif must also be a tiny gif, else you're starting to bog things down for the people on slower connections like mobile phones.

You know perfectly well that's false. That next post cannot be just "anywhere" like you're claiming. It cannot, in fact, even BE post #2 at all. The soonest it can be is post #3. If you make it post #2, there will be no post #2 as post #2 will get appended to post #1. The problem isn't "anywhere", it's "anywhen". Right now, the follow-up post can't exist until a point in time after someone else happens to post. If that's true, then it's the only good reason for not fixing it. The inabilty to do what I suggested (make it so the merging rule doesn't apply until after post #2) would be a perfectly good reason. Pretending I suggested something other than what I did, by pretending it would allow five posts in a row, is just a bogus strawman argument. What I said wouldn't allow five posts in a row. If what I said isn't possible, and the only choices are between "always allow consecutive posts everywhere" versus "allow no consecutive posts anywhere, not even at post #1" (neither one of which is what I suggested), and it's impossible to pick anything other than those two options, then the way things are is the lesser of two evils. It's not optimal like you're pretending it is, but it's the best you can do. Because of what the OP said. He'd like to get it out there without waiting around for someone else to happen to reply, which might still be a few hours away from happening and he might not even be on the computer anymore by then. "this is my description of the THREAD ITSELF" and "this is my first reply to that description" are two entirely distinct concepts. For example in a challenge thread, if you'd like to give a challenge, and then also enter your own example into it as one of the entries, then that entry should be an "equal citizen" to the other entries other people are making, and not given special status by being part of the initial description of the challenge itself (which is what the first post should be dedicated to).

It may be true to say it rubs the moderators the wrong way, but it's false to claim there's no need to do it. The OP gave exactly the precise case where there is such a need. When first STARTING a mod thread, the first post of that mod thread has a special meaning that is quite *different* from a normal comment post. Can't the rule just be enforced only AFTER the second post? In other words post 1 and post 2 remain distinct, but consecutive posts occurring in the thread after that get auto-merged. That would avoid the overspamming of a thread because it can't be done except at the start of a brand new thread. The initial staring post of a thread is quite different from the other ones after it. For one thing, it sets the title of the thread itself, and the 'flair' in the title.