• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

Discussion Brainstorming and Progress

Tingyun

Corsair
Storm Modder
In any case, the amount of options are quite huge. Eventually we'll have to limit ourselves.
And I must admit I'm beginning to lose track of all the suggestions and which ones are good/bad and why.... :unsure

Also, in addition to my above post, on this general issue:

Here is what I think makes sense: If a modder has an idea they would have fun implementing, then of course they should get feedback and suggestions at the outset before implementation, and incorporate those suggestions. And if people dislike it, they shouldn't spend time on it. But then after that feedback process, if generally people think the idea is good, even if some people are skeptical, we should go ahead and let the person make the implementation, try it out, and then create a toggle to remove it or something later if in practice it proves negative.

Requiring basically unanimous approval of theoretical plans for a modder to create something that they think is fun and would enjoy creating is just way too conservative and slow. Especially because many people might find that when they try the thing out, they actually do enjoy it. It is too tough to judge everything in theoretical terms.

And if the people who initially were skeptical remain unconvinced when they see the practical form, great, add a toggle then. And everyone who liked the idea gets to enjoy the system.

Basically, we've got tons of ideas and tons of debate, and more time spent debating than it would take to implement test versions of many of them.

And it sucks the fun out of it when modder a feel they can't try something that they want to try and would be fun to make. At that point, what difference between this and a job? It sucks the fun out of it.

So I think, it should go like: initial debate and feedback, and as long as some people like the idea, the modder is free to go ahead and create a test version. And then we can see in practice how we like it and whether some people need a toggle. Some things need to be tried out in practice not just debated in theory.

So, I think it actually is clear what ideas should be implemented from the past week: we have some unanimously liked ideas, and some almost unanimously liked ideas, both should be tried out when and if a modder thinks it would be fun to spend their own time doing so, and then we can add toggles if people don't like them later. Unanimous approval shouldn't be needed to try something out, instead just some people liking it and that modder thinking doing it would be fun is enough.
 
@Tingyun: I made a separate thread for this since there has definitely been some stuff to say on the subject lately, but it doesn't really fit with the other discussions.

For starters, I will NEVER stop people from trying stuff on their own, nor from sharing it. If you want to do something, go for it!

The way I normally work here myself is based on the often-true assumption that "somebody needs to do it" equals "I need to do it" and the fact that my time for modding is very severely limited.
As a consequence, by the time I start doing the work, I want to know as exactly as possible what I'm going to do. That way, my time spent would be the most efficient.
So often we discuss stuff weeks, sometimes even months before I'm ever ready to even begin on the implementation.
That has the added benefit that often potential issues may be caught and addressed prior to any code making its way into the game.
But yes, it is definitely slow.

It is also inspired in large part by past experiences, where fancy, complicated features were thought to be ready for implementation in the mod, were added, and subsequently broke the game very badly.
This happened after the release of Build 14 Beta 3.2 and it took me a very long time to first roll back the responsible changes and then re-add all fixes to be able to make progress again.

Similarly, a year ago we had massive delays in getting Build 14 Beta 4 actually released, for very similar reasons.
But this time, we noticed that before the public release, so rather than releasing something unplayable, we ended up delaying until it was OK. Ish.
As we found out after the release, there were still a bunch of new issues introduced, that I finally tackled in the current Beta 4.1 WIP.

Therefore I have become very, very careful about what I'm willing to add to the main mod.
Because if what goes into the mod isn't fully stable and ready, more often than not, it is me who ends up paying the price for that mistake, even if it is not actually a problem with my own added functionality.

As it is, I have substantially more time for discussing stuff, because I can do that even when I'm not at home with access to the game files.
The alternative would be for me to not use that time at all and just remain silent.
But I cannot use that time for modding, because I'm supposed to get some real work done as well. ;)

Actually doing stuff, on the other hand.... At the moment I haven't even found the time to install the latest ZIP that @Levis posted, let alone anything newer.
So I'm very simply behind. Maybe I can do something about that in the weekend, but I can give no guarantees on that.
Actual modding time for me is just very scarce.

I'm hoping the Git Version Control will be able to speed up the collaborative process.
Plus, a more thorough understanding by forum members on the differences between "ideas", "experiments" and "finalised mod content" might help too.

And if indeed we can maintain the current level of activity (which is quite unprecedented in a good few years!), perhaps it would be good to reserve a spot for "experiments".
Either as subforum or as "thread prefix" to indicate that someone is trying things there, outside the "official modpack development", but that if appreciated and successful can be added at some point.

Anyway, that's just a bit of background and some related suggestions.
 
Here is what I think makes sense: If a modder has an idea they would have fun implementing, then of course they should get feedback and suggestions at the outset before implementation, and incorporate those suggestions. And if people dislike it, they shouldn't spend time on it.


:no

If a modder has an idea they would have fun implementing, - then since it is the modding that gives them pleasure - they should go ahead and do it & test it in their game.

Once they are happy that it is working as they want and most of the bugs have been removed then they can post it for inclusion in the New Horizons mod. Then the community can do the final bug fixing, resolve any conflicts that occur, and decide whether to include it permanently.

What should be avoided is the release into the New Horizons Mod of half completed mods - or mods that have not been debugged.

The reason for this is that there are far too few people here who are willing or able to go through debugging, or commenting on inconsistencies or problems with new mods. And those that do comment are generally basing their comments on there own preferred style of play ( there is nothing wrong with this - since it is what they will have the best understanding of) and not considering the multitude of other ways that the game can be played.

:drunk
 
100% in agreement with both of the above posts.

But the conservative approval process I am referencing is not in relation to "is this stable" or "is the implementation going to break anything", it is rather in terms of "is this feature the best idea" and "will it make the game more fun."

On the former, great care is needed. But for the latter, we should be more risk-taking, and if most people like the idea, and a modder wants to do it, then as long as the modder can produce a stable version that works fine we should try it out. This even if there is some remaining skepticism, because getting unanimous love for the replacement or alteration or addition of almost anything is difficult at the theoretical stage. General general agreement and feedback is first needed, but not unanimous approval to just try it out.

The sharing XP dialogue system is a great example. Through rounds of feedback, we have an interesting idea that has been refined through group discussion. A dialogue system to enable half skill gain rate in one skill, no other effects from share XP. It is interesting, and drives a good compromise between the many concerns people have (i.e., it deviates from my suggestion for shore party sharing to address Grey Roger's concerns about micromanagement, and rightly so).

That is as refined through discussion and carefully considered as we are going to get at the theoretical stage. Yes, there is some remaining skepticism. But Levis has already suggested a way to address the concerns of people who liked the old system (internal settings having an option to change the default 1 to 10 or whatever of skills that can be shared).

It achieves almost everything everyone wants, and many people (myself included) eagerly look forward to it. There is then no reason not to go ahead and implement a version. We shouldn't still spend more time seeking an elusive goal of absolutely unanimous and enthusiastic approval before trying something out, certainly not at the theoretical stage.

Anyway, I see that as the proper standard for modding balance changes/feature additions: feedback, revisions to address concerns, but if in revised form most people like it, go ahead and implement but be ready to put a toggle in if the theoretically skeptical people also dislike the practical implementation. At that point, it should purely be a question of whether some modder thinks it fun to spend his time doing it. (And every modder of course remains free to himself be more conservative, as his time pressures dictate)

Game stability/bugginess should of course counsel greater caution, but we haven't been debating those issues these past weeks. ;)
 
I'm not saying you're wrong, because you're not.

But trying something that, with a bit more discussion, we could have known in advance was not a good idea, is a waste of time.
And if there are only very few people around to make things happen, then anything that wastes their efforts is best avoided.
So I'd rather spend a bit more time thinking things through than to make any quick decisions and have to spend weeks fixing stuff, only to find out it was never a good idea to begin with.
(That has definitely happened in the past. A not-too-bad recent example would be the "Soldier Weapons in Boarding" one.)

At the moment, @Levis and myself are the main people who can make complicated things happen and who are really able to hunt for bugs and fix them.
Therefore I consider both our time and effort to be very valuable, which means I want that time and effort to be spent where it counts, not trying random experiments.
As such, I'd prefer if the two of us focus as much as possible on "fixing bugs", leaving "experiments and gameplay updates" with a lower priority.

I cannot enforce this, of course, and if @Levis insists on doing new fun stuff instead, then I will not stop him. It is just a personal preference.
But fact is that I have actually been sticking to that preference myself for quite a while, since at the very least I "set an example".
Which has been quite tough, since I'd much rather implement my envisioned Reputation system changes than to fix yet another bug.

On the other hand, yourself and anyone else who wants to learn modding is absolutely welcome to experiment and try what you want.
I would never dream of standing in the way of that. Not for you, not for @Levis and not for anyone else.

It is a difficult balance to find though between "fixing stuff", "brainstorming", "exprimenting" and "delivering a stable and playable mod".
And for the longest of times, it has basically been me trying to do all of that. Together with "community management" and "mod promotion".
It is only very recently that we've had some more people around who are interested in making stuff happen too.
So I have high hopes that we can gradually start to spread out the "responsibilities" to make the whole modding process much more efficient, speedy and fun! :cheers
 
Pieter, all of that makes sense. I agree with the need to decide it is a good idea first, I guess I just think sometimes in the past few days I think we have reached that point, with as developed an idea as possible that most people are excited about (and with ideas for toggles if others dislike it). I want that to be the point where we say, ok, this idea is good.

On your point on bug hunting and fixes, I cannot express how grateful I am that you and Levis spend your time on that. But personally, I would much rather you spend at least 50% of your time on doing modding projects that you find fun, rather than just bug hunting. Because this should be fun for you both.

And the current version is very, very stable and bug free. Look at how minor the bugs I report usually are. About the only bug I've reported that I actually even care how quickly it gets fixed is the office type reinitilize, because if that is fixed soon I can continue my campaign, if not it is a new start. But even that isn't such a big deal that I would want people to miss out on working on the parts they want to.

So, personally, I really hope you let the bug fixing stuff be the minority of your work, and you instead do some projects you are excited about:reputation and loyalty, shared XP dialogue, or any of the other brilliant ideas you've had.

The game is stable enough that you've earned the chance to have fun with your modding.

Anyway, speaking of experiments from those of us who don't have the bug hunting skills and don't need to be quite so cautious, I will be completing a massive set of 2 experiments today. Rework of perks to make AI captains more effective in battle, change of skills for Doctor and firstmate, tightened weapon tiers, all weapons persist throughout the game, and maybe 20 other minor changes. Eskhol has volunteered to test and offer feedback, so if it is ok I'll use posting it in the brainstorming forum to get feedback?

I will mark it clearly as an experiment, so no one gets nervous thinking it is intended to be part of the main mod in any current form.

Maybe most of the changes will prove to be a bad idea, but I actually like them myself so far (and I haven't hit any bugs in my play tests yet), so we'll see if we can learn something of use. Maybe some component part or parts will prove to be good after they are observed in practice.
 
So, personally, I really hope you let the bug fixing stuff be the minority of your work
It is. But mainly because some "community management" comes first. ;)

Anyway, speaking of experiments from those of us who don't have the bug hunting skills and don't need to be quite so cautious, I will be completing a massive set of 2 experiments today. Rework of perks to make AI captains more effective in battle, change of skills for Doctor and firstmate, tightened weapon tiers, all weapons persist throughout the game, and maybe 20 other minor changes. Eskhol has volunteered to test and offer feedback, so if it is ok I'll use posting it in the brainstorming forum to get feedback?
No need to even ask. DO IT!
 
As @Pieter Boelen said, if you want to help modding please do. As long as it's simple things we can always include them in the mod and if they do seem to break things we can easily revert them back. If you want to do more complex stuff go ahead but we need a bit more cautious about it.
 
As long as it's simple things we can always include them in the mod and if they do seem to break things we can easily revert them back.
IF we use the Version Control System.
Otherwise it is sometimes less simple. ;)
 
Back
Top