Advance notice: changing game mechanics

[arekbulski]

I would like to change some game mechanics, and since there will be quite few of these changes, let me describe these on separate thread.

FIRST: I am going to improve the game mechanics (slightly) so that instead of 1 jump button there are 2. first button starts and keeps drives spinning (maintains max force after achieving it but still consumes EC), second button executes a jump instantly (with currently available force). This would allow jumping too early (at reduced chance) or too late (wasting EC which may not be abundant on ships without nuclear plants). This adds extra challange. If EC runs out while spinning, drives gradually lose generated force, but jump is still possible, and drives keep spinning in case EC supply goes up. Stops spinning if jump was executed or manually aborted.

SECOND: I would also like to remove "activate" button, so that forcereq/chance are always displayed and all drives on vessel must be used for jump. This makes menus much more usable. Also it kind-of helps with ships that dont have enough EC for all drvies. Player can jump at will when force is peek.

THIRD: I will remove the separate "FTL analysis" window and display important information in part's context popup. Truth is, some info is doubled, some info is not really useful, some info can be combined, and some info is missing (ie. calculated min altutude for 100 chance). Makes menu much more usable. Optimum altitude would be very useful because now player needs to either waste fuel on going way high or waste time on several orbital manuvers. Window has one advantage, that it shows in Map view (context popup doesnt) but with optimum altitude displayed, player wont need that anyway.

FOURTH: Removing restriction on source/dest being in certain modes. This seems arbitrary because it does allow to jump to a beacon in atmospheric flight (essentially suicide jump) but not jump to a surfaced or prelaunch beacon. Player should be free to make jumps that are clearly unadvisable.

FIFTH: Adding small EC consumption to activated beacons. This means player cant deploy just 1 part in space (which sucks anyway, you cant rename such a vessel), but needs a drone, battery, solar. If EC runs out, jumping to it is (temporarily) impossible. Since some players (me included) already have unpowered beacons deployed in their saves, there would be a CFG to disable this easily.

SIXTH: TweakScale support. Scaling is needed for vanity reasons, but mass and performance can remain constant. This is just for vanity needs.

SEVENTH: Tech requirements changes to much higher, comparable to Warp Drive. Already approved.

You dont need to approve in advance. I will implement it all, and you can play with it in game and just get a feel for it. But I am open for discussion.

REJECTED EIGTH: RemoteTech suport. Selected beacon would need to have a connection with active vessel to provide guidance, and therefore allow jump. For one, its difficult to code. For two, it just complicates game.

[linuxgurugamer]

My comments:

1 - Unnecessary, it just makes things more complicated.

2 - I disagree. I can see (and have had) instances where I'd only wanted some of the drives on a ship activated. For example, if there isn't enough EC to operate them all due to various circumstances (ie: damage, lost stages, etc), but later on there will be due to docking, etc. Do add an "Activate All", that will make it easier.

Third - I'd rather have the FTL Analysis Window fixed than removed. Having a separate window is useful, Adding the info to the right-click context window gets too cluttered. However, why not do both, and let me see how each looks before making a final decision. Fourth - I'd rather add restrictions (ie: prevent jumping to a beason in atmospheric flight, etc), than remove them. Fifth - Ok, but keep the EC small Sixth - NO, please. I already expressed this earlier. Seventh - Yes

[linuxgurugamer]

I'm going to have to reorganize the layout to work with my Jenkins server. Basicly, what I have to do is the following:

1. Remove a layer of directories - right now the source is one layer too deep
2. Move the VS solution file up one level
3. Add my local Jenkins config file

This is something that I have to do, not you. So, let me know when it will be a good time to do it. I'll do the changes in the dev branch, and when I'm done you will be able to pull them down.

[linuxgurugamer]

I just had an idea, means just a little more work for you :-)

I'm going to add a Settings window, with the following options:

1. Require all drives on a ship to be used at all times
2. FTL Analysis Window active

So, this should satisfy both of us. If #1 is true, then you can have the "Activate" button removed, if not, then the drives will need to be activated manually. If #2 is true, then the FTL analysis data will be available in the FTL Analysis Window, if not, then the data will appear in the right-click context window.

If this is ok with you, I'll get the settings window written and uploaded to the dev branch

[arekbulski]

Let me put counterpoints up, I think you misunderstood some of my vision. :) If you are still not convinced then, just wait for a finished product and be smitted then. :)

1. I know it "complicates it" somehow but it also gives player some challenge. Consider this analogy, you can have KSTS mod and automate delivery into orbit. Yet you still want to be able to fly SSTOs "hands on". What this feature adds is "hands on" experience.
2. You misunderstood, and I misunderstood it the first time I wrote about this feat too. Consider a ship, you have 2 drives, and EC inflow for 1, no batteries. You will be able to generate the same force as if you disabled one drive. It makes 2 drives half operational instead of 1 fully operational, same total force. If you dock, you use more drives. This feat does not deny player anything that he could do otherwise, but removing menus lessens clutter.
3. Agreed. I can easily display same info in both popup/window and only later remove the window.
4. Agreed. I see reasons for removing and tightening restrictions as equally reasonable. If this makes you happy, why not.
5. Jury is still out on this one. I am not sure if I really care about this feat.
6. When I put the beacon on 5m rocket parts stack, it looks laughingly small. I just want to make it look larger. It wont increase generated force or mass. It doesnt make it any more OP than it is now. I will add a visible note ingame so players are aware of this.
7. Already agreed.

Dont use hash, it references other tickets wrongly.

In my vision, there is no need for Settings window. Just put that on hold, and when you see final product, you will not have a need for it either. I will have it all done within few days.

[arekbulski]

There are few problems with repo. We need to drop some files from repo like

• bin\ obj\ .vs\
• AssemblyVersion.tt template, its too messy
• the 2 batch scripts, too messy I need your asssisstance on this.
• I would also like to remore entire build script from project settings, because its messy and I had to clean it to even compile it. Those scripts use hardcoded paths that do not work on my system. Lets leave this cleanup until after overhaul is finished.

[arekbulski]

I reconsidered and

4. I will remove all restrictions but add a clear warning to the player that jumping is sure suicide. I can easily think of some brave youtubers that would surely try jumping in atmosphere just for fun, or after watching Galactica's Exodus episodes, and making them unable for mere safety seems misplaced.

[arekbulski]

Just something I noticed. From readme

"Never, never, ever spin up the drive in a strong gravity field, keep far away from planets, suns, and other heavy objects."

Unless you want to calculate grav forces between ships, this part is pure fiction. Just saying. Which leads me to... EDIT. Ah you could mention moons and asteroids explicitely.

REJECTED NINETH: Add gravitational forces between ships. This is partially a joke because you unless you haul millions of cubic meters of uranium, the grav is almost zero.

[linuxgurugamer]

This MUST stay, it is part of my build process: AssemblyVersion.tt template, and needed to provide proper support when a user sends me a lot file The batch scripts are also part of the build process, please leave them

I would suggest that you edit your csproj file locally to delete the pre/postbuild command, but do not commit it. You can also set your local references.

You can drop the bin and obj and .vs, but they are harmless

Keep in mind that I am maintaining over 100 mods, I need to keep all of them building the same way for my sanity, and for my Jenkins server.

2. ok
3. ok I'll wait on the settings window. The readme, is for the user experience.

[linuxgurugamer]

As I said earlier, I had asked you to not move things around. I have updated scripts which I haven't committed yet to support my updated build process and my Jenkins server. And the AssemblyVersion.tt file is absolutely necessary. It reads the .version file and write it into the dll so that when the mod is run, it outputs the version in the log file. Very helpful when debugging someones log file.

[linuxgurugamer]

I'll accept it, since it's in the dev branch, but I'm not too happy.

Code changes is one thing, but changing the build process is not something lightly done. Believe me, I've been doing this for more than 40 years.

[arekbulski]

Point taken, no more messing with the build process.

[linuxgurugamer]

Thank you.

At least, not without chatting about it.

Are you done with moving files around? If so, then I can start working on my updated build

Let me know

[arekbulski]

Almost, PR one more commit. Afterwards no more shuffling files.

[linuxgurugamer]

Ok, let me know when you are done

[arekbulski]

Yes, I am done with shuffling files.

[linuxgurugamer]

Ok.

One thing, the changes need to be compatible with current games. A number of streamers are using this online, I don't want to cause them problems

[arekbulski]

You mean it cant break existing saves, Sure thing.