🐛 `console.log` not working in player.js about warriorjs HOT 14 CLOSED

I found using the debugger super helpful.

It's easiest with a local npm install:

npm i @warriorjs/cli

and then add an index.js as follows

'use strict';

require('@warriorjs/cli/bin/warriorjs');

now you can debug with:

node --inspect-brk index.js - just drop a debugger in player.js and play around with the commands.

from warriorjs.

WarriorJS v0.3.0 includes a think ability that can be used as an alternative for console.log. It's not perfect yet, but I think it's good enough for now. Let me know if you have any feedback, I'm closing this ticket now.

from warriorjs.

@olistic thanks for the quick reply! So far I'm thinking something along the lines of warrior.say() would feel the best to use. Though, there is the issue of a name collision in the future should a warrior ever be able to say anything in the context of a level. Perhaps a separate logs section for each turn is a better solution?

warrior.say would need to have some thought put in to logging complex values (if that is desired):

-------------------------------------------- turn 001 --------------------------------------------
♥ 20
╔════════╗
║C  @S aa║
╚════════╝
> Spartacus says "{ some: { json: 'object' } }"

A separate logs section doesn't look too bad:

-------------------------------------------- turn 001 --------------------------------------------
♥ 20
╔════════╗
║C  @S aa║
╚════════╝
> Spartacus walks forward

╔══════════════════════════════════════════════LOGS══════════════════════════════════════════════╗
║ 1.                                                                                             ║
║   {                                                                                            ║
║     some: {                                                                                    ║
║       json: 'object'                                                                           ║
║     }                                                                                          ║
║   }                                                                                            ║
╚════════════════════════════════════════════════════════════════════════════════════════════════╝

Perhaps a little theming within the context of the world would help it fit in better:

-------------------------------------------- turn 001 --------------------------------------------
♥ 20
╔════════╗
║C  @S aa║
╚════════╝
> Spartacus walks forward
> Spartacus added entry #1 to the journal

╔═════════════════════════════════════════════JOURNAL════════════════════════════════════════════╗
║ 1.                                                                                             ║
║   {                                                                                            ║
║     some: {                                                                                    ║
║       json: 'object'                                                                           ║
║     }                                                                                          ║
║   }                                                                                            ║
╚════════════════════════════════════════════════════════════════════════════════════════════════╝

from warriorjs.

yup. that was it. Was trying to figure out why my readme's weren't markdown as well. This would explain it

from warriorjs.

Hey @jakehamilton! Thanks for your detailed issue, I agree that something like this is needed (as other people have asked in the past: #41).

I'm going to take the time to think how this could be best implemented. I could inject console inside the VM context, but because of the way the play log is printed, the console.log calls would be hoisted instead of being inline with the play events. The other options I'm exploring so far are:

• Monkey-patching console.log with Logger. This has the advantage to preserve the existing logging interface already known by JS devs, but maybe feels a bit awkward implementation-wise.
• Adding warrior.say() ability that logs the message to the console in the form of > Spartacus says "blah blah blah". This feels more in sync with the APIs in the game and requires less magic to implement, but it breaks a bit the separation between the core and the abilities that already exists.

Any suggestion is welcome, and thanks again.

from warriorjs.

warrior.journal() could log to a journal.txt file or just output to terminal.

Just a thought to keep the logging "in character" with the game, as if the warrior was carrying a journal and taking notes in it to aid progress.

from warriorjs.

Another option in those same lines (but that doesn't interfere with the warrior's namespace) could be to pass a journal parameter to the playTurn function that allows the player to log to said journal.

Example:

class Player {
  playTurn(warrior, journal) {
    if (warrior.feel().isEmpty()) {
      journal.write("I'm not sure if I should work here...");
      warrior.walk();
    }
  }
}

I'm not sure it's the best solution though.

from warriorjs.

@benfletcher logging to a separate file would get the job done. I do think that would separate the logs from their isolated turn though. Were I to want to log out some data and double check it by looking at the level print out for a given turn, I would need both my terminal and a separate file open.

@olistic I think it could make sense to separate the warrior from logging functionality. It seems like anything not game/interaction specific doesn't have a place in that namespace. I do wonder about adding arguments to playTurn. Is that a slippery slope? I'd be worried about another issue like this coming along where some bit of functionality would be added, but done so by appending arguments. Or are we disciplined enough to say that playTurn is always (and only) given a warrior and journal?

from warriorjs.

@olistic (also probably @jakehamilton @benfletcher for interest)

I went ahead and made an example implementation of this because I wanted to see if I could check the enemy type ahead of me with feel() (is this cheating? 👀)

I exposed two functions to the Player instance, this.say(), and this.debug()

// PlayerLoader.createPlayer()
// See other implementations in 'Logger.js', 'ui/printDebugMessage.js', and 'ui/printPlay.js'
player.say = (...messages) => Logger.log(messages.length > 1 ? messages : messages[0]);
player.debug = (...args) => console.log(util.inspect(args, {showHidden: false, depth: null, colors: true}));

These are the results of calling

this.debug(warrior.feel())
this.say(warrior.feel().toJSON())

say() uses the Logger instance to pass what is supposed to be a short/concise log statement into the player's turn:

debug() allows you do a more thorough inspection, outside of the CLI's "in-game" UI:

The code probably isn't very good, it's a LARGE project and I did the best I could with what I could make out and infer from the stuff you'd already written.

If you want to take a look, it's here:
https://github.com/GavinRay97/warriorjs/tree/feature/logger

Code Diff:
master...GavinRay97:feature/logger

from warriorjs.

Just noticed there's a bug with the console styling switching between bold and not. I'll fix that later 😂

from warriorjs.

@pajtai Ahhh, I didn't think of that. I thought about running with the --inspect command but then realized warriorjs was a bin and not ran via Node. That's much more clever, though! 👍

from warriorjs.

@jakehamilton @benfletcher @GavinRay97 @pajtai I decided to implement a basic solution for this issue in #102. Please check it out (and maybe try it), any feedback is appreciated.

from warriorjs.

warriorjs v3.0.0 is live on npm but doesn't seem to enable this think ability in my profile. Is it hidden because it's not perfect yet or do I have to do something to my profile to refresh and have access to the new ability?

from warriorjs.

@cavejay you’re probably installing the old package, warriorjs, instead of @warriorjs/cli.

from warriorjs.