TriggerAu

June 28, 2018

On 6/26/2018 at 8:42 AM, Gordon Dry said:

@TriggerAu:

Thanks, working with LGG on it

May 14, 2018

Sound slike the handling of a default name isnt quite right - lemme see if I can tune that.

On 5/10/2018 at 11:59 PM, 81ninja said:

I don't see a reason why it couldn't be done in flight, but I'm already looking forward for a mod that adds that feature also to the currently active vessel.

Done that one for ya already

Quote
If you change this setting in settings.cfg to be true then the configure vessel naming option will show for parts configured when in flight mode
SHOW_VESSEL_NAMING_IN_FLIGHT = True

May 6, 2018

On 5/4/2018 at 4:05 PM, jclovis3 said:

If a node that checks if you are low on fuel is a "Catch All" node that is also allowed to repeat, how does it progress to the next node when the condition that triggered it would continue to persist. For instance, say the next node is to tell you that you are low on fuel and then the 3rd to fill your tank with liquid fuel. As soon as control jumps to the message, you are still low on fuel and it should jump to the fuel check as a Catch All again. How does it ever move on?

Is there any way we can suspend jumping to any catch all nodes until another specified node is reached? Can't they make a "continue" node to say prevent all "catch all" nodes from triggering until this "continue" node is reached so we can guarantee the execution of all the nodes after it?

if you have a catch all which allows repeats and uses a non-event driven test like fuel level - it will get in a loop yeah, it cant progress. in places where Ive needed stuff like that I dont use a catch all, but have multiple nodes conncted to the fuel level one - but that may not suit every occasion.

We dont have a "disable/enable" node currently - but thats a pretty cool idea

May 6, 2018

13 hours ago, klapstoelpiloot said:

This is a nice system and sounds like it is well designed.

But could it possibly be that it doesn't play nice with vessels made before this system was implemented?

I just docked a new vessel (with these naming options set, priority of 5) with an old vessel (station which was built before this was implemented) and it changed the name of the station. Later, after undocking, I noticed the name on the part of the station was actually changed! Thats bad. Possibly a bug in there?

Sounds like a bug, or a use case not thought of - If you can log a bug report with deets, save, etc and poke me back with the number that would be much appreciated

April 26, 2018

On 4/22/2018 at 3:38 AM, cineboxandrew said:

Is that a new thing? I swear I've controlled vehicles marked as debris but which had probe cores in the past

It wasnt when I looked at the code, but I had the same feeling too when I did it to myself - maybe it only when you start from debris - made for a few funny moments for me though

April 8, 2018

11 hours ago, Wallygator said:

@TriggerAu

Now that I've poked around a bit in the mission builder, I'm confused... because there is a clear horizontal schema between nodes when a mission is being built... but this transitions into a vertical and bracketed schema when one is viewing/trying to execute a mission.

I personally (others might disagree) would naturally expect a common visual model that is shared between the two interfaces - albeit the execution view might be much more simplified vs the builder view.

Was there a specific requirement that dictated this "90 degree flipping" or even a specific need for a "completely different representation" of the mission?

To me, this is a confusing UX. Sorry if I'm the only one bringing this up (seems like I am - OK not sorry )

Thoughts?

I guess that is probably related to the basis for the design/architecture. The "Apps" in KSP all work with vertical lists, and that is a better UX for a long list of items/checklist - thus the app/objective layouts consistent with the other apps

The Builder is based loosely on the R&D scene and other tools of a similar nature which have that node and line flow. You can make a mission flow down the canvas as well as across, but perhaps you mean how the pins are on the left/right of the node.. It might be interesting to see what it might look like to remove the pins so the lines flow in any direction directly, or also build out an graphical execution view but it wasnt in scope at the time. Will add some feedback to our list and see if it makes an impression

March 24, 2018

Always looking for improvements @Wallygator . If you don't mind could you give me an example for what you mean by a simplified horizontal path, would be good to see an alternative visualization idea - obviously cant promise well change it, but be good to see as we dont want to stick to a specific method just because thats what came out

March 24, 2018

On 3/24/2018 at 7:56 AM, linuxgurugamer said:

It seems to be working the way PDPN works, which btw, Im not going to continue since this totally replaced the functionality of it

Oh my goodness! in all honesty I didn't know that was a mod already. Apologies mate or I would have at a minimum PMed you, or more likely asked questions about any good/bad things you've seen from that for incorporation. Didn't mean to replace a mod, as such, without speaking to anyone :faceinhands:

6 hours ago, Catullus said:

That's fantastic, but why no satellite category?

Its an extension to the existing types where there are 3 satellite categories - probe, relay and station - so we didn't add any new types

March 24, 2018

3 hours ago, basic.syntax said:

Thank you!

As you add more Nodes, in/out pin paths overlap and tracing the flow gets harder. I would like to see some kind of highlighting for the node connection lines of the selected node. Like the animated arrows used on fuel flow lines, for example. Overlay some kind of animation ("dancing ants") on the lines, so that complex mission designers can clearly see what feeds into and goes out from the selected node. And/Or - consider adding a cross-hatch pattern to node borders of nodes connected to the selected node, with one style used for nodes-as-input, and (perhaps) another pattern for nodes-as-output. (Patterns are helpful for users with color perception issues.)

Thats a cool visualization, will add that to the feedback list we have if thats cool

March 23, 2018

On 3/22/2018 at 8:57 AM, TriggerAu said:

yep, but you could also do it without the always true docked node.

As it only tests when the parent node is activated it would reach the true node, test the docked node and then progress down that path if its true, else it will follow the out connector from the parent node.

Ill draw it up in game tonight when Im home

Heres what it would look like for testing LF >100 else

17 hours ago, Steven Mading said:

Wait, if it's truly an FSM with only one active node at a time, doesn't that mean that activating a "Catch All Node" should break the program and prevent it from continuing, because it can't fork the path into two simultaneously active nodes? But the main pathway does seem to resume afterward. How? Let's say you have a catch-all-node, that starts a chain of 2 other nodes, and then the path just stops without any mission end node or any explicit path linking back to the main program.

It appears to return back to the main pathway after finishing that chain of 2 nodes, continuing from right where it got interrupted, as if it was returning from a subroutine. How does it remember where to go back to? Wouldn't a true FSM forget that? If the Catch-all-node behaves like a subroutine that returns to where it got called from, that wasn't made clear by the UI text explaining things.

The active node wont come back to the other "path" from a catch all unless there is a connection. You can think of a "catch all" node as a Node that has connections from every other node in the mission (except for itself and the spawn nodes docked to the start node)

If you have a plan like this and destroy the vessel before getting to orbit then the player will get the CRASHED dialog but the mission will be stuck there

hint if you run the validator it will tell you that the node has no end setting and no output!

11 hours ago, Wallygator said:

@TriggerAu ... It would have been nice to allow a player to execute a mission normally and have it concurrently "recorded" as a mission file for post editing.

This might have required the player to indicate that the mission was to be recorded prior to the start of the mission - a small price to pay/play.

Can you consider this? Or at least reflect on the complexities considering your current mission architecture schema?

NOTE: I have not yet dived into the mission editing environment, so if this is already available then please either insult me or ignore me - either one is acceptable.

Is a cool idea, and one that I do recall being mentioned in the early days, but we went down the road of visual programming/flow chart after plenty of discussions.

The complexities (to use your term ) that I recall from the discussions about that approach were in two parts. The first being that you need to set up the capture of objectives and details for the mission - lets say landing on the Mun at a certain spot - so the creator would need to complete the mission and interact with a recorder along the way that garbs various configurable values. Using the landing point as a specific example if they then didn't land exactly where they wanted to set the target then we'd also need an editing interface to adjust the values after the recording. In essence the editing interface is the Mission Builder, and we added enough (we think) visualization in there to be able to.

The second being the time taken and process - if you have a really complex mission you would probably plan that out somewhere to then play it to record. Which is effectively what you can do with the Mission Builder. You plan it out using objectives and then use the Test function to fly the mission. If you get half way through and want to tweak it you jump back from test mode to the builder make some tweaks and then resume the mission testing from a checkpoint (or form the start if you want) to save the creator time.

Not saying its not an idea we wouldn't ever come back to (cause it is pretty cool) or that a modder couldn't make a recorder either (don't quote me on that one though as that wasnt a modding idea I had considered till I wrote this sentence!)

March 21, 2018

2 hours ago, Steven Mading said:

Explaining how the docked nodes work makes it possible to form an "else", I think, which is something I've been wanting. (As in "invert whatever this other test is" without having to explicitly re-write a new test that happens to be the opposing condition.)

Would this work: I make an "always true" node that's the header, with two nodes docked underneath it - the first one is the "if" test node (altitude test, location test, whatever), and the second one is another "always true" node. Thus it only falls through to the second node, the"always true" node, if the first node fails. That "always true" node becomes the "else".

yep, but you could also do it without the always true docked node.

As it only tests when the parent node is activated it would reach the true node, test the docked node and then progress down that path if its true, else it will follow the out connector from the parent node.

Ill draw it up in game tonight when Im home

March 21, 2018

no probs, hope it was a good read too

March 13, 2018

8 hours ago, Zhetaan said:

It's nice to see you writing these again.

Just so I'm completely clear: priority number one is at the bottom of the list? That's what I'm taking from this, though I confess to admit it will take a bit for me to adjust that in my mind.

Correct its like the fuel priority numbers - the higher the number the higher the priority

March 11, 2018

On 3/10/2018 at 6:09 AM, mostlydave said:

How about an update on the EULA or the lack of an opt out of KSP sending information in 1.4?

Sorry mate, not something I feel qualified to comment on, but anything about the naming system and game stuff Ill have a crack at

On 3/11/2018 at 8:22 AM, LordFerret said:

All fine and well that the 'vehicle' naming scheme carries, but do the staging orders for each 'vehicle' carry as well?

No just a system for the naming at this point. the staging stuff did actually come up in the earlier discussions I mentioned, but it was in that "substantial changes to the base structures" idea and we parked it at the time

March 9, 2018

15 minutes ago, 5thHorseman said:

Is it weird that this it's my single favorite thing in 1.4? It barely edges out the new decoupler models.

On of my favorites too, but I'm a little biased

June 13, 2017

18 hours ago, 7clem said:

Though not quite about the WEIGHING of fonts this comment does mention fonts.

Please Squad devs,

1) level one : Make sure KSP font matche size with the fallback font (one that has all glyphs present) used whenever the glyph you haven't designed appears in translations .

2) level max : make sure no glyph is missing for every font you use.

French uses : é è à ë ä ê â ç ï ï ö ô ù and É È À Ç Ï Î Ö Ô Ë Ê œ Œ And the game menu looked like excrements in 1.2 in a straight forward translation due to font problems. It was a problem in KSP1.2 patched to French.

7clem, involved in translating KSP to French.

From memory the fonts in the project are all scaled the same value, but will check it for you - have you got a good example I can use to reproduce?

For 2) all the glyphs used in the the languages that are translated should be there yes, as we haven't done french yet that's obviously going to have some gaps in a stock game, but if you wanting to you could look at the modding information about how to add your own font . If/When french is added Im sure all the glyphs wil be available

April 18, 2017

23 hours ago, Sereneti said:

about localisation:

simplest methode: put the description/the dialoges in an "external" .txt file.

that replacing/overwriting the orginal files are simple . (a simple "localisation_XX" folder in the gamedata folder) .

i think a lot of people would localise the game in their own language.

and: do you use the fonts "in the game" or do you use the fonts from the OS? - if you use your own fonts, why not in an external file?

If you download the prerelease you can see the current process in action - they are KSP Fonts and cfg files in short, and once we get all the buttons nailed down we have an article to publish on modding and adding your own languages for just such purposes

March 13, 2017

2 hours ago, Rory Yammomoto said:

are you going to shift all text to the new font engine? the small text on Linux is barely readable.

Everything gets brought across to the new fonts yes

February 15, 2017

Names are an interesting one for sure, and to me the mix of character sets looks weird. That said English is my only language (and at that its probably second to programming languages :wink: ) so I don't really have any experience/authority to draw on for where the use of Latin characters inis acceptable the mix is acceptable.

With the staff and volunteers that are working on the translations things like this are being actively discussed, as well as things like the best word for "Snacks" and other "Names" in KSP Land.

Super glad that people are liking the content and the style

1 hour ago, nightingale said:

...

You should probably cross-post to the daily Kerbal (and reddit?), I suspect most forum goers don't notice the articles on the sidebar.

Is a great point, I'll look at that

February 14, 2017

5 hours ago, Randox said:

Always enjoy reading behind the scenes stuff, even on topics like fonts

I do have a question though. I notice in the example that you left the Kerbal's name written in the Latin Alphabet, and was wondering why you left it that way?

...

You mean fonts are not the most exciting thing you have ever heard of... I'm shocked!

Is a good question on the name, and very observant , with a very simple answer. The name generation part has not yet been swapped in for the localized names in the UI components in that dialog. The idea is to make it as immersive as possible and where there are things that don't make sense the guys doing that work are interacting with the people (and the community) with local knowledge to get it sorted

July 16, 2016

10 hours ago, bewing said:

I have been going through a few ancient bug reports over the last months and marking some resolved -- marking others as "still present in 1.1.3" in the comments. The problem is that some of them are very system specific. Graphics effects that only appear on Macs and Linux are things I can't test or verify. If you want to spend some bughunting time efficiently, then you should concentrate on the ones that only you have the ability to test.

Many of the bug reports are marked as "resolved" in the comments by the authors of the bug reports (because they did not have the ability to close the issue themselves at that time). If you guys would just cull those ones out in a preliminary sweep, I think that would reduce the count a lot.

One suggestion that I would make is that the voting system has only been implemented recently. That means that any bug that has votes is one that still exists. That would give us an easy way of marking bugs that are still around. If you would just make some explicit policy about votes. Either votes mark bugs that still exist, or votes add urgency to a particular bug report. And then Anquietas and I can go mark a lot of stuff.

In some sense, we need some feedback, though, on which bug reports have even been looked at. As said above, some of them have been sitting there for 4 years, and don't have a single comment by a dev. If they have been looked into, but seem to be too hard to fix at the moment -- even knowing that is better than silence.

Some good stuff in there @bewing. For some extra detail from me (now that its the weekend and I got some time):

I've drafted up some detailed instructions that will be shared with the test teams later today to check I haven't messed up entirely .;
We'll use a status change to indicate whats still there or whats not.
Do want to use the votes system more effectively, but its visibility is not as good as it should be (its actually been there for a long time, but its not obvious enough) - you have to add the column and right click to vote on the list in the public tracker - I think its a permissions thing and is on the list to look at.
I do want to try and do another pass through the tracker to reduce noise as well before we kick into gear and its a great reminder

Thanks

July 13, 2016

10 minutes ago, John FX said:

When it is time please make some form of announcement (like this one) on the front page, maybe the devnotes as well, I`d hate to miss this.

Will be in the support forum and all the places we usually hang out for sure

July 11, 2016

Am writing the detailed instructions and testing in redmine, there will be a "Needs Clarification" status (or similar) and will have detailed instructions when its time to go

We wanted to share the plans, before we started making changes

July 10, 2016

3 hours ago, John FX said:

So is this something we should be doing now or is this something planned for the future and if so, how do we find out it is active?

We'll kick it off soon - just making sure all the permissions are right and getting a go date lined up. There will be more specifics when we hit the go button.

1 hour ago, WildLynx said:

Commenting on bug on bugtracker, that bug is still here and bad - is it enough to stop it being swiped under carpet?

Would be super helpful if you could "flag" it when we kick off this process, but items that are recently updated I'll be trying to check as well

July 10, 2016

40 minutes ago, Streetwind said:

@TriggerAu - a part of why the bugtracker backlog escalated to this point is probably because issues don't always get closed when they should be. For example, I submitted an issue in 1.1.2 which seemingly got fixed in 1.1.3. At least, the changelog reported the fix with pretty much the exact same wording I used to name my bug report. However, on the tracker, the report itself was never touched - it wasn't marked as being acknowledged or worked on, and it wasn't marked as complete and closed either. So it continues sitting there in the "new" status to this day.

I will now go and try to reproduce the issue in 1.1.3, and if it works, I will close my report - or at least mark it in a way that points out that it's been fixed, if I don't have the ability to close it. But the point is, I hope the current restructuring you're doing also includes more robust processes about actually closing completed issues on the bugtracker. Else, one year down the line, you'll have exactly the same problem again...

EDIT: issue #9796 can be closed, I am unable to do it myself.

Thanks for the check Streetwind. We do have a process we run through usually after each release where we look at closed bugs from the test periods and close the matching bugs out of the public trackers. For example #9796 has a linked bug in the private tracker where the dev work was done, I havent gotten to that step yet, but I will put that near the top of teh list so we clean out those sort of things before we ask people for checking.

Good point and thanks for the reminder

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Article Comments posted by TriggerAu