eezstreet

Argh, pick somewhere other than Photobucket to host this though. I can't zoom in at all on it.

Scrapped in favor of Binary Reliable Commands.

Thread moved to Modding Requests and Suggestions

It doesn't really matter, the CD version has barely anyone using it anyway.

...why would you even use that when OpenJK literally provides this functionality.

Thread unlocked It looks like the mod was pulled from Moddb. Is there something that has happened to this mod?

I don't think it works for SP though.

This information is primarily aimed at fellow programmers and is mostly a mind dump of some design which has been a long time coming, frankly. Prior to the engine source code being released, there were two copies of an entity's inventory being stored, one for the client, and one for the server. The server contained the "master copy" of an entity's inventory. Reliable commands are sent to the client every time an item is added or removed from the inventory. This of course has several limitations: A player can only know what items are in their inventory, not other players. Although with another reliable command, you can get sent this information.If a player loses their copy of their inventory on the client (such as through a vid_restart), all of the data needs to be sent back from the server, which increases bandwidth and may drop the client if their inventory is big enough.Reliable commands are limited in size. If an item instance has lots of fields, it might be truncated and therefore invalid on the client.So instead of using a crappy reliable command system, here is a pretty radical idea which I have been sitting on for a while: put it in the entityState. The information would be networked across in the engine via delta encoding and eliminate lots of overhead as well as enable new opportunities for features like trading, variable item qualities, and an "inspect" command to use on other players. In terms of data structures, I am borrowing the concept of components from Raz0r's xsngine. Maybe he will take some inspiration from my idea. Here are my proposed data structures #define ITEMNAME_LEN 64 struct ItemData; struct ItemInstance { uint_fast64_t nHiSeed, nLoSeed; char szInternal[ITEMNAME_LEN]; ItemData* pItemData; // not networked, independently verified on client and server }; struct ItemStack { unsigned nCount; // number of items char szInternal[ITEMNAME_LEN]; // which item it is ItemData* pItemData; // not networked, independently verified on client and server }; typedef struct { bool bStack; union { ItemStack* pStack; ItemInstance* pInstance; } } ItemSlot; struct Inventory { unsigned nRevision; // not networked; change me to signal that something has changed in this inventory ItemSlot* pItemSlots; };

T3-M4 is not a ship! Replace it with the Raven's Claw at once!

Updated OP with information on what platforms JKG will run.

This is fascinating. How are LODs and vis handled?

Updated OP

Looks like a stormtrooper got a bad nose job. I kinda like it.

Are you looking for someone to do this for you, or are you wanting to do this yourself? I'm asking because this is kind-of the wrong section.

It's on a `develop` branch. All of the item code is getting rewritten from (basically) scratch.

We haven't really had a discussion about the Xbox content. I think there's some case to be made for JKA being on homebrew systems, like maybe a Wii port of OpenJK. I think it's an interesting avenue that hasn't really been explored yet.

Xbox doesn't really have a homebrew system for you to author the CDs unfortunately so I would consider that a bust, unless you were to somehow author a modified JA CD.

On close examination, those values in the screenshot are wrong. Turns out there was an off-by-one error producing incorrect drop rates. Here are the correct drop rates: And as a bonus, I added a new command (tcEvalMulti) which turns on the multi flag for treasure classes when evaluating them:

It is probably best that we create another topic tbh since you're in charge of it now. EDIT: DONE

new item drop system at work. This is a prototype command for testing the item drop rates

I am happy to report that the Treasure Class system is fully coded and I have some screenshots to show of the math behind it. For starters, here is the format of the new treasure class files (this one is called ext_data/treasure/test.json): { "classes": { "base": { "numberPicksMin": 1, "numberPicksMax": 5, "picks": { "high-quality": 1, "med-quality": 4, "junk": 10 } }, "high-quality": { "numberPicksMin": 1, "numberPicksMax": 1, "picks": { "launcher_W-90": 4, "chem_CR-24": 7 } }, "med-quality": { "numberPicksMin": 1, "numberPicksMax": 1, "picks": { "rifle_E-11": 8, "carbine_E-11": 12, "Mine_LaserTrip1": 2 } }, "junk": { "numberPicksMin": 1, "numberPicksMax": 1, "picks": { "pistol_Suppressor": 5, "pistol_DL-18": 3, "pistol_Q2": 4 } } } } Each treasure class .json file can have multiple treasure classes inside of it. Treasure classes are case insensitive. Also this means now that item names will be case insensitive going forward. I have created a tcEval command which performs actual simulated drops. Here is me simulating 100 drops of the `base` treasure class: (note: the console currently can't render the '%' correctly, so it shows as a '.') Also note that the `base` treasure class only picks 1 item from it, instead of 1-5 as listed in the treasure class file. This is currently something that I am working on.

Done.

At best I see OpenJK using an MSI/simple installer with maybe a launcher to check for updates if the user prefers. No need to keep the user on the bleeding edge of updates unless it's a massive security loophole or critical bug being corrected.

So let me get this straight. "Politically correct" people are ruining things for you because you can't be blatantly racist or sexist anymore? Seems legit. EDIT: In any case, this is neither here nor there.

Why? It is a pretty solid measure I'd say.