eezstreet

Just a reminder that this event begins in roughly 24 hours.

@@Willdo

@@Noodle

@

@@Silverfang

@@Xycaleth

@@DT85

@@Darth Futuza

@@Onysfx

@@SiLink

@@Obsidian

@@MagSul

@@Evian

@

@@Stoiss

@@nyarl

@@Ramikad

@@Circa

@@therfiles

@@Pande

@@ooxavenue

The event will be at 1PM Eastern Standard Time (GMT-5), but if there is considerable demand we will be having an encore match at 7PM.

The match will be held at the same IP address as the first scrimmage match started. In case you forgot or can't find it, it will be in the server list (check JKHub.org servers). You will probably want the map pack.

Additional mentions, since the previous post was capped:

@@1NaCsTeR

@@SeTh

@@Seven

@@ensiform

Could it be that you don't have the dependencies? (SDL, OpenAL) - not sure if this is related, as I'm not sure how Mac works

Hey guys!

 

Just downloaded the latest update (1.2.1) and it looks sweet! However, I was wondering if there are any specific instillation differences for running the mod on MacOS. Upon running the .app, I got this:

 

 

My specs are: macOS 10.12.1, 16GB RAM, running off a Steam instillation of JKA. So sorry if I'm missing something obvious. Let me know if you'd like the full report that Apple generates when the error occurs.

Hi,

We are looking into Mac and what problems it's having. While it seems the game is compiling on Mac, it's having some issues launching with the correct program arguments. We've had a variety of different errors pop up, including "No assets detected", "Failed to load renderer," etc.

I'm going to defer to @@Xycaleth on this one as he knows more about Mac than I do.

I think it's decided to go towards 1pm EST then!

Trying to get a streamer, but our two main streamers aren't available on that day. I'll let you know closer to the event.

Let me know..!

The patch has been released. For all of you wishing to participate in the scrimmage match, you will need 1.2.1 to play.

I don't think that throwing the book at people is the right approach on how to teach people.

I think the best option when it comes to learning how to program is really look at the code and dive in. In your case, you want to make a tower defense, right? Here's a shortlist of everything that you'll need to do to make that happen:

• Commands to place, sell, and move towers
• A means of keeping track of life, and the current wave that you're on
• A means to generate income, so you can create more towers
• A pathfinding system for AI to reach its target
• Actual tower entities, and behavior functions for them (beam towers shoot a trace beam, laser towers could shoot a laser, etc)

It's a lot of stuff, and I don't have the answers for everything involved there (especially #2, I've never worked with actual pathfinding), but it's certainly an interesting project. I'd start with the first three. Commands are done on the server in g_cmds.c/pp. Maybe start by figuring out how to give yourself credits/cash as a command.

They go straight through shields.

I'm saying to the uninitiated player, it's not immediately apparent what damage types and what shields correspond to one another. You'd need some sort of way of figuring that out.

So in regards to shields being changed players no longer start out with a bonus 25 health (from the old shield) and have EVEN LESS health by default than before as a result.  Would a change like 125-150 hp as the default be an okay way to help balance this?  (Plus I'm thinking eventually in LMO phases, characters will have less or more hp than 100, depending on their level.  So its supposed to vary a little eventually, anyway).

You start with 100 health and no shields, correct. I actually think this is fine, it makes the gameplay a little faster to start. It takes now two less shots to kill someone with the starter pistol (5->3) because of changes to the damage types involved.

I mentioned it yesterday on Discord.  I'll see if I can hop on in a bit, but specifically if a grenade item (eg: thermal-e) kills another player, yourself, or an npc it will crash all clients and the server. If the grenade only does damage, there are no problems, only if it does the killing blow.

Just to follow up on this, I think this might have fixed that, as players were frequently going into a T-pose before - if freezeTorsoAnim was something invalid it could maybe cause a crash if a player was hit by a thermal detonator.

How would the enemy (person hitting the shield) be able to tell the difference between them?

It's been implemented.

In hindsight, I suspect what semblance of balance there was before is now very much out the window, seeing as how the ACP Array Gun does 20% more damage across the board, slugthrower ignores shields, and the pulse shotgun goes right through armor. Blasters are going to have to be cheaper probably to compensate.

Question: What is a disruptor? Is it Pulse? Or Blaster type?

These seem like good changes (note that the number actually does change colors for a moment when it changes), although we need to finalize the art assets first.

Oh I just remembered. @@eezstreet, JKG needs an ingame server list. This would really help when testing.

It won't really help if all the bugs are fixed

I mentioned it yesterday on Discord.  I'll see if I can hop on in a bit, but specifically if a grenade item (eg: thermal-e) kills another player, yourself, or an npc it will crash all clients and the server. If the grenade only does damage, there are no problems, only if it does the killing blow.

I can't seem to reproduce it. I'm assuming it's fixed or just a random bug.

@@eezstreet I want to do some bug testing first, to make sure nothing obvious was missed first before you release it, let me know when it's ready. Also was the issue with grenades looked at yet?

Which issue? You're going to need to be more specific.

The build is currently being packaged and will be released either today or tomorrow. Stay tuned.

Some more new features to CTF, especially adding credits per flag captures.

Weapons may specifically have properties to increase their effectiveness against certain things that they are normally weak to.

 

I think default damage multipliers gathered in one file (I assume that's what you mean by damagetypes.json)  with optional overrides in .wpn files is the way to go.

 

Question: Will future items (as in variants/qualities/etc. of items) be individual .wpn files for each one or will the extra properties they gain be determined in the itm files?

I'm not sure yet.

I think weapons for right now should have the same modifiers, and we can think about adding it to weapons when the need to balance arises.

In Phase 3 we will be focusing more on getting proper character models for all the races and basing the armor off of it. Right now it's a bit tricky because models don't use standard proportions and things can clip into one another.

That being said, the basic functionality of the armor is there, and I don't think it's going to change very much between now and then. We can still make armor, but we should try and make a basic standard for proportions so things don't look awkward/funky later on.

So now that I've finished all of the other hugemajor parts of 1.3.0, I can start working on this.

The question is, how should, for instance, Cold v Armor be determined? Should it be determined via a damagetypes.json where the values can be customized? And maybe have the damage block in the .wpn file override some things? Or?

What we need are some concepts for armor items specifically. Anyone got anything in mind?

Sooo no match today?

Date: Saturday, November 19th

Little more than a week away!

This system has, by and large, been implemented, but I feel it needs a few extra explanations:

First off, I lied, there is mesh based projectile collision in the game, and which mesh counts towards which body part is based on what the surface on the mesh is named:

Anything that starts with:

• hips : Can be waists or legs, depending on where it hits
• torso : Can be waists, arm, chest, head, or back, depending on where it hits
• head : Always head
• r_arm : arm or hand, depending on where it hits
• l_arm : arm or hand, depending on where it hits
• r_leg : leg or foot, depending on where it hits
• l_leg : leg or foot, depending on where it hits
• r_hand : hand
• l_hand : hand

These values then translate into the following limb damage multiplier, and subtract from the following armor slots:

• foot: 0.5 limb damage; boot slot
• leg: 0.7 limb damage; leg slot
• waist: 1.0 limb damage, leg slot
• chest, back: 1.0 limb damage, torso slot
• arm: 0.85 limb damage, shoulder slot
• hand: 0.6 limb damage, gloves slot
• head: 1.3 limb damage*, head slot

* most likely incorrect

To recap, there are the following slots:

• Head slot: Helmets; may in the future affect the HUD
• Neck slot: Amulets, things of that nature (might not be physically represented on the player)
• Torso slot: Chest armor
• Robe slot: Jedi robes that are worn over armor. They don't provide any protection at all.
• Leg slot: Leg armor
• Glove slot: Gloves
• Boot slot: Boots, may in the future affect footstep sounds
• Shoulder slot: Shoulder pads and pauldrons
• Implant slot: Not visible, they are special implants that you may receive.

For developers, the .armour files have been removed and replaced entirely with new .arm files. The following benefits of this new system include:

• Improved performance. Using a new Ghoul2 lookup table, it will copy one instance onto your player instance, instead of having 5 different instances being animated at the same time. To put it in perspective, if there are 5 players with full armor before, it would have to have 25 different Ghoul2 instances before...and all of them are gone now (they've been put onto the player)
• Improved networking/less bugs. The armor networks through the playerState/entityState instead of being reliable commands for equipping and unequipping, reducing the network overhead and reducing the possibility for bugs to creep in. Also it extends the capability of features that we can have with armor.
• More robust files. It uses JSON arrays instead of splitting strings by commas, for starters.

Here's a sample of a new .arm file:

{
    /////////////////////////////////////////
    //
    // Jedi Knight Galaxies - Armor File
    // Template (Stormtrooper Body Armor)
    //
    /////////////////////////////////////////

    "ref":        "sttorso",        // The reference that links this to the .itm file
    "slot":        "torso",        // Which slot this goes in
    "ehp":        50,            // Effective hit points - "Armor" in the GUI
    "movemodifier":    0.8,            // How much to modify the movement speed by

    // Visuals - all done on the client
    "visuals": {
        // To specify a skin, use a * and the skin name. Here, it uses model_default.skin.
        // modelGroup specifies which model group this armor belongs to - it won't load the same model twice.
        "model":    "models/players/stormtrooper/model.glm*default",
        "modelGroup":    "stormtrooper",

        // armorOnSurfaces tells which surfaces we should -only- show on the armor.
        "armorOnSurfaces": [
            "torso",
            "torso_body",
            "r_arm_shoulder",
            "r_arm",
            "r_arm_sleeve",
            "l_arm",
            "l_arm_shoulder",
            "l_arm_sleeve",
            "torso_augment",
            "torso_body_augment",
            "torso_waist"
        ],

        // bodyOffSurfaces says which surfaces to turn off on the player.
        "bodyOffSurfaces": [
            "torso",
            "torso_holster",
            "torso_strap",
            "torso_bandolier",
            "r_arm_shoulder",
            "r_arm",
            "r_arm_sleeve",
            "l_arm",
            "l_arm_shoulder",
            "l_arm_sleeve",
            "torso_body",
            "l_arm_a",
            "l_arm_b",
            "l_arm_c",
            "r_arm_a",
            "r_arm_b",
            "r_arm_c",
            "torso_l_shoulder",
            "torso_r_shoulder",
            "torso_vest",
            "torso_armor",
            "torso_cowelbase"
        ]
    }
}