Thomas Avirson

Forum Replies Created

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #33036
    Thomas Avirson
    Participant

    Captain Matsiyan, sir. While it might still need a coat of paint to look pretty and a bit of tuning to work out the bugs, far as I can tell nothing’s stopping it from being taken out for a spin.

    #33009
    Thomas Avirson
    Participant

    Hello Sabasti, I’ll start with an explanation of things as I understand it and then provide you with a step-by-step process to try.

    Once the mod is installed it’s already active, so you can skip running “zEnable Expansion.bat” as the only reason for it (and “zDisable Expansion.bat”) is to allow you to turn the mod on & off. I would instead recommend making a copy of the original Artemis directory and renaming it to “ArtemisTSN” or something similar, and then extracting the mod files to that TSN copy.

    There is also a known issue with some our currently posted files; you’ll want to download two other files and use them to replace files under the same names in the dat directory of your Artemis copy.

    Step-by-step:

      1. Install Artemis.
      2. Make a copy of the entire base Artemis directory & rename it “ArtemisTSN” (or similar).
      3. Download the “Full Upgrade File” from our site; ignore the “Patch Only File” for now.
      4. Extract the contents of “mod-master” (from the “Full Upgrade Files” download) to the ArtemisTSN directory.
      5. Download the corrected files (here and here) and use them to replace the files of the same names in the dat directory of your ArtemisTSN.
      6. Try to launch “Artemis.exe” from your ArtemisTSN directory.

    Hopefully this will fix it for you.

    #33007
    Thomas Avirson
    Participant

    I cannot recall any specific instance of being provided a written brief. We do, at times, get O.N.I. reports following our missions posted onto these forums, and I’m sure there’s “classified” paperwork that the Senior Officers use for those shift briefings, but that’s as close as we get at present.

    #33004
    Thomas Avirson
    Participant

    We do both simulations and missions during duty shifts. Simulations are used to stress-test the server/mod, provide players a chance to act in roles they’re less familiar with, and to generally get officers warmed up before missions. Missions, as continuations of the TSN canon, are story-driven experiences with repercussion. You could, in a sense, see simulations as “drills,” though we don’t typically have standalone practice sessions.

    As for the attack patterns, captains & experienced officers try assist new players by being more specific with their details when issuing a command, EG: “Helm, come about for Delta 2 on Sierra 8-9, engage with full beams,” rather than simply saying, “Delta 2 on Sierra 8-9,” as they would with a more experienced crew. We try to provide a welcoming atmosphere, as we fully understand it’s a lot to learn and mistakes are likely to be made early on. Once again, if you prefer it you’re also welcome to act as an observer until you’re more comfortable.

    As another resource, we do have a few people who stream the game and have recordings available for viewing. Here are a few recent recordings from different shifts & perspectives:

    #33002
    Thomas Avirson
    Participant

    Hello Sabasti, I’m sorry to hear about your Discord woes. While it’s true that we use Discord a fair bit these days for announcements, awards, objective tracking, and discussion, the important things are just about always echoed during shifts to ensure that everyone’s in the loop where possible. In short, you won’t be missing too much without Discord, simply getting “caught up” during the shift (and many new things are announced in TS3 first anyways).

    Thanks for taking a look at the New Player’s Guide, it’s good to hear that you’re taking a proactive approach. If you want to learn more about Artemis, here’s a list of some of our core training documentation:

    We always welcome new players! You can certainly join us and simply observe or, if you’re up for it, you can get your feet wet – no former experience is required to fly with us.

    As for your Discord troubles, have you tried using the browser version, or only the applications?

    #32989
    Thomas Avirson
    Participant

    Without details on a proposed cycle time or range, I can really only think of a two use-cases for such a device at the moment:

    1. Disabling vessels when you want to reduce the risk of significant damage or casualties. This use-case isn’t particularly common, but it certainly does come up now and again.
    2. Running continuous disables to assist another vessel engaged in Delta maneuvers; ideally, disabling beams on enemy vessels before they get within firing range and/or their impulse drives to prevent clustering when you intend to clear with beams (IE helping the lead vessel avoid engagements in multiple enemy arcs). In this use-case I’d recommend against such a lightly equipped vessel engaging in operations against certain strong “loners” with strong weapons and/or special modules, as getting tango could quickly prove disastrous for said lightly equipped vessel (even with another friendly vessel to assist it). This isn’t too different from certain TSN ships having “bad match-ups” against specific types or enemy craft, but the danger may be relatively higher for it.

    The worth of that second use case, at least when compared to another fully-equipped vessel, is debatable – at a glance maybe it’s great for reducing the fleet’s rate of attrition and recovery times, but then time-to-kill is comparatively increased so it might not break even in terms of energy expenditure.

    Drone clearing is largely a limit of cycle time and quantity, while range is typically less relevant until you get to the extremes. For a supporting craft the range is likely instrumental to helping it avoid a pitched engagement but is not, ultimately, a good metric of its drone-clearing capacity.

    On a note relating to the previous section, I haven’t personally witnessed drone clearing being a significant issue unless they’ve been ignored for too long (built up to extreme amounts) or were being handled ineffectively (slow targeting, beams not cooking, helm not scraping on asteroids; IE operator errors). Even vessels with below-average beam cycles can deal with drone clouds if handled correctly – in my opinion, it’s more of an officer skill/experience issue than one that requires a design-end solution… but, I’ll get off this soap box for now.

    In summary, while the weapon sounds interesting and does have niches it could fill, there are a lot of factors that could determine its relative worth. For a support craft, it is, in concept, a great method for it to contribute without being too strong in its own right.

    #32959
    Thomas Avirson
    Participant

    Regarding Weapons Officer Engagement
    You’re correct that there will not be an abundance of activity on weapons, but there is a degree of challenge involved as each of those passing shots matter. Being able to maintain a visual lock on a specific ship system as it performs a Delta-1 at warp, arguably warp 2 at least and even assuming the helm officer moving in a straight line, requires some degree of skill. And, when engaging an ship whose shields have been exhausted, the beams may best be fired in a way to spread the damage over the target’s visible systems.
    It’s spikes of fine-details activity rather than consistent activity… though, for experienced weapons officers, it may not prove interesting enough. You do bring up an excellent point in that regard. Perhaps an increase in light ordnance to lighten those restrictions is due, and while I hesitate to be adding a PD beam I’m not entirely opposed to it.

    Regarding Beam Arcs
    The arcs are intentionally narrow and short to encourage having to expose the ship to some danger in order to be effective. As it operates to avoid direct engagement between cycles, it has some time recover in between those strikes. I wanted to avoid creating a ship that had low-to-no operational risk, but if it proves to be too fragile as a result it can be tweaked accordingly. It’s a shared point of concern, and you’re right to point it out.

    Regarding Durability & Defenses
    It’s not intended to engage fighters or drones – it will invariably be pursued by them at times, but its agility allows it to dance around those problems rather than facing them directly. I would also note that it will disable fighters it fires upon in the first volley, possibly even one per arc (part of the reason for the staggers, though admittedly that’s taking a risk with a high skill ceiling attached to the execution).

    When it dives through the lion’s maw, those shield should be pumped to 300% to mitigate some of that damage – and even then, I do fully expect it to take low-to-moderate system damage as no ship engaging in its weakest field should come out unscathed. It’s not a line ship, as you correctly identified, but a specialist to support a contingent.

    Thank you very much for the feedback – and as stated, I do share many of your concerns on its current design iteration. I’m glad you find the ship concept to be fun.

    Notes for thread:
    Aft Shields are initially listed at 8, not 5; I cannot edit the topic to fix that typo.

    Thinking out its Delta-1 passes, I do have some concern that boosted beams might refresh faster than it can realign for another passing strike, doubly so if it’s having to avoid drones & fighters. Perhaps adding more damage to the beams while extending the cooldown will keep its potential from being wasted without dropping its overall DPS, though I’ve no suggestion as to what those exact numbers should be.

    #32957
    Thomas Avirson
    Participant

    1) As recommended by Nhaima, beam damage has been doubled for testing.
    2) File paths for .dxs and .snt have been modified to direct to the “/data” file, rather than “/data/TSN/Player” file for ease of copy/pasting files during design iteration.

    Resource file updated to reflect changes, code be posted here for easy viewing:

    <vessel uniqueID="25" side="0" classname="Kharvaach Class" broadType="player">
        <art meshfile="dat/kharvaach.dxs" diffuseFile="dat/artemis_diffuse.png" glowFile="dat/artemis_illum.png" specularFile="dat/artemis_specular.png" scale="0.2" pushRadius="150" />
            <internal_data file="dat/kharvaach.snt" />
        <shields front="12" back="8" />
        <performance turnrate="0.007" topspeed="0.7" shipefficiency="0.6" warpefficiency="0.3" jumpefficiency="1.0" />
        <beam_port x="0.00" y="5.90" z="211.45" damage="0.38" playerdamage="7.50" arcwidth="0.08" cycletime="40.0" range="1000" />
    	<beam_port x="0.00" y="5.90" z="211.45" damage="0.38" playerdamage="7.50" arcwidth="0.08" cycletime="40.0" range="1000" />
        <beam_port x="-1.15" y="5.90" z="211.45" damage="0.38" playerdamage="7.50" arcwidth="0.12" cycletime="40.0" range="850" />
    	<beam_port x="-1.15" y="5.90" z="211.45" damage="0.38" playerdamage="7.50" arcwidth="0.12" cycletime="40.0" range="850" />
        <beam_port x="1.15" y="5.90" z="211.45" damage="0.38" playerdamage="7.50" arcwidth="0.16" cycletime="40.0" range="700" />
    	<beam_port x="1.15" y="5.90" z="211.45" damage="0.38" playerdamage="7.50" arcwidth="0.16" cycletime="40.0" range="700" />
        <torpedo_tube x="1.15" y="5.90" z="211.45" />
    	<torpedo_storage type="trp" amount="6"/>  <!-- Homing"-->
    	<torpedo_storage type="nuk" amount="0"/>  <!-- LR Nuke-->
    	<torpedo_storage type="min" amount="1"/>  <!-- Mine"-->
    	<torpedo_storage type="emp" amount="2"/>  <!-- EMP"-->
    	<torpedo_storage type="shk" amount="4"/>  <!-- Plasma Shock"-->
    	<torpedo_storage type="bea" amount="2"/>  <!-- Beacon"-->
    	<torpedo_storage type="pro" amount="6"/>  <!-- Probe"-->
    	<torpedo_storage type="tag" amount="2"/>  <!-- Tag"-->
        <engine_port x="0.00" y="91.88" z="-208.96" />
        <engine_port x="0.00" y="77.60" z="-208.96" />
        <engine_port x="0.00" y="-92.05" z="-208.96" />
        <engine_port x="0.00" y="-77.78" z="-208.96" />
        <engine_port x="70.15" y="10.74" z="-144.31" />
        <engine_port x="61.28" y="-6.88" z="-144.31" />
        <engine_port x="79.41" y="-6.88" z="-144.31" />
        <engine_port x="-70.15" y="10.74" z="-144.31" />
        <engine_port x="-61.28" y="-6.88" z="-144.31" />
        <engine_port x="-79.41" y="-6.88" z="-144.31" />
        <long_desc text="Kharvaach Class Destroyer^Destroyer class suited for interception of light craft.^3 FIB arrays^2 Torpedo tubes^Stores for 6 Homing, 0 Nuke, 1 Mine, 2 EMP, 4 PShock."/>
      </vessel>
    #32956
    Thomas Avirson
    Participant

    At this point, it requires the following:
    Feedback on design intent/execution
    Field testing for design iteration
    A working texture map (could not figure that out)

    Other:
    The vertical nacelles are intended to be difficult to reach and the rings are subject to hallway damage, but it may be too troublesome in its present stage.
    In solo field tests to work on certain vesseldata features, it did very well at punching through shields and into target systems on lighter targets, which was the intent. TTK was consistently higher than Lancer under similar conditions, likely because the longer cycle gave time for targets to repair systems.
    The image links didn’t work quite right, but you can right-click and view them in another tab.
    The vesseldata is stored in a .txt file under the “Resources” link, which itself contains the .snt, .dxs, and the same images as above.

    Note
    Even if this concept is rejected, the .dxs and .snt can still be used for other vessels.

Viewing 9 posts - 1 through 9 (of 9 total)