waitwhatwolf / warwolfworks-x-unity Goto Github PK

In the update 6.1 all supported INyuComponent update methods were reworked to be stored in a separate list then retrieved from it instead of casting it every time those methods were called.
For reference, it went from something this:

for(int i = 0; i < nyuComponents.Count; i++)
{
    if(nyuComponents[i] is INyuUpdate nyuUpdate)
        nyuUpdate.NyuUpdate();
}

To something like this:

for(int i = 0; i < nyuComponentUpdates.Count; i++)
{
    nyuComponentUpdates[i].NyuUpdate();
}

The plan is to implement this into pre-made components as well; Currently, the systems that will see an implementation of this are:

• YharonSystem Added in 6.1.1 update.
• AttackSystem
• AttackSystemV2 Added in 6.1.1 update.
• ProjectileSystem
• SerializedProjectiles Added in 6.1.1 update.

Self explanatory, this will be fixed next release.

The CTS system works differently from Streaming.Catalog:
Where changes made to the saving class would immediately be written to the file in the current saving system, CTS need it's Apply() method to be called for changes to be applied to the file.

A new an reusable pooling system; Previous pooling system was deprecated in 2.3.1.0, so it will need a better replacement.

Will fix in upcoming update. (5.0?)

The goal here is to make a console which has a core class (currently implemented but not finished, resides in WarWolfWorks.Debugging.Console) which handles all logic, and a separate class which handles the visual aspect of the console; That way, you can use the Console class but can still make your own Console UI if you do not like the pre-made one.

Planned to ship in Madeina 3, using the SlickMenu system.

Currently, there will only be a message telling you what to do to display variables using a custom editor; With this, all visible serialized values will be displayed by default instead of that message.

https://github.com/WhiteWarriorWolf/WarWolfWorks-x-Unity/blob/f8773e223c2a51088dc21c8de29996c1b7e049d2/NyuEntities/SerializedProjectiles/SProjectileManager.cs#L194

Already implemented in NyuManager, but not in Nyu sub-components like SProjectileManager.

Currently, the Entity system is based off of Unity's current gameobject/component system, which is fine, however, Unity's upcoming DOTS system will be much more optimal and will have better support compared to the current component system; The goal here is to make an Entity system similar to the current entity system, with full dependency on the DOTS system, not the components system. (Both will be separate, and Dotters will be developed as Unity's DOTS system develops.)

UnityEngine.Application.productName is as broken as unity, so instead of relying on this inconsistency-fest, I'll just create one where you can set it in the WarWolfWorks>Settings menu.

'Nuff-said.

...Yes, another one; However, this time it will be much more code-oriented instead of awkwardly integrated into unity's whacky scriptable object system.

Codenamed: Marshmallow

The current attack system is basically the old EntityAttack scripts which was adapted to the current system; As of now this doesn't pose major issues, but it does start showing it's age.

Current idea is to name all attack-related scripts and components after Greek/Norse Mythology, similarly to the Yharon system which has multiple references.

Ah, good'ol Unity, back at it again with the stupid consumer-unfriendly features that no one asked for, this time they decided it would be a bad idea to request the project's name outside runtime...

Man, I love this engine.

No fix is planned for this yet, as the WarWolfWorks library uses the project's name to save user preferences of the library on the disk, on a per project-basis. (in {current user documents}/{projectname}/Preferences.cts)

So for now the best thing would be to wrap any instances of the project name use in try-catch blocks and ignore the catch; I know, I know, this is terrible and not pretty, but it's not my fault Unity is pulling shit like this.

(Continuation to this issue)
#14

This would include saving variables like PreviousInputs, DeveloperMode, ConsoleColor or even the console's size.

Will make them saveable through CTS system.

Basically, a Scene system, but good, not like mr.Unity I like f-ing up everything in the game scene system.

The reason this is labeled with the 'potentially' tag is because it will require a custom inspector, a very broad spectrum of utilities as well as god-like levels of memory management, so for now I'd rather lazy it out.

Currently the LanguageString is attached to the same value the library uses (see), the plan is to separate them.

As the title suggests, the WarWolfWorks library uses the current Streaming.Catalog system which will be obsolete after the release of 5.0; WarWolfWorks should fully use the CTS system before that.

This is a QoL addition which essentially allows you to put anything in without casting it as int; This essentially removes a lot of boiler plate

Example:
Assuming you have an enum for affections (we will call it Affections for simplicity)

public enum Affections
{
    ...
}

You would go from this:

Stat bonusSpeed = new Stat(1f, 1, (int)Affections.MovementSpeed, (int)Affections.Running, (int)Affections.TipToeing);

To this:

Stat bonusSpeed = new Stat(1f, 1, Affections.MovementSpeed, Affections.Running, Affections.TipToeing);