Print

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

[Alex]

(Sorry about the delay responding!)

What justify an important people in the API?

I know story npcs should be placed in there, but what about reproducable (infinite, but requires a specific condition to spawn) contacts? Do they go in there too or rather what is the purpose of this api?

Also what is the point of checking them out or in?

Basically it's a way to get at a unique NPC if they're needed for something and you're not, for example, just creating one on the spot or looking through a comm directory for a suitable one. So it depends entirely on what you need.

The "checking out" thing is meant to be a way to coordinate multiple things trying to involve an NCP in something (e.g. of they're already "checked out" for a specific purpose, they can't be "checked out" by something else for that purpose) but this isn't really used by the game.

I have another question.  I am writing a new version of VersionChecker, and  fetching the title of a mod forum thread would return the number of the latest version.  May I please code this new version of VersionChecker to do so? 

(VersonChecker is not vanilla.)

TAG_PLAYER_ONLY doesn't work on officer level-up for the base officer plugin (it doesn't check for that tag - OfficerManagerEvent does, and since FleetFactoryV3 relies on that, it works on both recruitable and NPC-fleet officers) but the mod can always fix that on its own by providing its own officer level-up plugin. Making them deprecated should work, too - it works on the levelup plugin and that trickles down to the other two.

Ah, thank you for the info! And, fixed this up.

Is it possible to set the max radius in hyperspace of a star system?

I am using the ConstellationGen methods to seperate the stars that I made and it uses the getMaxRadiusInHyperspace to seperate the stars, but the only way to increase the max radius in hyperspace is through using the autogenerateHyperspaceJumpPoints method in StarSystemAPI. Do we have other options  to increase the radius manually? I've been searching for a way but haven't found any.

Hmm, I don't think so. Let me add a setMaxRadiusInHyperspace() method. I suppose you could copy-paste the ConstellationGen methods, at least for the time being?

does the SHIP_LIMITED_TOOLTIP variant tag work as intended? (or am I misinterpreting it?)
I'm spawning a ship with lazylib's spawnShipOrWingDirectly which creates a fleetmember then spawns the ship & it seems not to apply correctly, the ship still has it's default tooltip when I select it in the command screen.
the text2 & text3 fields in the ship's desc seem to be filled out correctly, the only thing that seems like it'll be messing up will be the fact that the ship's getting spawned mid combat?

As far as I'm aware, it works - but it checks ship.getFleetMember().getVariant(), so perhaps there's some kind of disconnect there in doing this with spawnShipOrWingDirectly? For the omega, for example, it does work when they split and it looks to be adding the tag to ShipAPI.getVariant(), and using CombatFleetManagerAPI.spawnShipOrWing() to spawn the ships.

Random thing that doesn't involve anything I'm working on but is bothering me:

How often do tooltips in general refresh? The ones in the character skills screen seem to do it every frame the button is moused over, which seems, uh, less than ideal.
I've heard of an issue where looking at a cargo screen with too many blueprint items in it causes a framerate drop, and was wondering if that could be related in any way.

Either once when created or every frame, depends on the tooltip. Some need to be dynamic, but a bunch that don't strictly need to do it are still recreated every frame. It super doesn't matter performance-wise unless the tooltip creation code is doing something bad. And if it were, it'd still be an issue even if the tooltip was only created once, in that it would cause a frame drop when the tooltip is first shown.

It can't be the issue you're describing, since the tooltips aren't being created/recreated/etc unless they're actually being shown. So how many items there are in the cargo doesn't matter for this at all. At most one tooltip would be created at a time.

So, hmm. That issue might be caused by blueprint item rendering being a little heavier than for normal items? Or, perhaps, a modded item of a similar sort, that does something even more performance-heavy in its custom rendering? Really hard to say, though. It *could* also be tooltip-related, if an item's tooltip is doing something performance-heavy in whatever plugin method adds stuff to the tooltip, but in that case it would show up regardless of what other items might be in the cargo, and only when the tooltip is being shown.

[Ruddygreat]

As far as I'm aware, it works - but it checks ship.getFleetMember().getVariant(), so perhaps there's some kind of disconnect there in doing this with spawnShipOrWingDirectly? For the omega, for example, it does work when they split and it looks to be adding the tag to ShipAPI.getVariant(), and using CombatFleetManagerAPI.spawnShipOrWing() to spawn the ships.

ty for the answer! I'll probably just switch back to using the vanilla method, I'm not hugely sure on why I used lazylib's method anyway

Quick edit - here's the code I'm using to spawn the ship & change the variant & it still doesn't work correctly, the only other difference I could think of is that I've only been testing in the sim?

code

Code

    @Override
    public void apply(MutableShipStatsAPI stats, String id, State state, float effectLevel) {

        //maybe redo spawn in / out vfx, maybe use particles?

        ShipAPI ship = (ShipAPI) stats.getEntity();
        ShipVariantAPI variant = stats.getVariant().clone();
        variant.addTag(Tags.SHIP_LIMITED_TOOLTIP);
        String varID = variant.getHullVariantId();
        Vector2f loc = ship.getLocation();
        CombatFleetManagerAPI fleetManager = Global.getCombatEngine().getFleetManager(ship.getOriginalOwner());
        Vector2f safeLoc = new Vector2f(findClearLocation(ship, loc));

        if (!doneOnce) {
            fleetManager.setSuppressDeploymentMessages(true);
            //todo - needs better facing determination
            ShipAPI otherShip = fleetManager.spawnShipOrWing(varID, safeLoc, ship.getFacing());
            fleetManager.setSuppressDeploymentMessages(false);
            doneOnce = true;

            otherShip.addListener(new clonedShipListener(ship, otherShip, maxLifeTime));
            ship.setCustomData(PairKey, otherShip.getId());
        }
    }    

[close]

[Great Wound]

Is there an easy way to adjust commission stipend amounts on a per faction basis?

Ended up making a whole suggestion about it: https://fractalsoftworks.com/forum/index.php?topic=25309.0

[Liral]

(VersonChecker is not vanilla.)

Yes, I just don't want to drive traffic to your site if it would bother you. 

[Alex]

Quick edit - here's the code I'm using to spawn the ship & change the variant & it still doesn't work correctly, the only other difference I could think of is that I've only been testing in the sim?

Oh! You're spawning the other ship using the variant ID, which - if you're lucky - is going to be the stock variant ID (in which case it'll find and use the stock variant, without the added tag). If you're not lucky, the variant ID is some unique ID assigned to a refitted campaign variant, in which case it might not even spawn, since that ID would not be found in the map that has the id-to-variant mapping.

You probably want to use spawnFleetMember(). Or spawnShipOrWing(), with a known stock variant ID, and then add a tag to that stock variant. Basically, what you're doing - making a cloned copy of the variant - doesn't actually *do* anything since that variant never gets used.

Is there an easy way to adjust commission stipend amounts on a per faction basis?

Ended up making a whole suggestion about it: https://fractalsoftworks.com/forum/index.php?topic=25309.0

You can see the commission code - it's in FactionCommissionIntel. Off the top of my head, I don't think so. (Thank you for the suggestion; in all honesty I'm probably not going to touch it until I have a better notion for how I want all this to ultimately shape up/expand, if at all.)

(VersonChecker is not vanilla.)

Yes, I just don't want to drive traffic to your site if it would bother you. 

... ah, right, I missed that part of it. I appreciate you asking! In all honesty, I'd rather not - I mean no offense here, but I feel like code that makes mods fetch stuff from the forum should probably be written by programmers with a little more experience, since it's quite easy to make a mistake of some consequence. On the face of it, making a copy of VersionChecker (I'm not sure if the license allows it, but that aside) doesn't seem like a great idea, either, at least not knowing the reasoning behind it.

[Audax]

Hmm, I don't think so. Let me add a setMaxRadiusInHyperspace() method. I suppose you could copy-paste the ConstellationGen methods, at least for the time being?

Made a simpler code for seperating them, a bit crude and might crash the game but works.

[vicegrip]

I am currently modding my own station defense drone similar to the Gargoyle that has a fairly long range weapon and can face enemies with its main gun. Everything from the summoning ability to the drone itself works fine, but I've noticed the drones will often get fixated on an enemy, and won't attempt to switch targets even when it's rotated out of view. Is there a way to force a station defense drone to always attack the closest enemy?

[Ruddygreat]

Oh! You're spawning the other ship using the variant ID, which - if you're lucky - is going to be the stock variant ID (in which case it'll find and use the stock variant, without the added tag). If you're not lucky, the variant ID is some unique ID assigned to a refitted campaign variant, in which case it might not even spawn, since that ID would not be found in the map that has the id-to-variant mapping.

You probably want to use spawnFleetMember(). Or spawnShipOrWing(), with a known stock variant ID, and then add a tag to that stock variant. Basically, what you're doing - making a cloned copy of the variant - doesn't actually *do* anything since that variant never gets used.

ah, that makes some sense - I assumed that cloning a variant would assign the clone variant a unique id.
though it does seem to work using the campaign refitted variant, I'll try and see if using the cloned variant w/ a custom ID (smth like varID + "_clone") works, before falling back on spawnFleetMember

[Liral]

... ah, right, I missed that part of it. I appreciate you asking! In all honesty, I'd rather not - I mean no offense here, but I feel like code that makes mods fetch stuff from the forum should probably be written by programmers with a little more experience, since it's quite easy to make a mistake of some consequence. On the face of it, making a copy of VersionChecker (I'm not sure if the license allows it, but that aside) doesn't seem like a great idea, either, at least not knowing the reasoning behind it.

I apologize for having been vague.  I should have clarified that I have not written a new version of Version Checker but rather modified it to reduce the trouble modders have supporting it, fetch threads from the forum only with the code whereby Version Checker already fetches forum threads, and would not release this modification but rather personally test it to demonstrate that the Version Checker author, LazyWizard, should be include my modification in the next Version Checker release.  My reasoning is that many modders do not support Version Checker because its approach to checking whether the mod is updated requires the modder to follow a complicated and surprisingly-error-prone process of writing a custom .csv inside a hardcoded nested directory and including a separate .version file in the mod itself and maintaining another 'master' .version file at a separate link--all because VersionChecker was written before the StarsectorAPI could read .json files. 

This hassle had deterred me from supporting Version Checker for many versions of Realistic Combat, still deters other modders from supporting Version Checker, made me have to try several times to make it work, and even afterward ensnared a mod manager with a hidden gotcha error in the .csv I had to write for Version Checker.  After all this trouble, I thought, "There must be a better way", talked to much more experienced mod and mod-manager authors, and they agreed that there is. My better way would be simple enough for more modders to support, not require separate .version and master .version files, and be reliable enough to avoid tangling mod managers: the modder would include the download link and forum thread ID in mod_info.json and the current mod version number in the title of the forum thread, and Version Checker would check the title of the ID-indicated thread, fetched with its current thread-fetching code, for a mod version number and, if it found one, compare it to the one in mod_info.json.

So... um, may I please try my code out? 

[Alex]

Made a simpler code for seperating them, a bit crude and might crash the game but works.

(... I'm not too sure "might crash the game" and "works" are compatible with each other )

I am currently modding my own station defense drone similar to the Gargoyle that has a fairly long range weapon and can face enemies with its main gun. Everything from the summoning ability to the drone itself works fine, but I've noticed the drones will often get fixated on an enemy, and won't attempt to switch targets even when it's rotated out of view. Is there a way to force a station defense drone to always attack the closest enemy?

Hmm, I don't think so - it's just going to do what it does, which is mostly behaving like a normal ship that just can't move. You could write your own ship AI for it, but that's... involved. It might be worth it to make sure that you have the hull size set to FRIGATE, though, just in case it being not set to that is affecting its behavior.

ah, that makes some sense - I assumed that cloning a variant would assign the clone variant a unique id.
though it does seem to work using the campaign refitted variant, I'll try and see if using the cloned variant w/ a custom ID (smth like varID + "_clone") works, before falling back on spawnFleetMember

*thumbs up*

Spoiler

I apologize for having been vague.  I should have clarified that I have not written a new version of Version Checker but rather modified it to reduce the trouble modders have supporting it, fetch threads from the forum only with the code whereby Version Checker already fetches forum threads, and would not release this modification but rather personally test it to demonstrate that the Version Checker author, LazyWizard, should be include my modification in the next Version Checker release.  My reasoning is that many modders do not support Version Checker because its approach to checking whether the mod is updated requires the modder to follow a complicated and surprisingly-error-prone process of writing a custom .csv inside a hardcoded nested directory and including a separate .version file in the mod itself and maintaining another 'master' .version file at a separate link--all because VersionChecker was written before the StarsectorAPI could read .json files. 

This hassle had deterred me from supporting Version Checker for many versions of Realistic Combat, still deters other modders from supporting Version Checker, made me have to try several times to make it work, and even afterward ensnared a mod manager with a hidden gotcha error in the .csv I had to write for Version Checker.  After all this trouble, I thought, "There must be a better way", talked to much more experienced mod and mod-manager authors, and they agreed that there is. My better way would be simple enough for more modders to support, not require separate .version and master .version files, and be reliable enough to avoid tangling mod managers: the modder would include the download link and forum thread ID in mod_info.json and the current mod version number in the title of the forum thread, and Version Checker would check the title of the ID-indicated thread, fetched with its current thread-fetching code, for a mod version number and, if it found one, compare it to the one in mod_info.json.

So... um, may I please try my code out? 

[close]

Wait, wait. Why would/does Verstion Checker fetch forum threads (aside from whatever code it might have letting the player open the forum thread)? It doesn't do this just to check the version - that's why the modder needs to host a .version file elsewhere, so that Version Checker doesn't hit the forum with a bunch of requests every time the game starts. This seems like a bad idea - I think, at least if my understanding is correct, that the thing you're simplifying away is the thing that makes Version Checker viable in the first place.

The inability to read mod_info.json - not just any .json file, but that one specifically for multiple mods - is *not* the reason for why a mod needs to host a file with its current version. Not hitting the forum with a mini-DoS is.

(It *is* the reason for being unable to get version data from mod_info.json and requiring the mod author to also include a .version file with their mod, but that's secondary here.)

[Liral]

Wait, wait. Why would/does Verstion Checker fetch forum threads (aside from whatever code it might have letting the player open the forum thread)? It doesn't do this just to check the version - that's why the modder needs to host a .version file elsewhere, so that Version Checker doesn't hit the forum with a bunch of requests every time the game starts. This seems like a bad idea - I think, at least if my understanding is correct, that the thing you're simplifying away is the thing that makes Version Checker viable in the first place.

Your understanding is correct, and now I'm glad I asked! 

The inability to read mod_info.json - not just any .json file, but that one specifically for multiple mods - is *not* the reason for why a mod needs to host a file with its current version. Not hitting the forum with a mini-DoS is.

Ahhh!  I don't want to hit your forum with a mini-DoS!    I won't even test this modification of VersionChecker as-is.

(It *is* the reason for being unable to get version data from mod_info.json and requiring the mod author to also include a .version file with their mod, but that's secondary here.)

Thank you so much for your patience and understanding response.  I guess a master copy of mod_info.json with the version number would be the next best alternative to reading the forum thread title.  That said, a local separate .version file would no longer be necessary if the .version file information could be kept in mod_info.json.

[Alex]

Ok, whew, glad I wasn't missing something. Thank you for being so understanding about it!

And, yeah, you're right on about the .version file info potentially being kept in mod_info.json - at least, as far as my understanding of all this goes.

[Liral]

Ok, whew, glad I wasn't missing something. Thank you for being so understanding about it!

Haha, of course!  I know I don't know what I'm doing, so I ask first before hitting the big red button. 

And, yeah, you're right on about the .version file info potentially being kept in mod_info.json - at least, as far as my understanding of all this goes.

Eeeeee!   

[Ruddygreat]

ah, that makes some sense - I assumed that cloning a variant would assign the clone variant a unique id.
though it does seem to work using the campaign refitted variant, I'll try and see if using the cloned variant w/ a custom ID (smth like varID + "_clone") works, before falling back on spawnFleetMember

*thumbs up*

ah-ha! found the issue- lazylib's method uses the createFleetMember() method that takes a VariantID, not the one that takes a ShipVariantAPI; made my own version that takes a ShipVariantAPI & it all works fine now.

[Alex]

*thumbs up* all around