Jnet Development Thread

The best place is to do a cursory search on Github and if you don’t see it already written about, open a new issue and post it there! As much detail and any screenshots also help immeasurably. Thanks so much!

2 Likes

Got it thanks :+1: So no way to get logs?

Not currently. I have as a long-term goal keeping logs and replays of games for viewing after-the-fact, but that’s not possible right now (and probably not for the foreseeable future).

2 Likes

Announcement:

I’m planning on changing how “discard at the end of turn” works. Right now, when you have too many cards in hand, you get a toast message that tells you to discard down (which you accomplish by dragging cards from hand to the discard). With my change, when you click “End Turn”, if you have too many cards in hand you’ll get a card-select prompt and can click as many cards as necessary in your hand, which will trash them for you. Once you’ve clicked the necessary number, you’ll be pushed back to the normal prompt with “End Turn” once again being the only option.

What do you all think of this change?

3 Likes

Sounds pretty great. Would help me look like less of a bozo when playing against cybernetics division (by taking too long) and against mental health clinic (by unnecessarily discarding).

A potentially-fiddly UI enhancement would be to put a border around the leftmost [handsize] cards as a visual reminder of your limit that is more obvious than the max hand size counter – e.g. so that when you’re looking at the cards in HQ/grip planning out a turn you take into account the hand limit and don’t look like a bozo.

4 Likes

That’s an interesting idea. I don’t know that it’d necessarily work in practice, cuz it might imply that a given card is “stuck being kept” instead of “this is just a potential card to keep”.

1 Like

As a compromise, how about the additional visual cue only appearing once all clicks have been spent? I know that does less to help someone plan their turn, but does reduce confusion around why the leftmost [x] cards have been bordered/highlighted or whatever?

FWIW, I’d personally be fine with the current handsize being visually indicated at all times, but I realise this might cause unnecessary confusion for some players.

In principle I think this would be a welcome change, however it’s relatively common for players to quickly change their minds (“no wait, I’ll discard this instead”) and/or mistakenly discard the wrong card and need to correct it.

Any change would need to make it possible for players to correct their hands without too much trouble.

On the corp side, I was trying to think through how these changes could create more confidence in the game state rather than less. There’s always that tiny sneaking feeling that a corp player fixing a mistaken discard isn’t dragging back the same card.

So what if the game state signalled this differently to the runner? For example, if the corp player mistakenly discards the wrong card and fixes it before ending their turn, the runner might see “[opponent] discarded two cards to Archives” then “[opponent] swapped a discarded card with one in HQ” instead of just seeing that they’d just dragged any old card from archives to HQ?

I think it is a valid point. From my point of view an entry in the log such card was mixed to hand like Archive (15) would solve it.

These are interesting ideas but might be hard to implement currently. How exactly would you want it to look? Any sort of mock-up would be appreciated cuz I can’t quite envision how I’d make it work.

ok, I try from my point of view, currently it looks like this:

player1 discards a card from their HQ.

player1 discards a card from their HQ.

player1 moves a card from their Archives to HQ.

player1 moves a card from their Archives to HQ.

for the move from HQ this is totally fine, as it should not be clear which card it is. But moving them back to HQ is telling you nothing.
What would be perfect:

player1 discards a card from their HQ.

player1 discards a card from their HQ.

player1 moves card (5) from their Archives to HQ.

player1 moves card (3) from their Archives to HQ.

The question is still how they are numbered, but assuming (1) is the card on top should work.

Does it answer your question Noah?

Yes it does! Thanks for that, I’ll experiment a bit and see if I can whip something up!

1 Like

That’s also relevant for stuff as Archives Memory.
Example:
The top of Archives is a facedown card. You access a HHN from HQ, and later got the Corp to trash something from HQ facedown that you suspect is the HHN. The Corp then plays Archives Memory to take one of the top two cards from Archives. You might want to know whether that’s the HHN or the older card.

Thanks for the end of turn trash btw, that’s dope.

i believe that archives is allowed to be shuffled, so long as the orientation of faceup or -down cards is preserved

1 Like

I believe that you are incorrect. :slight_smile: It’s the heap that is unordered. I could not find this information in the comprehensive rules of Nisei though.

If that were true however, we would still need the Jnet implementation to be modified because right now, most of the time, we know when was trashed the card retrieved by Archives Memory.

E.g., Corp trashes a card face down; later plays Hedge Fund; later trashes a card face down; plays Archives Memory to retrieve the first trashed card. Then we know that it’s the first trashed card that was retrieved.

From the current NISEI rules v1.1:

4.5.6. Archives
a. ARCHIVES is the name for the Corp’s discard pile. It is also one of the Corp’s central
servers.

4.5.2. Discard piles are not ordered. A player may freely arrange the cards in their discard pile
in any order at any time

3 Likes

OK thanks!
So should Jnet put all facedown cards together, so that it is unknown which card leaves Archives?

1 Like

Yeah, I think that’s what I’ll do now that I know this rule. Make two piles of cards in Archives: 1 of all face-up cards and 1 of all face-down cards.

Thanks for sparking this discussion!

1 Like

Question for everyone:

Currently, we have a “Star of turn effects” period we call in the engine :corp-phase-12 and :runner-phase-12, which are for the ability/rez/score windows that happen after the player receives their clicks and for triggering any “When your turn begins” effects. However, this is much more manual than it needs to be, and in a PR I just pushed up, I’ve made Rashida Jaheem and Marilyn Campaign better respect the actual rules, which is that unless you fire them manually, they don’t fire until we’ve hit :corp-turn-begins (1.4) and if they’re both rezzed you can choose which ability to fire first.

My question is: should we extend this functionality to all of the other “Start of Turn” effects? It would be slightly more cumbersome to click through and say, “No thanks, no thanks, no thanks” if you want to wait, but I think it’s better than having to remember which cards you’re allowed to fire and which you’re not, and it makes for ordering effects much simpler.

What do you all think?

1 Like

That seems good, but all this talk about start of turn triggers has made be think again about the “end of turn” problem, specifically that because of “each turn” triggers (Hayley, DBS, Tech Trader, etc…) its in your interest to want to trigger something on the opponent’s turn but at the end of it. Unfortunately, with JNet as is, this can often be really difficult. Usually people just work around it, but in a few cases (Councilman springs to mind) this can be impossible.

I think one solution is that before you click “start of turn”, you also have an option to click “end opponent’s turn”.

e.g. corp advances 3 times and scores, then clicks end of turn. Control passes to the runner, who has an option to use paid abilities before clicking “end opponent’s turn” themself. They then get the option to do their own paid abilities before their start of turn triggers start. They can then click “start of turn” and the game proceeds as usual.

This does have the downside of adding an extra button you have to click each turn, but I think its worth it for the increased precision.

4 Likes