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.

1

Modding / Re: Misc modding questions that are too minor to warrant their own thread

« on: May 27, 2021, 11:07:48 AM »

Doesn't seem like the sound player API has a way to do that.

Mega gross workaround I thought of: Break up the sound into chunks (say 0.5 seconds each).
In the weapon script, at each interval, check if we should continue playing the overall sound effect. If yes, play the next sound in the sequence, if not, reset and leave.

Hmm - I think SoundAPI.stop() should do it? And the various playSound() methods return a SoundAPI.

I'm not sure you understand - starting a sound or playing it isn't the real issue - making the sound loop naturally is.
Basically, within an EveryFrame scrip, and within the main fire squence (powerup and powerdown work) I have to know when the sound finished playing to start playing it again, for as long as the weapon is fireing.

The weapon itself can fire for 10 seconds (or less, depending on flux level). Since it's a builtin weapon, I COULD just  remove any ties to flux and make it so it will ALWAYS fire for 10 seconds, but I don't like that solution.
I could also edit the fire sound ot be exactly 10 second long and only play it once, but again...seems like a bad solution.

If a looping sound is what you're after, you should look into

Code

Global.getSoundPlayer().playLoop()

and its overloads. These all allows a looping sound to be played on command, and you can change their properties such as pitch and volume as they loop. Needs to be called once per frame to keep the loop going, but otherwise it sounds like exactly what you're looking for.

So I need to replace this: Global.getSoundPlayer().playSound("vns_Reflex_fire", 1f, 1f, point, ZERO);

with the below?

void    playLoop(java.lang.String id, java.lang.Object playingEntity, float pitch, float volume, Vector2f loc, Vector2f vel)


What would be a playingEntity? I'm not sure what goes there.

The playingEntity would be your weapon or ship (don't remember, someone correct me here); it's used so that two of the same "source" with a looping sound doesn't result in two different sounds.

2

Modding / Re: Misc modding questions that are too minor to warrant their own thread

« on: May 27, 2021, 06:27:58 AM »

Doesn't seem like the sound player API has a way to do that.

Mega gross workaround I thought of: Break up the sound into chunks (say 0.5 seconds each).
In the weapon script, at each interval, check if we should continue playing the overall sound effect. If yes, play the next sound in the sequence, if not, reset and leave.

Hmm - I think SoundAPI.stop() should do it? And the various playSound() methods return a SoundAPI.

I'm not sure you understand - starting a sound or playing it isn't the real issue - making the sound loop naturally is.
Basically, within an EveryFrame scrip, and within the main fire squence (powerup and powerdown work) I have to know when the sound finished playing to start playing it again, for as long as the weapon is fireing.

The weapon itself can fire for 10 seconds (or less, depending on flux level). Since it's a builtin weapon, I COULD just  remove any ties to flux and make it so it will ALWAYS fire for 10 seconds, but I don't like that solution.
I could also edit the fire sound ot be exactly 10 second long and only play it once, but again...seems like a bad solution.

If a looping sound is what you're after, you should look into

Code

Global.getSoundPlayer().playLoop()

and its overloads. These all allows a looping sound to be played on command, and you can change their properties such as pitch and volume as they loop. Needs to be called once per frame to keep the loop going, but otherwise it sounds like exactly what you're looking for.

3

Bug Reports & Support / Re: Potential bug with Entropy Amplifier visuals

« on: February 04, 2021, 02:22:00 AM »

Ah, makes sense!

4

Bug Reports & Support / Potential bug with Entropy Amplifier visuals

« on: February 01, 2021, 08:16:17 AM »

Hello there. While searching around for an issue with some of my modded visuals, I accidentally stumbled across a potential vanilla-side issue with how the Entropy Amplifier handles its jitter. To be more specific: the entropy amplifier uses this anonymous BaseEveryFrameCombatPlugin to make sure its damage buffs stay active even if the ship carrying the Entropy Amplifier gets shot down:

Code: java

if (Global.getCombatEngine().isPaused()) return;
if (targetData.target == Global.getCombatEngine().getPlayerShip()) {
    Global.getCombatEngine().maintainStatusForPlayerShip(KEY_TARGET,
            targetData.ship.getSystem().getSpecAPI().getIconSpriteName(),
            targetData.ship.getSystem().getDisplayName(),
            "" + (int)((targetData.currDamMult - 1f) * 100f) + "% more damage taken", true);
}

if (targetData.currDamMult <= 1f || !targetData.ship.isAlive()) {
    targetData.target.getMutableStats().getHullDamageTakenMult().unmodify(id);
    targetData.target.getMutableStats().getArmorDamageTakenMult().unmodify(id);
    targetData.target.getMutableStats().getShieldDamageTakenMult().unmodify(id);
    targetData.target.getMutableStats().getEmpDamageTakenMult().unmodify(id);
    Global.getCombatEngine().removePlugin(targetData.targetEffectPlugin);
} else {
    targetData.target.getMutableStats().getHullDamageTakenMult().modifyMult(id, targetData.currDamMult);
    targetData.target.getMutableStats().getArmorDamageTakenMult().modifyMult(id, targetData.currDamMult);
    targetData.target.getMutableStats().getShieldDamageTakenMult().modifyMult(id, targetData.currDamMult);
    targetData.target.getMutableStats().getEmpDamageTakenMult().modifyMult(id, targetData.currDamMult);
}

This is all fine and good, but the problem is that this does not include the target-side visual jitter graphics: those are handled slightly below that code, inside the main advance loop of the EntropyAmplifierStats file.

Under normal circumstances this doesn't cause any issues, but I've found two specific cases where this can cause bug-like visual behaviour:

• When the ship carrying the Entropy Amplifier dies, but the debuff has yet to end (this creates a de-sync between the mechanical effects and the visuals)
• When time-mult is involved, and high enough (This apparently causes a de-sync between the "application" and "consumption" of the jitter on a ship, causing a flicker-like effect). Hard to spot in vanilla due to time-mult increasing systems usually having their own visual jitter, but becomes clearer when adding time mult to other ships without jitter

This should be fixable by adjusting the anonymous everyframe script to also include desired jitter level and set the jitter at the same time as other debuffs and effects.

5

Blog Posts / Re: Personal Contacts

« on: August 13, 2020, 02:56:48 PM »

Very nice, definitely looking forward to this. Main complaint is that I might just procrastinate for the new patch instead of actually working on implementing the Vass questlines now that a system so close to what I needed will be in vanilla (heck, the current quest already has a basic system to pull of effectively what you've done here, but worse)!

Am I correct in assuming that since contacts show up in the intel screen, their display in said screen shouldn't be set in stone? For example, making the icon/name change dynamically (for an obvious example, someone who hides their identity until more trust is earned) or showing a "fake" importance that doesn't confirm to the 1-5 scale? Just making sure since having those displays completely set in stone on the coding side would make the system quite rigid and hard to use for mods.

6

Modding Resources / Re: [0.9.1] MagicLib v0.28 (2019/11/09)

« on: February 25, 2020, 09:30:43 AM »

I'm getting a crash, probably because I'm using the method wrong but I didn't find any sample code to go off of.

Might be my bad: that code is non-implemented. I... honestly didn't remember that stuff was still in the release branch. Thought it was on a private dev branch.

Either way, campaign trails are non-implemented, so you cannot use them.

7

Modding / Re: Releasing a mod that overwrites some files in the .api

« on: October 19, 2019, 02:00:44 AM »

While I'm not gonna go all "Don't do it, you madman!", I am going to say that overwriting the API pretty much ruins the point of working towards an API in the first place.

While some of these changed files may very well have justified reasons for being changed, it's as many has pointed out before: changing the API is very dangerous territory. Because it breaks the "promise" provided by the default API, no future mods can make assumptions on how things operate; aforementioned changes to the API from existing mods are already skimming the line and, as mentioned, can already cause compatibility issues. With these changes, it's pretty much impossible for anyone to know which mods are compatible in which situations without explicitly digging through all source code of all mods affected and comparing them towards the now-changed API.

8

Modding / Re: Misc modding questions that are too minor to warrant their own thread

« on: September 23, 2019, 06:38:13 AM »

What does the 8/6/5/4% in ship_data.csv mean?

It is an old "memory note" of sorts: it has no in-game effects, but refers to the standard proportions of flux dissipation vs. capacity for the ship classes: 8% of capacity as dissipation for frigates, 6% for destroyers etc.

Values in the column are (in vanilla, at least) generally the capacity a ship "would have" if it was balanced exactly against this benchmark, without being adjusted up or down slightly for the different individual hulls.

9

Modding / Re: [Help!] How to make sure AI loadouts stick to .variant file?

« on: September 20, 2019, 04:24:34 PM »

There is a tag you can add in ship_data.csv: "no_autofit", which does pretty much exactly what you're looking for.

10

Mods / Re: [0.9.1a] Tahlan Shipworks 0.3.7b - Ready broadsides!

« on: September 09, 2019, 01:56:35 AM »

I updated all the mods after a long weekend, and something broke either in Tahlan, or in Tahlan+GraphicsLib.

The Izanami special ability combined with its Atrapos Lances started causing graphical glitches. After the first use of Chrono Rupture while Atrapos is firing, the ship usually turns black, every Atrapos shot turns into a black "shadow" that hides effects, and all shield effects disappear for all ships for the rest of the battle. Venting shows the Izanami again, but then it's back to black.

Tried disabling everything but the shaders in GraphicsLib, but it did not help. It does not matter what other ships are in a battle. 1 on 1 in simulation also brings out this bug.

Sounds distinctly like an issue with your GraphicsLib installation; this sounds like OpenGL messing itself up quite royally. The Izanami triggering it is most likely due to it having a big distortion being triggered, though I'm not sure.

11

Modding / Re: Please be mindful of the tone of your mod

« on: August 25, 2019, 04:30:45 AM »

And if you dont like his mod just dont play it, dont force others to do the same .

Also i think too that forcing people to dont make jokes , vide "Onslaught was mistake", because that's joke, mean basically , that you dont like their jokes so throw them out of all players. Also i dont like you throwing insults on people and telling them they're liars. Dont insult people.

My first iteration of post could be a little harsh, but even if you're right, just point that, dont throw insults on people.

Oh, so me pointing out a factual incorrectness makes me the bad guy here? Saying "no, that wasn't what you said" is in no way, shape, or form an insult.

My response was purely on the level of "no, you don't get to decide what you said after you've said it" level. It was not an insult, it wasn't even a comment on their person, it was a statement on what was said and what wasn't.


And that's not even mentioning that I've never even remotely claimed that jokes should be forbidden OR that people are forced to listen to these opinions... quite the opposite, in fact:

C: Of course people can say things about a mods tone, just like the creators have every right to disregard said things. The argument that "they've put in work, you haven't, shut up" is utterly ridicilous... however, the opposite is also true: that a mod creator is forced to listen to this critique is equally ridicilous.

12

Modding / Re: Please be mindful of the tone of your mod

« on: August 25, 2019, 03:22:56 AM »

B. Undertones is the word I used. Tone control is a slippery slope that starts incredibly small, and slowly snowballs into something larger over time.

You realize this is just tone policing?
People have the freedom to design their mods however they please. The moment that goes away I certainly wouldn't be a content creator.

I'm not leaving outright lies unconfronted. Sure, you tacked on "undertones" at the end of that message, but "You realize this is just tone policing?" does not leave much open for interpretation.

13

Modding / Re: Please be mindful of the tone of your mod

« on: August 25, 2019, 12:59:23 AM »

A: Mods usually don't specify which mod a tip comes from, meaning it can be hard to actually "just don't use that mod" as suggested (exceptions exist though, and it has gotten better recently).

B: This is not a policing action, this is not a threat, it is purely the opinion of one person who'd like it if people, at the very least, specify if they add content which is of a very different tone to the rest of the game experience. Not a particularly tall order (not to mention it's not an order, but rather something they'd find nice), and definitely not a "tyranny of the offended".

C: Of course people can say things about a mods tone, just like the creators have every right to disregard said things. The argument that "they've put in work, you haven't, shut up" is utterly ridicilous... however, the opposite is also true: that a mod creator is forced to listen to this critique is equally ridicilous.

14

Mods / Re: The Crystanite (Version 1.10b Hotfix) [0.8.1a compatible]

« on: August 20, 2019, 10:23:34 AM »

I think his biggest crystalship is incorporated in one of missions in many mods i have.

This is in fact just a coincidence: both mods use the same sprite, but are otherwise completely different entities. Just another risk of using Spiral Arms sprites (which is why my newer projects don't). For the record, I *think* the mod in question is Ship and Weapon Pack, however I'm not certain.

Nicke had confirmed some time ago that he wasn't going to work on getting Crystanite to 9.1a anytime soon, so highly unlikely, as he may be working on other things.

Ah, yeah, I never did post that on the forums, did I?

I'm glad there's still people who think this looks like a cool mod. However, the Crystanite is on an undifined-length hiatus, depending on if I come up with some ways of
 - A: fixing some of the more glaring issues in the mod (such as content bloat, lack of complexity and balance), and
 - B: getting some new sprites that work well and fit better as an aesthetic


I've also been pretty preoccupied with studying and work, meaning starsector modding as a whole has been slow.

...of course, that's not to say I'm not working on anything: as some who visit the discord channel might have noted, I am currently busy updating the Vass (who are, despite not having a forum update for years, still in active development) to the standards I've achieved since their original inception and with a completely new sprite-set from Gwyvern. I've also been supplying smaller modding scripts to various modders and mods when necessary, so while I'm not very forum-active I'm still very much involved in starsector modding.

15

Suggestions / Re: API request thread (please read OP before posting!)

« on: July 02, 2019, 03:33:42 AM »

A method, of some sort, to adjust built-in weapons on a ship post-generation. Ideally, it would work in one of two ways: either ShipAPI.getVariant().addWeapon() would allow built-in weapon slots to be modified (which might not be ideal, or even possible), or some similar hook specifically for modifying built-in weapons could be added. This second hook could either be something similar to how built-in fighters can currently be modified (via list reference modification):

Code

java
ShipAPI.getHullSpec().getBuiltInWeapons(); /* Returns a List<Pair<String, String>>, with first element being weapon slot ID and second being weapon spec ID */

This has the added benefit of matching the existing getBuiltInFighters() and getBuiltInHullmods() functions. Or, if it's for some reason preferable, an entirely different endpoint could be used. Something like this:

Code

java
ShipAPI.getVariant().addBuiltinWeaponOverride(String slotID, String newWeaponID) /* Adds an override, making the variant replace the hullspec's built-in weapon */
ShipAPI.getVariant().removeBuiltinWeaponOverride(String slotID) /* Removes an override, giving control back to the hullspec */

Either of these solutions (or an equivalent solution) would allow for some more interesting weapons and hullmods to be coded, without messing with the autofit or fleetmember instantiators (which current attempts at "semi-builtin" weapons do), and several modders have already expressed desire to use the functionality this would allow.


Also, unrelated for the suggestion but related to the thread: the OP seems to be outdated, as several of its entries that now exist in the game are not marked as such.