profile
viewpoint
Michal Dziekonski mdziekon Warsaw, Poland Frontend developer (React / TypeScript)

mdziekon/UniEngine 43

OGame-like Game Engine

mdziekon/eiti-alhe-firefly 2

Firefly Algorithm implemented in R

mdziekon/cleave.js 1

Format input text content when you are typing...

mdziekon/eiti-tin-ftp-stattr 1

A simple system providing FTP traffic data collection & analysis.

mdziekon/craco 0

Create React App Configuration Override, an easy and comprehensible configuration layer for create-react-app

mdziekon/eiti-aisdi-business-relations-analysis 0

Projekt grupowy na przedmiot "Algorytmy i struktury danych"

mdziekon/eiti-soi-lab3-semaphores 0

A project made for Operating Systems class laboratories, using semaphores to solve a inter-process synchronization problem

mdziekon/eiti-soi-lab4-monitors 0

A project made for Operating Systems class laboratories, using monitors to solve an inter-process synchronization problem

mdziekon/eiti-tkom-interpreter 0

A project made for Compilation Techniques class - an interpreter of a simple language with built-in matrices type

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha c481614d112b1e41a4bc77a7686960d4daf1e36b

GH-126 Properly initialize necessary accumulators

view details

Michal Dziekonski

commit sha 57084a04de57349342428e8831d93254323fb15a

GH-126 Prepare helper functions dealing with threadability of messages

view details

Michal Dziekonski

commit sha 6f99c63fdb5aac2cd3c11f1f7bc98c67495a9f96

GH-126 Create message results unpacker

view details

Michal Dziekonski

commit sha ff97d01b08e67a9af0be8cc55dd6989642495b5d

GH-126 Use the new unpacker to populate necessary details

view details

Michal Dziekonski

commit sha c9609e91bf16613899d459e7ab200a2b49dff312

GH-126 Create thread messages fetcher

view details

Michal Dziekonski

commit sha 87a94a6e1b774bb2de2fe8615472f088dc72e670

GH-126 Use the threaded messages fetcher

view details

Michal Dziekonski

commit sha 22434bd3f89017b6d7dd6a7c42d6192fa3590be8

GH-126 Create thread lengths fetcher

view details

Michal Dziekonski

commit sha 24f869c061b5a7c48c5510fd9107802458676fe7

GH-126 Use the new lengths fetcher

view details

push time in 9 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 28abfe18e16a4240dcba97c50de49feb1b093731

GH-126 Share message type coloring code

view details

Michal Dziekonski

commit sha e1ed39360dec6c969287cc49f7c0c5da1226d0fd

GH-126 Move messages count fetchin to an util function

view details

Michal Dziekonski

commit sha b3d8d1694b4dd2757444751c5213e68b5a598660

GH-126 Move user messages fetching to an util func

view details

Michal Dziekonski

commit sha 269602abe8899f01ef3968cd4996cef80ae77bd1

GH-126 Simplify current page no normalization

view details

Michal Dziekonski

commit sha 0f4094841949500d1cf23eb9bc54a4c4f44bfedb

GH-126 Reuse page no normalization

view details

push time in 11 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 9418a50a8b22e6df5f695399ce3e45fc6ba483e4

GH-126 Remove unused consts map

view details

push time in 12 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 3fdb63b8ac08c4823ded57cd8c941c86ba9ae881

GH-126 Move message content formatting to a separate util

view details

Michal Dziekonski

commit sha 1c143d83cb1d1ea7c75bcdb59e60dbe2aa00dac9

GH-126 Reuse formatUserMessageContent as much as possible

view details

Michal Dziekonski

commit sha 548ad605d95ba3579df337a29b42f909a6ac07c0

GH-126 Remove obsolete include

view details

Michal Dziekonski

commit sha 393714e5f7da03223a6df62d8d11cac788978f63

GH-126 Stub missing quote styling transform

view details

Michal Dziekonski

commit sha bcfe631841a525d9da915eadcf7c00fdf8232610

GH-126 Rename utils file to accomodate for more formatters

view details

Michal Dziekonski

commit sha d0422b574d43c553bd964957af8c2e14ea82757b

GH-126 Move sender label formatting to a separate util

view details

Michal Dziekonski

commit sha 051864f31ac83019d6fec0f231c50ead9b1ca218

GH-126 Reuse formatUserMessageSenderLabel()

view details

Michal Dziekonski

commit sha 3608f1d06b63e9df4418afa78401d825398f49e8

GH-126 Reuse buttons builder

view details

push time in 12 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 9a28fb33cf9367e592bb9453a902c026480bc26b

GH-126 Move buttons creation to an util function

view details

Michal Dziekonski

commit sha 0516fd9eaa5e07ac42c28a511e7102c4d3dc15e6

GH-126 Do not overwrite the original message content

view details

Michal Dziekonski

commit sha e366411c11117f2a03a2ff141439feffe07fd993

GH-126 Use DOM element builders to create buttons

view details

push time in 14 days

PR opened mdziekon/UniEngine

Refactor messages displaying code pr:enhancement_request

Summary:

messages.php is a huge file that needs to be split into smaller chunks to make it more manageable and flexible.

Changelog:

  • [ ] Split messages displaying code into separate, purpose-built functions

Is migration required?

NO

Related issues or PRs:

  • #126
+300 -139

0 comment

4 changed files

pr created time in 15 days

create barnchmdziekon/UniEngine

branch : mdziekon/gh-126/msgsys-refactor-part3

created branch time in 15 days

push eventmdziekon/eslint

Michał Dziekoński

commit sha ce6be3325c8862670753d17ee84f889a0ab2fca3

Update: support async arrow fn in function-paren-newline (fixes #13728)

view details

push time in 21 days

pull request commenteslint/eslint

Fix: support async arrow functions in `function-paren-newline`

@mdjermanovic sure thing, I've pushed an amended commit message.

mdziekon

comment created time in 21 days

push eventmdziekon/eslint

Michał Dziekoński

commit sha 26c10ef1355ccf59f61348ff29705e04cb34911f

Update: support async arrow functions in function-paren-newline (fixes #13728)

view details

push time in 21 days

push eventmdziekon/eslint

Michał Dziekoński

commit sha ce093eacc47febca58efd9d42cc61050eadbe5c5

Fix: support async arrow functions in function-paren-newline (fixes #13728)

view details

push time in 21 days

PR opened eslint/eslint

Fix: support async arrow functions in `function-paren-newline`

Prerequisites checklist

What is the purpose of this pull request? (put an "X" next to an item)

[x] Bug fix (#13728)

What changes did you make? (Give an overview)

Added support for the async ArrowFunctionExpression in function-paren-newline. This fixes the issue where source analysis for this node type wrongly assumes that it does not have an opening parenthesis (because it thinks that in this case, opening paren is always the first token, which since ES2017 is no longer a guarantee).

Is there anything you'd like reviewers to focus on?

No

+370 -1

0 comment

2 changed files

pr created time in 21 days

create barnchmdziekon/eslint

branch : gh-13728

created branch time in 21 days

issue openedeslint/eslint

[`function-paren-newline`] Missing support for async arrow functions

Tell us about your environment

  • ESLint Version: 7.10.0
  • Node Version: 14.7.0
  • npm Version: 6.14.7

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using?

default

Please show your full configuration:

<details> <summary>Configuration</summary>

module.exports = {
    rules: {
        'function-paren-newline': [
            'error',
            'multiline',
        ],
    },
};

</details>

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

<!-- Paste the source code below: -->

const test = async (foo,
    bar) => {};

<!-- Paste the command you used to run ESLint: -->

./node_modules/.bin/eslint src/test.js

What did you expect to happen?

ESLint should report the following problems:

  1:20  error  Expected newline after '('                             function-paren-newline
  2:8   error  Expected newline before ')'                            function-paren-newline

ESLint should be able to autofix this issue by inserting missing newlines.

What actually happened? Please include the actual, raw output from ESLint.

No errors were reported.

Are you willing to submit a pull request to fix this bug?

Yes

Cause of the problem

In this rule's getParenTokens function, when analysing ArrowFunctionExpression, the code wrongly assumes that any arrow function always starts with a parenthesis opening. Since the introduction of async / await syntax, this is no longer the case.

created time in 21 days

push eventmdziekon/eslint

ESLint Jenkins

commit sha 60eafc15075f38955cb6816bf1f0bcf6e6e6d3a6

Sponsors: Sync README with website

view details

ESLint Jenkins

commit sha 2f27836e989f3dfe236e34054b490febc359bc48

Sponsors: Sync README with website

view details

Milos Djermanovic

commit sha b487164d01dd0bf66fdf2df0e374ce1c3bdb0339

Docs: add exponentiation operators to operator-assignment documentation (#13577)

view details

Dieter Luypaert

commit sha 66442a9faf9872db4a40f56dde28c48f4d02fc7b

Update: Add no-magic-numbers 'ignoreDefaultValues' option (#12611) * Fix: Add no-magic-numbers 'ignoreDefaultValues' option * Test: Add cases for `no-magic-numbers` array destructuring * Chore: consistent function parameters for `no-magic-numbers` * Test: default option `no-magic-numbers` * Docs: add `no-magic-numbers` array destructuring example * Fix: add `no-magic-numbers` additional check * Test: add `no-magic-numbers` test * Docs: fix typo * Chore: move ignoreDefaultValues option check * Docs: add line-break * Test: Add test for default function parameter values * Chore: rename function * docs: update JSDoc

view details

Nicholas C. Zakas

commit sha 2bee6d256ae0516c9a9003bb3fdca24ff93253b5

Chore: Mark config-related files (refs #13481) (#13597) * Chore: Mark config-related files (refs #13481) * Fix lint errors * Fix more linting errors

view details

Kai Cataldo

commit sha f954476fb6b0664679c73babd5e8a0647572b81f

Chore: add common 3rd party parsers to issue template (#13596)

view details

YeonJuan

commit sha bdb65ec2e672c9815bee356b61d1cd60a1072152

Chore: add 3rd party parsers in BUG_REPORT template (#13606) * Chore: add 3rd party parsers BUG_REPORT issue template * edit templates/bug-report.md

view details

ESLint Jenkins

commit sha 05074fb2c243e904e8c09d714ad9d084acdd80d2

Sponsors: Sync README with website

view details

Kai Cataldo

commit sha 091e52ae1ca408f3e668f394c14d214c9ce806e6

Upgrade: espree@7.3.0 (refs #13568) (#13609) * Upgrade: espree@7.3.0 * update docs * Update types.js

view details

Patrice Sandhu

commit sha 4111d21a046b73892e2c84f92815a21ef4db63e1

Docs: Fix typo and missing article before noun in docs (#13611) * Docs: Fix typo semicolumns in providing suggestions docs * Docs: Fix missing article before noun

view details

Nicholas C. Zakas

commit sha 82669fa66670a00988db5b1d10fe8f3bf30be84e

Chore: Extract some functionality to eslintrc (refs #13481) (#13613)

view details

Brandon Mills

commit sha 1c35d57b0a5f374cc55f1727a7561bcab1962e83

Docs: Remove stale Keybase 2FA instructions (#13622)

view details

Soobin Bak

commit sha 483bf7f3cc40e0d866798d6ca9ee1c19aa77ddd2

Docs: fix examples in object-curly-newline (#13605) * Docs: consistent example * docs: let a -> empty * docs: add correct example * docs: add function object incorrect example * docs: add object empty correct example * docs: add destruct operation example * style: tab -> space

view details

ESLint Jenkins

commit sha e60ec07fad0c1d4c966f28d214c5379da753ff4e

Sponsors: Sync README with website

view details

Anix

commit sha ed64767859d776145d68145419a61f5379b4dd63

Update: add comment to message in no-warning-comments (fixes #12327) (#13522) * Update: added the comment in no-warning-comments (fixes #12327) * Update: changed display logic * Update: changed the char limit and early break * Chore: refactor the logic * Chore: smallchanges * Chore: refactor small * Chore: added tests and refactor * Chore: correct tests

view details

Anix

commit sha 3439fea5c0ed330d01d874b0c9df51dd51ae792c

Update: support numeric-separator in no-loss-of-precision (refs #13568) (#13574) * Update: support numeric-separator in no-loss-of-precision (refs #13568) * Chore: changed the function jsdocs description * Chore: removed extra getRaw calls * Chore: update lib/rules/no-loss-of-precision.js Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com> Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>

view details

sodam

commit sha 96b11a0717bf32b94ec768611574372320fb774b

Update: Add exceptionPatterns to id-length rule (fixes #13094) (#13576) * Add #13099 to continue * Delete unnecessary 'parserOptions' * Add invalid test with an identifier that doesn't match configured pattern * Add valid test with multiple exception patterns * Add a function that extracted 'return' below * Docs: Add "exceptionPatterns" to "id-length" rule * Add a function that extracted 'return' below Docs: Add "exceptionPatterns" to "id-length" rule * Update : modify wrong example * Update: all RegExp instance create in "create(context)" * Update: more simpler by refactoring some codes * Update docs/rules/id-length.md Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com> * Update: modify the function name * Update: Add a valid test with multiple patterns where the first doesn't match. Co-authored-by: Milos Djermanovic <milos.djermanovic@gmail.com>

view details

Milos Djermanovic

commit sha 0003dc0f966f2b47555595586f84eb3163cb0179

Update: support numeric separators (refs #13568) (#13581) * update astUtils.isDecimalInteger and astUtils.isDecimalIntegerNumericToken * add tests and comment for prefer-numeric-literals * add tests for quote-props

view details

Milos Djermanovic

commit sha 88a9ade7643bb166efbab45cee15f3269496f4be

Update: add es2021 environment (refs #13602) (#13603) * Update: add es2021 environment (refs #13602) * Add no-undef test

view details

Brandon Mills

commit sha a32032430a0779a4e3b2d137d4d0682844084b82

Chore: Test formatted integers in no-dupe-keys (refs #13568) (#13626) This adds tests for numeric literal object keys that aren't digit-only decimal integer literals, including ES6 binary and octal literals, ES2020 bigint literals, and ES2021 numeric separators. The valid tests have similar-looking literals that are distinct keys, and the invalid tests have differently-formatted literals that result in duplicate keys.

view details

push time in 22 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 2f9f4e394881125649911828046415658a47891c

GH-126 Move ignore system checks to a separate validator function

view details

Michal Dziekonski

commit sha b1f17f45b5174b2f94ca9657c5a53ce245941ea6

GH-126 Move actual message sending to its own utility

view details

Michal Dziekonski

commit sha a70e2592531bb6269aeb1cd16b7b150c9f889736

GH-126 Move reply form data fetching to utilities

view details

Michal Dziekonski

commit sha 41e73c6d5ebcbe525d7b6ca3887c835cf794467a

GH-126 Add recipient data fetchers, by uid & by name

view details

Michal Dziekonski

commit sha 6c913b4d6e1f971ea056d104b5af9a13886d96fd

GH-126 When fetching data for reply, create next subject as well

view details

Michal Dziekonski

commit sha a01e0026caf2d311dfc5a63ac8f14bd5df8b9eef

GH-126 Create unified message data normalization utility

view details

Michal Dziekonski

commit sha 8bd1ea29ed293b65eb1f0d9577f4aae9feaf778c

GH-126 Simplify message sending code in message.php by delegating to utilities

view details

Michal Dziekonski

commit sha 581e4ccaca95a686bec1444b0f5a9d9e32608de4

GH-126 Normalizer should allow max length customizations

view details

Michal Dziekonski

commit sha 394b00bc9fdb23993134b6d485f26dccfdb200d2

GH-126 Remove useless comment

view details

Michal Dziekonski

commit sha 94ba85745897700652cb2c9da00669f2c14d9b8d

GH-126 Move message sending to its own function

view details

Michal Dziekonski

commit sha 94783318c642f597b4bb91345f653bf8f3b625e2

GH-126 Remove unreachable code

view details

Michal Dziekonski

commit sha 0fb7de838bf54462589f48a918587ba45ea46d1e

GH-126 Set next reply subject only on success

view details

Michal Dziekonski

commit sha 500c055a64ecb098db5cbdac403e2c635b6367d7

GH-126 Lock username & subject when replying and there's no major reply problem

view details

Michal Dziekonski

commit sha 033a4243a13c01b537950f3aba24aae989333f38

GH-126 Final code improvements

view details

Michal Dziekonski

commit sha e331732dc8f849140e370ce52e8a89a9b6649313

Merge pull request #128 from mdziekon/mdziekon/gh-126/msgsys-refactor-part2

view details

push time in 25 days

PR merged mdziekon/UniEngine

Refactor messages sending form pr:enhancement_request

Summary:

messages.php is a huge file that needs to be split into smaller chunks to make it more manageable and flexible.

Changelog:

  • [x] Split messages sending code into separate, purpose-built functions
  • [x] Move general handler out of messages.php to a separate handler function

Is migration required?

NO

Related issues or PRs:

  • #126
+910 -274

0 comment

12 changed files

mdziekon

pr closed time in 25 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 033a4243a13c01b537950f3aba24aae989333f38

GH-126 Final code improvements

view details

push time in 25 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 0fb7de838bf54462589f48a918587ba45ea46d1e

GH-126 Set next reply subject only on success

view details

Michal Dziekonski

commit sha 500c055a64ecb098db5cbdac403e2c635b6367d7

GH-126 Lock username & subject when replying and there's no major reply problem

view details

push time in 25 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 94783318c642f597b4bb91345f653bf8f3b625e2

GH-126 Remove unreachable code

view details

push time in 25 days

PR opened mdziekon/UniEngine

Refactor messages sending form

Summary:

messages.php is a huge file that needs to be split into smaller chunks to make it more manageable and flexible.

Changelog:

  • [x] Split messages sending code into separate, purpose-built functions
  • [x] Move general handler out of messages.php to a separate handler function

Is migration required?

NO

Related issues or PRs:

  • #126
+897 -267

0 comment

12 changed files

pr created time in 25 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 94ba85745897700652cb2c9da00669f2c14d9b8d

GH-126 Move message sending to its own function

view details

push time in 25 days

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 41e73c6d5ebcbe525d7b6ca3887c835cf794467a

GH-126 Add recipient data fetchers, by uid & by name

view details

Michal Dziekonski

commit sha 6c913b4d6e1f971ea056d104b5af9a13886d96fd

GH-126 When fetching data for reply, create next subject as well

view details

Michal Dziekonski

commit sha a01e0026caf2d311dfc5a63ac8f14bd5df8b9eef

GH-126 Create unified message data normalization utility

view details

Michal Dziekonski

commit sha 8bd1ea29ed293b65eb1f0d9577f4aae9feaf778c

GH-126 Simplify message sending code in message.php by delegating to utilities

view details

Michal Dziekonski

commit sha 581e4ccaca95a686bec1444b0f5a9d9e32608de4

GH-126 Normalizer should allow max length customizations

view details

Michal Dziekonski

commit sha 394b00bc9fdb23993134b6d485f26dccfdb200d2

GH-126 Remove useless comment

view details

push time in a month

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha b1f17f45b5174b2f94ca9657c5a53ce245941ea6

GH-126 Move actual message sending to its own utility

view details

Michal Dziekonski

commit sha a70e2592531bb6269aeb1cd16b7b150c9f889736

GH-126 Move reply form data fetching to utilities

view details

push time in a month

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha d37d7bdd59243ecbbbe4335bb6c9f88b45e3d4c7

wip

view details

push time in a month

create barnchmdziekon/UniEngine

branch : mdziekon/gh-126/msgsys-refactor-part2

created branch time in a month

pull request commentgsoft-inc/craco

Add a warning about API functions

@patricklafrance I agree that an additional validator is also a nice thing to have, therefore I've added it to all API functions your mentioned. However, I do not agree that this should replace the documentation piece, simply because it's better to know about this upfront rather than being surprised by it once we first run any tool that consumes these configs. Or, in other words, principle of least surprise applies to these validators.

mdziekon

comment created time in a month

push eventmdziekon/craco

Michał Dziekoński

commit sha 38a8e35bdabb912c6c0393f8173fad9658c1bf40

Add a validator for cracoConfig preventing it from being a function

view details

push time in a month

push eventmdziekon/craco

Michał Dziekoński

commit sha 2963c1f22f85e7facae6fe4520505854b226c4cd

Add a validator for cracoConfig preventing it from being a function

view details

push time in a month

PR opened gsoft-inc/craco

Add a warning about API functions

Recently I was messing around with createJestConfig API function to add some additional config props for the CI environment on a project I'm currently working on. However I've stumbled upon a lot of weird problems when certain props from craco.config.js were simply not visible to Jest. After tedious debugging session I've discovered a rather simple reason for that - my craco.config.js file exports a config function, which apparently is not supported by createJestConfig and that fact is neither documented, not reported as an error.

I don't know if this is intentional or not, but I figured that it would be good to at least mention that fact in the API's documentation.

+4 -0

0 comment

1 changed file

pr created time in a month

push eventmdziekon/craco

Michal Dziekonski

commit sha 4696c49ea17b777a0c89f3c09a26d261c12f40f4

Add a warning about API functions

view details

push time in a month

fork mdziekon/craco

Create React App Configuration Override, an easy and comprehensible configuration layer for create-react-app

https://gsoft.com

fork in a month

issue commenttypescript-eslint/typescript-eslint

[no-unnecessary-condition] Wrong report "Unnecessary conditional"

@bradzacher yes, this regression is caused by the mentioned Pull Request. In your code review, you were originally right when you mentioned that the unary expression checker should simply call checkNode on the arguments (https://github.com/typescript-eslint/typescript-eslint/pull/2382/files#r468215593, I believe you have to expand it yourself unfortunately). The problem was not with the logic of checkNode itself, but rather the error message, which to be correct, should be somehow flipped.


The problem with checkIfUnaryNegationExpressionIsNecessaryConditional is that it incorrectly assumes that, for example, when the expression is possibly truthy, it therefore must always be truthy (hence it reports always falsy, because the condition is negated), which is not true.

Not only that, this function also does not check for other edge cases that checkNode already handles. For example, let's consider the following code:

declare function doSomething(): void;
declare function getBoolean(): boolean;
declare function getUnknown(): unknown;

function runTest(): void {
    const booleanTyped = getBoolean();
    const unknownTyped = getUnknown();

    if (!(booleanTyped || unknownTyped)) {
        doSomething();
    }
}

runTest();

The condition is necessary, because ultimately the result of the unary's arguments might be of type unknown. In this scenario, the newly introduced code reports a false positive:

error Unnecessary conditional, value is always falsy

In other words - checkNode(node.argument) is probably the best choice since it already handles different edge cases, but it would need to take an additional parameter to allow final message to be flipped (IIUC, this could also be possible by traversing the node's hierarchy backwards, but I wonder if detecting nested negations would be as easy as with boolean flag flipping, and if "stop condition" could be easily determined).

If my analysis is correct, I think #2382 should be reverted and reimplemented in a different way (a couple more test cases to check for this regression wouldn't hurt as well). Fixing and extending checkIfUnaryNegationExpressionIsNecessaryConditional would introduce unnecessary code duplication.

juergenzimmermann

comment created time in 2 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 1fabb61e5ad2abaed30f92cd55887a5783a4b13a

GH-126 Create batch messages deletion function in Messages module

view details

Michal Dziekonski

commit sha 74c38e17460ca9eaf7fa1dd7db0bc63ee9ff2da7

GH-126 Delegate "delete all messages" to Messages\Commands\batchDeleteUserMessages()

view details

Michal Dziekonski

commit sha 887d59c4b173da38418c36d0c8db3d6ed0c78ffe

GH-126 Fix incorrect assignment of messages to the output arrays

view details

Michal Dziekonski

commit sha d614d9bf41b8eb57c04579fc248cf9fd7b15bd3c

GH-126 Allow to limit batch deletion to a specific category of messages

view details

Michal Dziekonski

commit sha 7c10df78dfb3a2224c7304394eb5081044a34f82

GH-126 Delegate batch deletions in category to Messages\Commands\batchDeleteUserMessages()

view details

Michal Dziekonski

commit sha 0d1065ee86ac5a7091f6788d62ba194aca2c550f

GH-126 Code style simplification

view details

Michal Dziekonski

commit sha 3be8e726a21f33a34c435705bfb5729670f51ebc

GH-126 Rename batch deleter to better reflect what is its purpose

view details

Michal Dziekonski

commit sha 0aed929eb8cd82101a848d36d9a366a762520281

GH-126 Fix query

view details

Michal Dziekonski

commit sha b28b63851288f97f9176140fffc44400dfbbab52

GH-126 Create batch message deleter by their IDs

view details

Michal Dziekonski

commit sha 053bcef28b470c411d62b330439125095a125b91

GH-126 Delegate batch deletions by selected IDs to Messages\Commands\batchDeleteMessagesByID

view details

Michal Dziekonski

commit sha e89f6bb8acb910c6760c7703239b1309e56d10eb

GH-126 Delegate batch deletions by non-selected IDs to Messages\Commands\batchDeleteMessagesByID

view details

Michal Dziekonski

commit sha 3896e39c8359ce03420583acbf0497c47497aac3

GH-126 Create batch message "reader"

view details

Michal Dziekonski

commit sha e4644d6453191d8533c9af9edead3be0a3e32623

GH-126 Delegate batch message "mark as read" to Messages\Commands\batchMarkMessagesAsRead()

view details

Michal Dziekonski

commit sha b3d1b579a875c05fd243a6ed334ac28e47b8011e

GH-90 Move shared code to "utils" namespace

view details

Michal Dziekonski

commit sha 07e262a8728a5e2cff9e78e1542d88b968f0401f

GH-90 Move duplicated batch deletion code into a separate module unit

view details

Michal Dziekonski

commit sha 67c8bb83b442e9d539b3adda30f1523fae1e64ef

GH-90 Allow to lift the prevention of excluded message types removal

view details

Michal Dziekonski

commit sha de7d9f4460de6b37be456faaa36a658a0223d6f7

GH-126 Delegate single selected message deletion to Messages\Commands\batchDeleteMessagesByID()

view details

Michal Dziekonski

commit sha 1bdc4303d6e272d760117989c37e7e27b27cb82a

GH-126 Encapsulate "batch actions" handler into a function (enable short-circuiting)

view details

Michal Dziekonski

commit sha 14152642caa1b6779725ad57a9a531ba7b60fb93

GH-126 Move batch action handler to its own user command handling file

view details

Michal Dziekonski

commit sha 7df4fdbee2958ac0800918202ba6af95dcacb44e

Merge pull request #127 from mdziekon/mdziekon/gh-126/messaging-cmds-refactor

view details

push time in 2 months

PR merged mdziekon/UniEngine

Refactor messages batch commands handling pr:enhancement_request

Summary:

messages.php is a huge file that needs to be split into smaller chunks to make it more manageable and flexible.

Changelog:

  • [x] Split batch message-related commands into separate, purpose-built functions
  • [x] Move general handler out of messages.php to a separate handler function
  • [x] Share code between similar message deleting functionalities

Is migration required?

NO

Related issues or PRs:

  • #126
+634 -401

0 comment

12 changed files

mdziekon

pr closed time in 2 months

PR opened mdziekon/UniEngine

Refactor messages batch commands handling pr:enhancement_request

Summary:

messages.php is a huge file that needs to be split into smaller chunks to make it more manageable and flexible.

Changelog:

  • [x] Split batch message-related commands into separate, purpose-built functions
  • [x] Move general handler out of messages.php to a separate handler function
  • [x] Share code between similar message deleting functionalities

Is migration required?

NO

Related issues or PRs:

  • #126
+634 -401

0 comment

12 changed files

pr created time in 2 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 1bdc4303d6e272d760117989c37e7e27b27cb82a

GH-126 Encapsulate "batch actions" handler into a function (enable short-circuiting)

view details

Michal Dziekonski

commit sha 14152642caa1b6779725ad57a9a531ba7b60fb93

GH-126 Move batch action handler to its own user command handling file

view details

push time in 2 months

issue commenteslint/eslint

[`array-bracket-newline`] Add option `consistent` to the object configuration

Thanks for the answer. Even though I've already closed the issue as this is basically a lost cause here, I still have a question.

Is there currently any equivalent of ESLint's stylistic rules already forked in a form of a plugin, or did anyone from the maintainers consider doing this, even in an unofficial manner to jump-start this kind of project? The biggest problem with this new approach that I can see is the "community maintainability" of such plugins, or rather, new plugins like this one would be - even though they would be based on existing, ESLint's rules, they would still need to gain some traction in order to thrive. Obviously, even ESLint had to deal with this in the past, but if it would be possible to make it a bit easier for new plugins based on the old, frozen rules, it could potentially speed up community building process. Also, don't get me wrong - this idea of mine is not about making maintainers of ESLint to maintain yet another project, but rather to make a statement to the community that "this code was once maintained by us, we don't want to do this anymore in core, but this is a place where you can continue extending it out of core".

mdziekon

comment created time in 2 months

issue closedeslint/eslint

[`array-bracket-newline`] Add option `consistent` to the object configuration

What rule do you want to change?

array-bracket-newline

Does this change cause the rule to produce more or fewer warnings?

By default: no change. When option enabled: fewer.

How will the change be implemented? (New option, new default behavior, etc.)?

New option

Please provide some example code that this change will affect:

// .eslintrc (fragment)
{
    'rules': [
        'array-bracket-newline': {
            'error',
            {
                'multiline': true,
            }
        }
    ]
}
const test1 = [
    'test',
];

const test2 = [ 'test' ];

const test3 = [
    'test1',
    'test2',
    'test3',
];

What does the rule currently do for this code?

It reports two errors for the test1 array:

1:15 error There should be no linebreak after '[' array-bracket-newline 3:1 error There should be no linebreak before ']' array-bracket-newline

What will the rule do after it's changed?

It won't report any errors, meaning that it will allow for an array to either be multiline with new lines between elements, or force consistent line breaks for opening and closing brackets.

Important note: this proposal is NOT about changing the behaviour of the already existing consistent (string) variant of this rule, but about a new property to the object-like configuration. Please read my explanation in its entirely before jumping to conclusions about possible redundancy.

The reasoning behind this is as follows:

  • The multiline: true option forces to either write all elements of an array in one line (one after another), or split them into multiple lines. This behaviour is already implemented and well-documented (... requires line breaks if there are line breaks inside elements or between elements.). This however, does not allow one-line element enumerations (whether it's just one or multiple elements) to be started from a new line (when looking at the bracket opening -> first element), because now the rule does not consider this situation to require line breaks, and in turn forbids line breaks entirely.
    • The string-like option [ 'error', 'consistent' ] is not able to achieve the same effect, because even though it allows for one-liners to start from a new line, it only checks the brackets, disregarding whether there are any line breaks between elements. multiline checks both brackets and elements line breaks. To better visualise this, using only the string-like option consistent treats this code as valid:
    const test = [ 'test',
        'test',
        'test',
        'test' ];
    
  • The consistent: true option would additionally force to consistently open & close brackets in the same line as all the elements, or in new lines, regardless of whether the elements are actually split or not (as a whole). Therefore, it would not affect the multiline option, but rather provide additional constraint with accordance to how the object-shaped configuration for this rule is supposed to work (... Requires line breaks if any of properties is satisfied.).
  • Adding the consistent option to the object-shaped configuration would additionally bring this rule closer to how object-curly-newline works (which already does provide what I propose here).

To prevent breaking changes, this option would have to be set to false by default. For consistency with object-curly-newline, it could be put into consideration to enable it by default, but that's a matter for another PR.

There was a discussion similar to this one in the past (https://github.com/eslint/eslint/issues/12736), however I believe that either the author did not describe their intent correctly, or the ESLint's contributors were too absorbed with the proposed "multiline option extension", so hopefully my explanation will bring a new perspective to this old proposal.

Are you willing to submit a pull request to implement this change?

Yes, I believe this can be achieved in a similar fashion to how object-curly-newline does this and can do it in my spare time.

closed time in 2 months

mdziekon

issue openedeslint/eslint

[`array-bracket-newline`] Add option `consistent` to the object configuration

What rule do you want to change?

array-bracket-newline

Does this change cause the rule to produce more or fewer warnings?

By default: no change. When option enabled: fewer.

How will the change be implemented? (New option, new default behavior, etc.)?

New option

Please provide some example code that this change will affect:

// .eslintrc (fragment)
{
    'rules': [
        'array-bracket-newline': {
            'error',
            {
                'multiline': true,
            }
        }
    ]
}
const test1 = [
    'test',
];

const test2 = [ 'test' ];

const test3 = [
    'test1',
    'test2',
    'test3',
];

What does the rule currently do for this code?

It reports two errors for the test1 array:

1:15 error There should be no linebreak after '[' array-bracket-newline 3:1 error There should be no linebreak before ']' array-bracket-newline

What will the rule do after it's changed?

It won't report any errors, meaning that it will allow for an array to either be multiline with new lines between elements, or force consistent line breaks for opening and closing brackets.

Important note: this proposal is NOT about changing the behaviour of the already existing consistent (string) variant of this rule, but about a new property to the object-like configuration. Please read my explanation in its entirely before jumping to conclusions about possible redundancy.

The reasoning behind this is as follows:

  • The multiline: true option forces to either write all elements of an array in one line (one after another), or split them into multiple lines. This behaviour is already implemented and well-documented (... requires line breaks if there are line breaks inside elements or between elements.). This however, does not allow one-line element enumerations (whether it's just one or multiple elements) to be started from a new line (when looking at the bracket opening -> first element), because now the rule does not consider this situation to require line breaks, and in turn forbids line breaks entirely.
    • The string-like option [ 'error', 'consistent' ] is not able to achieve the same effect, because even though it allows for one-liners to start from a new line, it only checks the brackets, disregarding whether there are any line breaks between elements. multiline checks both brackets and elements line breaks. To better visualise this, using only the string-like option consistent treats this code as valid:
    const test = [ 'test',
        'test',
        'test',
        'test' ];
    
  • The consistent: true option would additionally force to consistently open & close brackets in the same line as all the elements, or in new lines, regardless of whether the elements are actually split or not (as a whole). Therefore, it would not affect the multiline option, but rather provide additional constraint with accordance to how the object-shaped configuration for this rule is supposed to work (... Requires line breaks if any of properties is satisfied.).
  • Adding the consistent option to the object-shaped configuration would additionally bring this rule closer to how object-curly-newline works (which already does provide what I propose here).

To prevent breaking changes, this option would have to be set to false by default. For consistency with object-curly-newline, it could be put into consideration to enable it by default, but that's a matter for another PR.

There was a discussion similar to this one in the past (https://github.com/eslint/eslint/issues/12736), however I believe that either the author did not describe their intent correctly, or the ESLint's contributors were too absorbed with the proposed "multiline option extension", so hopefully my explanation will bring a new perspective to this old proposal.

Are you willing to submit a pull request to implement this change?

Yes, I believe this can be achieved in a similar fashion to how object-curly-newline does this and can do it in my spare time.

created time in 2 months

fork mdziekon/eslint

Find and fix problems in your JavaScript code.

https://eslint.org

fork in 2 months

issue commenttypescript-eslint/typescript-eslint

[no-unnecessary-condition] False positive with nullish coalescing

No problem, I understand where did this first question come from.

I was actually going to post my findings (from my little debugging session), but it looks like you already solved the issue, cool :)

mdziekon

comment created time in 2 months

issue commenttypescript-eslint/typescript-eslint

[no-unnecessary-condition] False positive with nullish coalescing

I'm using strict which enables strictNullChecks. The second test run (the one using plugin's RC version) was run directly using the attached test suite, and as far as I know, it also has this flag enabled.

mdziekon

comment created time in 2 months

issue openedtypescript-eslint/typescript-eslint

[no-unnecessary-condition] False positive with nullish coalescing

Repro

{
    "rules": {
        "@typescript-eslint/no-unnecessary-condition": ["error"]
    }
}
function test(testVal?: boolean) {
    if (testVal ?? true) {
        console.log('test');
    }
}

Expected Result

No ESLint errors reported (condition inside the function is falsy only when we explicitly pass testVal = false).

Actual Result

2:20 error Unnecessary conditional, value is always truthy @typescript-eslint/no-unnecessary-condition

Additional info

I've noticed this recently when reading about additional options introduced in #1983, namely allowComparingNullableBooleansToFalse. With that option set to false, code like this:

function test(testVal?: boolean) {
    if (testVal !== false) {
        console.log('test');
    }
}

... turns into this with an autofix:

function test(testVal?: boolean) {
    if ((testVal ?? true)) {
        console.log('test');
    }
}

This is a valid transformation, since there should be only one situation when console.log() is run - when the testVal argument was explicitly set to false. Therefore, no-unnecessary-condition incorrectly reports that nullish coalescing is not needed here.

Versions

package version
@typescript-eslint/eslint-plugin 3.9.0
@typescript-eslint/parser 3.9.0
TypeScript 3.9.7
ESLint 7.6.0
node 14.7.0
npm 6.14.7
package version
@typescript-eslint/eslint-plugin 4.0.0-rc (2edbca380bd8f317cd96bac0df5030ddcd14a6af)
@typescript-eslint/parser 4.0.0-rc (2edbca380bd8f317cd96bac0df5030ddcd14a6af)
TypeScript 4.0.0-beta
ESLint 7.2.0
node 14.7.0
npm 6.14.7

created time in 2 months

PR opened typescript-eslint/typescript-eslint

docs: document additional allow options in no-empty-function

This PR adds missing pieces of the no-empty-function documentation, where the TS-specific allow entries were completely omitted. It adds both a general overview of the extended Options object (as pseudo-code), and per entry descriptions with examples (taken directly from test cases).

+54 -0

0 comment

1 changed file

pr created time in 2 months

create barnchmdziekon/typescript-eslint

branch : docs/no-empty-function-new-options

created branch time in 2 months

issue commenttypescript-eslint/typescript-eslint

[naming-convention] Can't use array of selectors

Hi @bradzacher, you've just closed a duplicate of this issue (#2377), which is totally fine. However, I've included some analysis of the problem, a possible solution and a question about the proposed solution (or rather, the problem itself) that I think needs to be answered or at least discussed. Can you take a look at Additional info section over there and see if you can comment on that? I can copy-paste it here, if you want to maintain continuity.

EvgenyOrekhov

comment created time in 2 months

issue openedtypescript-eslint/typescript-eslint

[naming-convention] Add support for `types` when array of selectors

Repro

{
  "rules": {
    "@typescript-eslint/naming-convention": [
      "error",
      {
        "selector": [ "variable", "property" ],
        "types": [ "boolean" ],
        "format": [ "PascalCase" ],
        "prefix": [ "is", "should", "has", "can", "did", "will" ]
      }
    ]
  }
}
const featureAEnabled = true;

class TestClass {
    featureAEnabled: boolean;
}

Expected Result

Using the specified rule configuration, ESLint is able to verify that my code (variable and class property) does not follow naming convention.

Actual Result

ESLint throws the following error:

Configuration for rule "@typescript-eslint/naming-convention" is invalid:
	Value {"selector":["variable","property"],"types":["boolean"],"format":["PascalCase"],"prefix":["is","should","has","can","did","will"]} should NOT have additional properties.

Looking at the schema code, it's clear that it in fact does not support types (nor modifiers), because this property of the configuration object is placed in a wrong nesting level: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/src/rules/naming-convention.ts#L255-L302

Both modifiers and types should be moved to begin at L281, not L283, at the same nesting level as filter and selector. This looks like a mistake made in the original PR that introduced multi selectors (https://github.com/typescript-eslint/typescript-eslint/pull/2335/files#diff-6c2c7f346f804da11253beb86ccb0211R255), however... (see Additional Info).

Additional Info

At first this problem seems trivial to fix - I've already identified the offending schema lines that should be changed to make it work. However... both types and modifiers are a bit tricky specifiers in multi selector environment, since not every selector has the same types and modifiers available (eg. function selector has no types, while variable has few).

Therefore, changing the schema to what I've already proposed may solve the issue for rule configurations like mine, where every selector used has the same set of types, but it will also leave a validation hole for mixed selectors, leading to... undefined behaviour (probably). I can do that (as in, submit a PR with validation schema adjustment), but since it sounds controversial at best, I would like to hear other peoples' opinions first. I do not know if ESLint's validation schemas support dynamic validation (as it seems like the only logical solution that would satisfy both my needs and the need of configuration correctness; generating all possible permutations is most likely out of the question), but if it does, I'm also willing to work on this as long as someone can provide a bit of guidance on the topic.

Versions

package version
@typescript-eslint/eslint-plugin 3.8.0
@typescript-eslint/parser 3.8.0
TypeScript 3.9.3
ESLint 7.6.0
node 12.18.3
npm 6.14.6

created time in 2 months

fork mdziekon/typescript-eslint

:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript

https://typescript-eslint.io

fork in 2 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 3896e39c8359ce03420583acbf0497c47497aac3

GH-126 Create batch message "reader"

view details

Michal Dziekonski

commit sha e4644d6453191d8533c9af9edead3be0a3e32623

GH-126 Delegate batch message "mark as read" to Messages\Commands\batchMarkMessagesAsRead()

view details

Michal Dziekonski

commit sha b3d1b579a875c05fd243a6ed334ac28e47b8011e

GH-90 Move shared code to "utils" namespace

view details

Michal Dziekonski

commit sha 07e262a8728a5e2cff9e78e1542d88b968f0401f

GH-90 Move duplicated batch deletion code into a separate module unit

view details

Michal Dziekonski

commit sha 67c8bb83b442e9d539b3adda30f1523fae1e64ef

GH-90 Allow to lift the prevention of excluded message types removal

view details

Michal Dziekonski

commit sha de7d9f4460de6b37be456faaa36a658a0223d6f7

GH-126 Delegate single selected message deletion to Messages\Commands\batchDeleteMessagesByID()

view details

push time in 3 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 3be8e726a21f33a34c435705bfb5729670f51ebc

GH-126 Rename batch deleter to better reflect what is its purpose

view details

Michal Dziekonski

commit sha 0aed929eb8cd82101a848d36d9a366a762520281

GH-126 Fix query

view details

Michal Dziekonski

commit sha b28b63851288f97f9176140fffc44400dfbbab52

GH-126 Create batch message deleter by their IDs

view details

Michal Dziekonski

commit sha 053bcef28b470c411d62b330439125095a125b91

GH-126 Delegate batch deletions by selected IDs to Messages\Commands\batchDeleteMessagesByID

view details

Michal Dziekonski

commit sha e89f6bb8acb910c6760c7703239b1309e56d10eb

GH-126 Delegate batch deletions by non-selected IDs to Messages\Commands\batchDeleteMessagesByID

view details

push time in 3 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 1fabb61e5ad2abaed30f92cd55887a5783a4b13a

GH-126 Create batch messages deletion function in Messages module

view details

Michal Dziekonski

commit sha 74c38e17460ca9eaf7fa1dd7db0bc63ee9ff2da7

GH-126 Delegate "delete all messages" to Messages\Commands\batchDeleteUserMessages()

view details

Michal Dziekonski

commit sha 887d59c4b173da38418c36d0c8db3d6ed0c78ffe

GH-126 Fix incorrect assignment of messages to the output arrays

view details

Michal Dziekonski

commit sha d614d9bf41b8eb57c04579fc248cf9fd7b15bd3c

GH-126 Allow to limit batch deletion to a specific category of messages

view details

Michal Dziekonski

commit sha 7c10df78dfb3a2224c7304394eb5081044a34f82

GH-126 Delegate batch deletions in category to Messages\Commands\batchDeleteUserMessages()

view details

Michal Dziekonski

commit sha 0d1065ee86ac5a7091f6788d62ba194aca2c550f

GH-126 Code style simplification

view details

push time in 3 months

create barnchmdziekon/UniEngine

branch : mdziekon/gh-126/messaging-cmds-refactor

created branch time in 3 months

issue openedmdziekon/UniEngine

Refactor messaging system to allow more flexibility

Summary

Current messaging system is inflexible in terms of how the message arguments can be presented and transformed before presentation to the user. In certain cases, it leads to bugs like #99, where certain piece of the message is "hardcoded" in the sender's message.

The messaging system should be refactored so that every "system message" could be programmatically transformed before being displayed, based on "facts-only" arguments stored as message's arguments. For example, instead of persisting the label of "origin point type" (Planet / Moon), we should be able to store the type's identifier, and then, when the message is about to be displayed, transform that into appropriate label. Not only this will make this more flexible and resitant to bugs, but also may result in a bit of space saving (however, that might be negated by the persistence format, which will most likely change to just JSON; still, space savings are not a priority anymore, at least not that low-level savings).

Related issues or PRs:

  • #99

created time in 3 months

delete branch mdziekon/UniEngine

delete branch : mdziekon/91/fleet-mission-attack-refactor-part14

delete time in 3 months

delete branch mdziekon/UniEngine

delete branch : mdziekon/90/refactor-expeditions-part01

delete time in 3 months

issue openedmdziekon/UniEngine

Implement autoscaling of expedition's rewards

Request background

In #123 the new and rewritten expeditions system has been merged into master. However, it's "reward system" is currently set to a flat reward value. This value (or values for any new events to be added in #124) should automatically scale based on these criteria:

  • Ships in the fleet (more ships / more expensive ships should yield better rewards; however, there should be an upper limit on that)
  • Server's speeds (resources extraction & overall game speed)
  • Server's owner defined multiplier (additional variable / function for fine tuning on demand)

Related issues or PRs:

  • #90
  • #123

created time in 3 months

issue openedmdziekon/UniEngine

Add more events to expeditions.

Request background

In #123 the new and rewritten expeditions system has been merged into master. However, it brought only two, rather not exciting expedition events: "nothing found" and "resources found". There should be more of these events to make expeditions more entertaining for the players.

Proposed event types:

  • Complete fleet destruction
  • Fight against random enemy forces (weak / similar power / stronger than the player)
    • These fights should somehow contribute to player's statistics
  • Recoverable ships found
  • Dark energy found
  • Nothing found & fleet comes back much later

Related issues or PRs:

  • #90
  • #123

created time in 3 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha ecc63951f8719fe550b40af073b73d5ce8f4e6ad

GH-90 Fix UserDevScanner's statistics building code

view details

Michal Dziekonski

commit sha 27f27d86426c151c5d537f552b35e2563fed2ba0

GH-90 Create basic fleet handling code for the new expeditions system

view details

Michal Dziekonski

commit sha d8d99257901c99b9782b02d170c31bf85cc57a61

GH-90 Fix dev dump creation when iterating over element categories & simplify it

view details

Michal Dziekonski

commit sha de44abacc8e7b121823f7bf7c883bda8513d40ac

GH-90 Create basic randomizers for expeditions

view details

Michal Dziekonski

commit sha 6b5c8ed0ffc303124e65bf0c97c605a33694329a

GH-90 Minor documentation spelling mistake spotted, might as well fix it

view details

Michal Dziekonski

commit sha 47129e33cb68ec3c44db953e33f3d837dc8afe31

GH-90 Add fleet update-related code to the new expedition system (fleet row updates, development log insertion & fleet archive insertion)

view details

Michal Dziekonski

commit sha d66acd9ab50527b63924be4a875c2c60f5cab575

GH-90 Create FleetDestructionReason enum

view details

Michal Dziekonski

commit sha dfa13e418772bd68e41974e9729bfd1228590264

GH-90 Replace all fleet destruction codes with enum values

view details

Michal Dziekonski

commit sha 159e63f9dd9e9060a545540e1dd57d0aeb7b27b7

GH-90 Remove comment from fleet_archive::Fleet_Destroyed_Reason and provide migration for that

view details

Michal Dziekonski

commit sha 6cbd6e554996a458adb7f4bd3623d9ccd5c89eb9

GH-90 Remove last hardcoded pieces of destruction reason codes

view details

Michal Dziekonski

commit sha 5c4afe52b52eb005e3332aca936cd303feb5f837

GH-90 Add basic expedition messages

view details

Michal Dziekonski

commit sha a970c0a46042559da3caa1003781ef571c42fefa

GH-90 Prepare expedition events message creators & their respective messages

view details

Michal Dziekonski

commit sha cf75533a5c009fe556cc3285e07dbd49a8efc623

GH-90 Send expedition result message to the user

view details

Michal Dziekonski

commit sha 22fb99765f5791e9a7edaee22dffcc95eb0aa5df

GH-90 Unify messages sending

view details

Michal Dziekonski

commit sha 984305d4a65955f92c2a382a75b7b243285df68d

GH-90 Fix expedition handler's ID in UserDevScanner

view details

Michal Dziekonski

commit sha 2c09271e1d73a3bd0dfc056ac237ca08bcbb7aaa

GH-90 Gather expeditions count statistics for users

view details

Michal Dziekonski

commit sha 8d9bf252c2933edee85307bfd6748eb773226063

GH-90 Remove the old code of expeditions completely

view details

Michal Dziekonski

commit sha 23d7d98709a937864562f7f8d7adff74a8af1989

GH-90 Include the correct, new code of expeditions

view details

Michal Dziekonski

commit sha e000ba963b3e0c427334898e0f7f8cd95160df1f

GH-90 Re-enable expeditions

view details

Michal Dziekonski

commit sha d7ffcbba47e0949cdcf54f4ea641574044a92470

GH-90 Add a shortcut in Galaxy view to send an expedition

view details

push time in 3 months

PR merged mdziekon/UniEngine

Re-enable expeditions (basic functionality) pr:bugfix pr:enhancement_request

Summary:

The old expeditions code needed a complete rewrite due to its incompatibility with "new" Flights handling systems. For now, it only implements two events: nothing happened and resources found. More events should be added in future Pull Requests.

Changelog:

  • [x] Complete rewrite of the expeditions code.
  • [x] Expeditions (as a mission) has been re-enabled by default.
  • [x] Added feature flags capability, allowing to disable expeditions by changing .FEATURES__EXPEDITIONS__ISENABLED constant's value from true to false.
  • [x] Fixed expedition shortcut in Galaxy view to always point to the currently selected galaxy & solar system's coords
    • Previously, it would stay at the "initial" coordinates
  • [x] Fleet destruction reason codes are easier to use in code now (unique Enum)

Is migration required?

YES

Related issues or PRs:

  • Closes #90
  • #82
+831 -509

0 comment

41 changed files

mdziekon

pr closed time in 3 months

issue closedmdziekon/UniEngine

Reinstate expedition fleet mission's code

Feature request summary

Bring back and reenable the ability to send player's fleet on an "expedition" mission.

Request background

In the current codebase, expeditions (sending fleet to the outskirt of any solar system in order to have a random chance of either getting some additional resources, ships, or with bad luck, getting your fleet damaged or destroyed) are completely disabled.

As stated in the old expeditions file (includes/functions/MissionCaseExpedition.php), the reasoning for this state of the game is as follows: https://github.com/mdziekon/UniEngine/blob/324b1042b4ee9a3f37faab538166d682b62a5074/includes/functions/MissionCaseExpedition.php#L3-L9

TL;DR: the mission's code was not rewritten to be compatible with the "new" Fleets handling system back in the days when the rewrite happened.

Related issues or PRs:

  • https://github.com/mdziekon/UniEngine/issues/82

closed time in 3 months

mdziekon

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha 3977d86f2b2dee9acded43ead8afb8d75453fccc

GH-91 Create an util allowing to roll moon creation

view details

Michal Dziekonski

commit sha a686bc541f092452f9ff0ebcff44ec6a57295d7a

GH-91 Use the newly created moon chance roll util in MissionCaseAttack

view details

Michal Dziekonski

commit sha e1ebcb8d7ef0791a952fcf630db6d72f4ee6481e

GH-91 Fix incorrectly passed moon creation chance to the moon creator

view details

Michal Dziekonski

commit sha 6b1f202a95c27ea582bd71f8b7b01e18c40d5d6b

GH-91 Fix incorrectly passed moon ID to devlog entry

view details

Michal Dziekonski

commit sha f2295f2a42e6b1a9f4370c1b41f09b9b84d9df4f

GH-91 Use the newly created moon chance roll util in MissionCaseDestruction

view details

Michal Dziekonski

commit sha 55c16828faae0e2dd51e3c3f9481ef1c0e4a145c

GH-91 Document the fact that moon creation in MissionCaseDestruction doesn't actually work...

view details

Michal Dziekonski

commit sha ee5f3dc280d50d2860b88810044bc0f98c8ef660

GH-91 Use the newly created moon chance roll util in MissionCaseGroupAttack

view details

Michal Dziekonski

commit sha 57fc1867886b8547c8e3002f17f743eb54c2907c

GH-91 Refactor CreateOneMoonRecord() to take singular $params object instead of multi args

view details

Michal Dziekonski

commit sha 4383b4240ac78389ab8ae18bfc1ca637c710752b

GH-91 Modify all usages of CreateOneMoonRecord to match new signature

view details

Michal Dziekonski

commit sha f4d2b3f01c092b4bd2476c78129807488227a9ec

GH-91 Simplify moon existence check and short circuit

view details

Michal Dziekonski

commit sha 8becb086978094a2b35d1ab5a95a4d6cdae70157

GH-91 Simplify new moon's planet existence check and short circuit

view details

Michal Dziekonski

commit sha be2e41c77228bc3b0610f0d25d5281d157f3a254

GH-91 Add an additional null check

view details

Michal Dziekonski

commit sha 7999a902801ee9bba5efbb29a772c71815bd0871

GH-91 Minor code cleanup

view details

Michal Dziekonski

commit sha 309808b05ebcec9280d74c3fbc56e0ba1b5fa6f0

GH-91 Create Collection\get() helper

view details

Michal Dziekonski

commit sha 35942ebe24acc4d4cb3a9de078dcb6685ba24252

GH-91 Create initial renderer of MoonCreationView with empty cmd handler

view details

Michal Dziekonski

commit sha 7f59c702e6c5700ef9cb0b614cac85a88c776496

GH-91 Implement the appropriate cmd handling for admin's moon creation view

view details

Michal Dziekonski

commit sha 0c15de2472e06d3f7b4f9db6a5d664605ce29754

GH-91 Properly use new MoonCreationView\render()

view details

Michal Dziekonski

commit sha bb2f4b87d7daf40317a42ef693f8dc6ae1c453a4

GH-91 Remove unused (moved) template file

view details

Michal Dziekonski

commit sha 9abb15a4632713775f1b34e40b0867a2044c8eec

GH-91 Minor code cleanups

view details

Michal Dziekonski

commit sha 51ac64a5115f13658eb79950b8e6ec92f3f1a013

Merge pull request #120 from mdziekon/mdziekon/91/fleet-mission-attack-refactor-part14

view details

push time in 3 months

PR opened mdziekon/UniEngine

Re-enable expeditions (basic functionality) pr:bugfix pr:enhancement_request

Summary:

The old expeditions code needed a complete rewrite due to its incompatibility with "new" Flights handling systems. For now, it only implements two events: nothing happened and resources found. More events should be added in future Pull Requests.

Changelog:

  • [x] Complete rewrite of the expeditions code.
  • [x] Expeditions (as a mission) has been re-enabled by default.
  • [x] Added feature flags capability, allowing to disable expeditions by changing .FEATURES__EXPEDITIONS__ISENABLED constant's value from true to false.
  • [x] Fixed expedition shortcut in Galaxy view to always point to the currently selected galaxy & solar system's coords
    • Previously, it would stay at the "initial" coordinates
  • [x] Fleet destruction reason codes are easier to use in code now (unique Enum)

Is migration required?

YES

Related issues or PRs:

  • #90
+831 -509

0 comment

41 changed files

pr created time in 3 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha dfa13e418772bd68e41974e9729bfd1228590264

GH-90 Replace all fleet destruction codes with enum values

view details

Michal Dziekonski

commit sha 159e63f9dd9e9060a545540e1dd57d0aeb7b27b7

GH-90 Remove comment from fleet_archive::Fleet_Destroyed_Reason and provide migration for that

view details

Michal Dziekonski

commit sha 6cbd6e554996a458adb7f4bd3623d9ccd5c89eb9

GH-90 Remove last hardcoded pieces of destruction reason codes

view details

Michal Dziekonski

commit sha 5c4afe52b52eb005e3332aca936cd303feb5f837

GH-90 Add basic expedition messages

view details

Michal Dziekonski

commit sha a970c0a46042559da3caa1003781ef571c42fefa

GH-90 Prepare expedition events message creators & their respective messages

view details

Michal Dziekonski

commit sha cf75533a5c009fe556cc3285e07dbd49a8efc623

GH-90 Send expedition result message to the user

view details

Michal Dziekonski

commit sha 22fb99765f5791e9a7edaee22dffcc95eb0aa5df

GH-90 Unify messages sending

view details

Michal Dziekonski

commit sha 984305d4a65955f92c2a382a75b7b243285df68d

GH-90 Fix expedition handler's ID in UserDevScanner

view details

Michal Dziekonski

commit sha 2c09271e1d73a3bd0dfc056ac237ca08bcbb7aaa

GH-90 Gather expeditions count statistics for users

view details

Michal Dziekonski

commit sha 8d9bf252c2933edee85307bfd6748eb773226063

GH-90 Remove the old code of expeditions completely

view details

Michal Dziekonski

commit sha 23d7d98709a937864562f7f8d7adff74a8af1989

GH-90 Include the correct, new code of expeditions

view details

Michal Dziekonski

commit sha e000ba963b3e0c427334898e0f7f8cd95160df1f

GH-90 Re-enable expeditions

view details

Michal Dziekonski

commit sha d7ffcbba47e0949cdcf54f4ea641574044a92470

GH-90 Add a shortcut in Galaxy view to send an expedition

view details

Michal Dziekonski

commit sha 4f09fdbc58d224378b241302d51f265d806fd5c8

GH-90 Properly handle expedition coords with auto-fill

view details

Michal Dziekonski

commit sha 6c5f614b1ebb22d30daac0e3591504ca885ddcff

GH-90 Add ability to check whether certain feature is enabled

view details

Michal Dziekonski

commit sha 40c21b7da23955090a6a960310bc783f227bc780

GH-90 Allow to disable expeditions using feature flags

view details

Michal Dziekonski

commit sha ee753252fd6e7689cc2ccf631af3d8b0b5c4641c

GH-90 Remove unused footer row & replace expedition label

view details

Michal Dziekonski

commit sha 93c11566898eafd1fa736eab91de5d21e1e1b1b1

GH-90 Add FEATURES__EXPEDITIONS__ISENABLED const to the installation script

view details

Michal Dziekonski

commit sha 5dce28361199016b4fb007a9829a975ee5f5b7fe

GH-90 Add migration which adds the FEATURES__EXPEDITIONS__ISENABLED const

view details

push time in 3 months

push eventmdziekon/UniEngine

Michal Dziekonski

commit sha d8d99257901c99b9782b02d170c31bf85cc57a61

GH-90 Fix dev dump creation when iterating over element categories & simplify it

view details

Michal Dziekonski

commit sha de44abacc8e7b121823f7bf7c883bda8513d40ac

GH-90 Create basic randomizers for expeditions

view details

Michal Dziekonski

commit sha 6b5c8ed0ffc303124e65bf0c97c605a33694329a

GH-90 Minor documentation spelling mistake spotted, might as well fix it

view details

Michal Dziekonski

commit sha 47129e33cb68ec3c44db953e33f3d837dc8afe31

GH-90 Add fleet update-related code to the new expedition system (fleet row updates, development log insertion & fleet archive insertion)

view details

Michal Dziekonski

commit sha d66acd9ab50527b63924be4a875c2c60f5cab575

GH-90 Create FleetDestructionReason enum

view details

push time in 3 months

create barnchmdziekon/UniEngine

branch : mdziekon/90/refactor-expeditions-part01

created branch time in 3 months

more