Comments (15)
I'll give it a shot separately, if it doesn't work out as you imagined you could always let me know and take over
from artemis.
Sounds nice and really complicated.
from artemis.
Do the features that expose variables need to be enabled in config just like any other feature, or is it possible to have the info boxes work out which features are required and have them automatically enable/disable? I believe this would save a lot of headache with users wondering why we "removed" certain info variables.
It would also be good to see something like math(%dry_boxes%/%dry_streak%)
where it would return the math result. This was requested a few times in legacy.
from artemis.
We could perhaps add automatic management of feature state, yes.
As for math, format could be more limiting (add,div,etc).
from artemis.
@DonkeyBlaster do you plan on working this yourself (in the info overlay PR or separately) or should I work on this after vacation?
from artemis.
I would wait for the manager PR to be merged though.
from artemis.
You would want something like that but dependant=variable and dependency=feature.
from artemis.
I have quite a lot of opinions on this. I get the feeling I approach this from a somewhat different angle, so I'll just give my little speech listing what I think is important characteristics, and leave it to you how to turn that into useful code. ;-)
First of all, I think we should talk about "functions" instead. Let's have a low-level interface like this:
public interface Function {
String get(String argument);
}
This will allow us to have info "variables" with arguments. I think this can come in handy. For instance, a speed function could take in the unit type (block/second, etc) as argument. Most "variables" will be just functions without argument, but that's fine. We should support such as we do "normal" variables in legacy.
Secondly, and this is implied by the interface above, the functions should operate at a very basic level. They have a name, and return a string. They should be usable in other contexts than the "info overlays". As a concrete example, I do think that the very first implementation of these functions should be as a command, just like how configs work right now.
Examples: '/wynntils function mana should print your current mana level, or '/wynntils function speed m/s
would print your speed in meters per second.
We need to have a registry of some kind, where we list all instaces of Function
. (If that name is too general, we can name it WynntilsFunction, WFunction, or maybe even InfoFunction, in keeping with the old name). The implementations need to extract the data necessary to provide their result. Typically I assume that means dependency on Managers; hopefully not on Features. (I'd really like to avoid that.) Functions that need to have callbacks to stay updated will only have to be registered as listener if someone is observing them. That means, if they are added to an info overlay, they should be activated as listener. But that means a "one shot" read-out using /wynntils function
is allowed to return "N/A". (We might need a command to start listening, if it turns out that we need that kind of functions, if not for anything else, so for testing them.)
(Cont'd...)
from artemis.
The info overlay needs to have a better syntax for handling functions. I suggest we can have two forms of info overlays:
-
simple
-
template
-
means that we just give the name of a single function (possibly with a constant argument), which is then watched. As a bonus, we should also be able to set the color of this value. As a bonus bonus, the
Function
interface can be extended with apublic String name()
, which we can choose to display in front, so you can get like:Emeralds: 122
or just122
, or so. -
Means the user get full control. A string with template patterns, where we keep the & as synonom for ยง. And we make sure we have a parsable and unambigous syntax for functions, meaning we need paired delimiters for metadata.
Examples:
&1{name:speed}: &3{speed:m/s}&1 m/s
would call the special function name
which gets the name of the function given as argument, then the speed function with m/s
as argument, and then print the literal m/s
, all color coded.
&q{emeralds}
will just print emeralds with "q" formatting. (Probably easier expressed as a simple info box)
(Cont'd...)
from artemis.
I'd also like to see the possibility to display functions with numerical return values differently, perhaps as bars or meters or something. Maybe we should even make a basic distinction between functions returning strings and functions returning a number. (Don't need the entire int/float division, just have strings or double). Such values could e.g. have formatting built in: {[email protected]:m/s}
would print speed using any needed number of integer digits, and always print two decimals. Or suchlike.
Or we can in the future have not only textual representations, but perhaps different kinds of graphical measures.
(Cont'd...)
from artemis.
Finally, I think that these functions is such an important part in itself (if done right, these can possibly replace some specialized overlays from legacy, and may open up for all kinds of cool things in the future, like scripting!), that they need to have their own top level package, com.wynntils.functions
, with the framework for handling them in com.wynntils.core.functions
, in analogy with to features.
from artemis.
(And perhaps needless to say, having a function concept makes it easy to add non-Wynncrafty functions, like averages, evaluation of mathematical expressions, etc.)
from artemis.
I don't think it need to be that complicated. As long as we kind of agree on the direction, we can start very simple, and then expand. For instance, let's start without arguments, then we can add that going forward. I'll setup a simple example in a PR with just a few basic variables, to show what it could look like.
from artemis.
I've implemented my ideas in #291. This will set the foundation for functions, but not fully resolve all @DonkeyBlaster's needs. For instance, the info boxes still need to keep track of which functions are EnableableFunctions, and make sure these are enabled and disabled as appropriate. (This is trivial for the "simple" style, but will need a bit of thought for the "template" strings.)
from artemis.
Can we close this now?
from artemis.
Related Issues (20)
- [Question] About the resource download issue of Chinese Players HOT 1
- [Proposal] - Allow overriding urls.json source link with a java properties
- Make translation feature work with NPC dialogues HOT 13
- Disabling Game Notifications overlay hides all notifications (unless it's parent feature is also disabled) HOT 2
- WorldStateModel needs to correctly handle Housing Islands
- The one-click join wynncraft button on the title screen crashes when using Blur Mod HOT 2
- Text renders black on the left side of the screen
- Crashes on launch when using v1.1.11+ HOT 2
- Unidentified Shiny Items are not annotated correctly HOT 1
- "donator" should be "donor"
- [Function request] Some features that may provide a better experience HOT 2
- "Press SNEAK to continue" has "<protected>" behind it HOT 6
- WorldStateModel breaks after /class in streamer mode HOT 2
- Game frequently crashes in trade market HOT 4
- Quest, cave, discoveries, and other things in content book take way too long to load HOT 10
- WAR_MESSAGE_PATTERN does not handle x minute and y second case
- [MapData] - Icon Fade is applied on the minimap HOT 4
- [MapData] - Minimum visibility to render is slightly off, allowing hovering unrendered features HOT 3
- [MapData] - Hovering does not work if multiple waypoints are stacked, and the one with the highest priority does not render HOT 1
- MalformedJsonException + error 'Signature is missing from Property textures' spamming in the console HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from artemis.