Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

16

General Discussion / Re: Skill system encouraging frequent respec is annoying when it is not cheap.

« on: March 08, 2022, 07:59:55 AM »

If storypoint is too hard maybe start a new game?
The cost is there so you are committed to a build and need to think twice before doing so, while offering a properly priced leeway. Player controlled ship is way more powerful than an AI controlled one (most of the time) so switching flagship constantly is something that is extremely powerful and owe to cost a storypoint. IMO it’s one of the best bargain in all the ways you can spend a storypoint comparing to overpriced historian colony item spawn and exponential growth colony upgrade just for some useless credits.

17

General Discussion / Re: Planet composition algorithm: is it designed to screw you, or RNG?

« on: March 03, 2022, 06:51:24 AM »

Hazard pay mitigates ALL growth penalty introduced by hazard and since it only grows to size 6 it’s a finite money sink and pays for itself relatively quickly.

I never take hazard rating into consideration.

18

General Discussion / Re: Planet composition algorithm: is it designed to screw you, or RNG?

« on: March 02, 2022, 03:33:56 PM »

As the other guy said, just settle. Perfect is the enemy of the good enough, and good enough + time (endgame farming) = great.

I don't have any GREAT seeds for 95.1, but I'm sure someone has found and posted one somewhere. Might be worth trying a game with an amazing system, to really push the limits of colonies, but that often gets boring.

I actually disagree with a lot of colony advice, and try to set down my first 2 colonies pretty much ASAP, as soon as I can afford to buy the required supplies/machinery/crew and have enough space junk to get the materials to the system. My first colonization fleet is usually a mix of barely spaceworthy pirate salvage that will be left on the planet anyway. Maybe an extra 200-300k for initial buildings (industry, waystation, patrol HQ).

I don't look at colonies as cash cows, usually. I just hope they can cover crew/officer salary and support heavy industry/orbital works to make ships from blueprints. I don't actually need them to do much more than that. That's why I try to settle 2 colonies quick, usually one for high value industry (heavy, fuel production) and the second to do something that is relevant to the high end supply chain (mining/refining, volatiles) I pick for my first.

I totally agree on this. Vanilla colony system is there to make you able to cover most of the day to day operation costs, and it’s easy to find systems good enough for the task. Hazard rating is also extremely overrated given that in-faction supply can easily slice the operating cost in half.

I think it’s the community setting up an impractically high standards for colonization that lead to many “complaints” and drive mods to overextend the economy.

19

Modding / Re: Modding Help

« on: March 01, 2022, 08:01:57 AM »

If you do not override the method the code does nothing.
You can not and should not use ShipAPI in apply effect before method.
You can get ship attributes by stats.getVariant and getHullSpec.

20

Bug Reports & Support (modded) / Re: Crash when starting new game?

« on: March 01, 2022, 07:28:19 AM »

Update Diable Avionics and MagicLib

21

Mods / Re: [0.95.1a] Modern Carriers 1.9.0

« on: February 28, 2022, 08:13:22 PM »

Not sure if this is intended or not:  VIC Vipers don't double in cost when used with Ace Core

Fixed with the latest update.

22

Suggestions / Re: Probably already requested: Initial Wing Formations

« on: February 27, 2022, 08:40:05 AM »

There is no air resistance in space so line formations are preferable

23

Mods / Re: [0.95.1a] Concord 3.1.0a

« on: February 26, 2022, 09:59:42 AM »

Does this latest version fix the issue I reported earlier?

I have the same problem, operational center. Does this code need to show something after done?

Download the bridge version and save the game should resolve the issue

24

Mods / Re: [0.95.1a] Concord 3.0.1 + PhaseLib

« on: February 26, 2022, 08:42:21 AM »

Fatal: Hullmod with id [concord_operations_center] not found for faction [player]

error after installing latest version

Run this in console command on old version and save.
Do not enter refit screen in the process.

Code

FactionAPI player = Global.getSector().getPlayerFaction();
        for (HullModSpecAPI spec : Global.getSettings().getAllHullModSpecs()) {
            String doppelganger = "concord_" + spec.getId();
            if (player.knowsHullMod(doppelganger)) {
                player.removeKnownHullMod(doppelganger);
                if (!player.knowsHullMod(spec.getId())) {
                    player.addKnownHullMod(spec.getId());
                }
            }
        }

The new version get rid of doppelgangers after game load to minimize other mod interaction jank

Thanks for the quick reaction but, if possible, i need you to be a little bit more specific on where to run this exactly so not to make mistakes.

Thank you in advance

When you are in campaign layer floating in the space with the old version concord active.

25

Mods / Re: [0.95.1a] Concord 2.2.1

« on: February 26, 2022, 07:55:10 AM »

REPORT

After update newest version , i've check the game by type in console :"allhullmods" and result got All The Game Hullmods !

for example : 1 ship dont have Phase field , it can add manualy now...., Vast Bulk , Salvage Gantry, Ground Control Support Package , Advanced Ground Support... also can addable

dude this sounds like a feature more then a bug

It's an old version missing an if clause excluding the supposed to be hidden hullmod from whitelist. It is no longer a thing in latest version.

26

Mods / Re: [0.95.1a] Concord 3.0.1 + PhaseLib

« on: February 26, 2022, 07:52:29 AM »

Fatal: Hullmod with id [concord_operations_center] not found for faction [player]

error after installing latest version

Run this in console command on old version and save.
Do not enter refit screen in the process.

Code

FactionAPI player = Global.getSector().getPlayerFaction();
        for (HullModSpecAPI spec : Global.getSettings().getAllHullModSpecs()) {
            String doppelganger = "concord_" + spec.getId();
            if (player.knowsHullMod(doppelganger)) {
                player.removeKnownHullMod(doppelganger);
                if (!player.knowsHullMod(spec.getId())) {
                    player.addKnownHullMod(spec.getId());
                }
            }
        }

The new version get rid of doppelgangers after game load to minimize other mod interaction jank

27

Modding / Re: [Resource?] Implementing Hullmod Tracker & Forcing Refit Screen to Refresh

« on: February 26, 2022, 07:48:31 AM »

Alternatively, just implement TrackedHullmodEffect (in other utilities). You should never need a forced refresh.
Every frame scripts are terrible.

In some cases, forced refreshes are necessary. And that 'onRemove()' is subject to limitations, here it is executed as soon as a hullMod is removed. If I can find a way to do this with listeners or by hooking into the UI or something, I will change everything to that way, naturally. For now, this does the job that I needed, though.

There's a method for the hullModFleetEffect called 'onFleetSync()' (or something like thatSync) which also triggers on hullMods being added or removed, but the script triggers for every fleet. It can be woven into a hullMod that only goes to the flagship, and ignores other fleets, but it requires keeping an active list on the memory at all times. I found it rather late, but that can also be utilized to do things as soon as they are added/removed.

Forced refresh is only necessary when you use everyframe script which is unassumed by the refit engine. ApplyEffectAfter method is enough to trigger any evaluation that needs happening if it involves updating attributes, for example, adding another hullmod. It does run the risk of infinite re-evaluation of bad coding but that is out of scope.

My main concern of your approach is the force refresh may render undo function inaccessible by force updating the variant of the ship. I also avoid everyframe script whenever possible due to, as you mentioned, performance concerns.

Ok, here is the thing. My mod does most (all) of its things in a different way; in a way that I have never seen in any other mod. I alter the hullSpecs, and I do it in a way that I doesn't affect other ships (hint: clone). I have 3 categories: retrofits, cosmetics and systems. All of them alter the hullSpecs, and some of them require the refit ship on the screen to go away, otherwise the changes aren't displayed properly.

For example, one retrofit (hullMod) that I have splits a slot into two smaller ones. This change requires such a refresh, and it's not just for QoL that a refresh is required. Otherwise, you can dupe weapons, lose weapons, etc... there are lots of stuff to deal with. A refresh takes all those issues away, at the cost of invalidating the undo function. And from my experience, I rarely use that function - YMMV but having these hullMods do their thing without causing an issue seems like a good cause to sacrifice the undo function altogether. If I could hook into the UI, and refresh it without refreshing it, I'd do it that way.

And as far as the scripts go, they only live in the refit screen, and die as soon as you close/swap the tab. They can be further made cheaper by checking the number of hullMods rather than checking the ids, and so on. If I can use listeners and such, I'll definitely go that way, or maybe try using the method you mentioned (but I remember trying to use it before, just to have game crashing on my face - maybe I was using it wrong back in the day, who knows).

So I made these scripts to deal with the issues in my mod, and sharing it with others in case they require it as well. Tartiflette's some stuff require such a thing if I'm right, so I tossed him a link too, and might be useful to him/her and others that require such a thing.

Is there something that cannot be done by a simple global hullmod and you have to use an everyframe and deleting functions from players?
I can see all you're trying to do is messing with player cargo when installing/uninstalling and they are naturally non-issue if you're using a simple global tracking hullmod with a persistent memory. If memory usage is ever a concern, clear the installMemory cache on unpause, easy as that.

28

Mods / Re: [0.95.1a] Concord 3.0.0 + PhaseLib

« on: February 25, 2022, 11:34:02 PM »

Updated to 3.0.0 with greatly improved performance and reduced jankiness.
Added PhaseLib.

29

Modding / Re: [Resource?] Implementing Hullmod Tracker & Forcing Refit Screen to Refresh

« on: February 25, 2022, 01:24:44 PM »

Forced refresh is also needed for OP cost reduction hullmods, iirc.

The hullmod effect interface literally required “affects Op” boolean for you to indicate and you should only do that in applyEffectsBefore method, in case you’re banking on listeners.

30

Modding / Re: [Resource?] Implementing Hullmod Tracker & Forcing Refit Screen to Refresh

« on: February 25, 2022, 12:26:05 PM »

Alternatively, just implement TrackedHullmodEffect (in other utilities). You should never need a forced refresh.
Every frame scripts are terrible.

In some cases, forced refreshes are necessary. And that 'onRemove()' is subject to limitations, here it is executed as soon as a hullMod is removed. If I can find a way to do this with listeners or by hooking into the UI or something, I will change everything to that way, naturally. For now, this does the job that I needed, though.

There's a method for the hullModFleetEffect called 'onFleetSync()' (or something like thatSync) which also triggers on hullMods being added or removed, but the script triggers for every fleet. It can be woven into a hullMod that only goes to the flagship, and ignores other fleets, but it requires keeping an active list on the memory at all times. I found it rather late, but that can also be utilized to do things as soon as they are added/removed.

Forced refresh is only necessary when you use everyframe script which is unassumed by the refit engine. ApplyEffectAfter method is enough to trigger any evaluation that needs happening if it involves updating attributes, for example, adding another hullmod. It does run the risk of infinite re-evaluation of bad coding but that is out of scope.

My main concern of your approach is the force refresh may render undo function inaccessible by force updating the variant of the ship. I also avoid everyframe script whenever possible due to, as you mentioned, performance concerns.