WorldSpawn official WIP thread

[MadGypsy]

I did a lot


I made another abstract for a boolean. It's job is to determine if the value falls within a range of possible enums. I made all the enums private and used a class interface to expose them.


This is an example of the results.



by "using" TypeCheck I am able to treat any value like it has the TypeCheck functions. I'm also able to have direct access to Supported_e values which comes in very handy when making switch statements for the returned values. If I didn't "using" TypeCheck, ex: IsObject would become TypeCheck.IsObject or maybe even TypeCheck.Supported_e.IsObject (one of those).

[MadGypsy]

I just found this awesome thing. Just like there is a JSFiddle there is a "HaxeFiddle"

Try Haxe

It's not as awesome as a full featured editor but, to just bang out some ideas on the fly it's pretty cool.

[Dutch]

I just found this awesome thing. Just like there is a JSFiddle there is a "HaxeFiddle"

Try Haxe

It's not as awesome as a full featured editor but, to just bang out some ideas on the fly it's pretty cool.

This is awesome! The examples really shed some light on what the code does...seeing the output let's you make connections in what the code is actually doing.

[MadGypsy]

I wish my phone had a real keyboard. The Try Haxe site would be handy when there is nothing to do at work and I wanted to flesh out some ideas. Whatever you put in that code box is autosaved to their servers when you click build and the URL changes to a unique one that you can go back to forever.

It's about new phone time. I'm going to look into one that supports a mini bluetooth keyboard. Wednesdays are super slow at work right now. I've considered bringing an entire laptop a few times (never did though). A phone that supports some kind of actual keyboard would be acceptable. EVen if the keyboard only let me thumb type due to it's mini size it would still be way better than trying to use the onscreen keyboard.

[MadGypsy]

I have done this to death. Damn near every single character has been considered. Everything reuses itself as much as possible. I'm chalking this up to absolute final. I did not add any new types (Vector, Dictionary, etc) because reversing any of those types from object back to whatever they are is impossible. There is no way to guess from one type to the next which one the object is meant to represent. For IntMap and String Map that's fine because they don't have anything special about them so I can get away with those. If you consider something like Vector3D though, the only way to represent it in JSON would be as an object and there would be no way to determine if it was truly meant to be an object. This matters because Vector3D has public methods like add, crossproduct, dotproduct, etc. The "work around" is to derive Vector3D manually, after the fact, from any supported type that would make sense to do so with.

[Baker]

I wish my phone had a real keyboard.

Walmart. Bluetooth keyboards, $17. They had 80 on the racks and 5 different brands to choose from 2 days ago at my Walmart. Brand I bought was "onn". Quite nice. Works with both iphones and android phones.

[MadGypsy]

That's good info. Thank you!

The only thing I need to consider is if I'm going to ignore my boycott of walmart to save a couple bucks on a keyboard. I probably wont BUT ONN brand name is a useful piece of info to use for an online search.

My boycott has nothing to do with morals or small-business. Everything I ever buy there breaks in 1 year. There's no savings in buying the same mid-quality stuff over and over. My coffee pot was 49$. It broke in a year to almost the day and for no apparent reason. I have more stories like that. I'm just fed up with walmart.

[enderandrew]

Walmart. Bluetooth keyboards, $17. They had 80 on the racks and 5 different brands to choose from 2 days ago at my Walmart. Brand I bought was "onn". Quite nice. Works with both iphones and android phones.

If you need to maintain portability, they also make projected laser bluetooth keyboards. I've never used one however, so I don't know how well they work.

https://www.amazon.com/Wireless-Proj.../dp/B00LFJBP0Y

[MadGypsy]

@projected kb

Just bought it. That's one of the coolest things I've seen in a while for the price. It also looks a little closer to actual keyboard size.

[MadGypsy]

Ya know, creating your own base type is straight up hard as fuck. I claimed yesterday that my Key abstract was absolute final and the bottom line is, it's not. It's not terribly broken or anything like that but, there are a couple-few oversights. I'm about to go address them. I'm still taking a minute to wind down from work.

One thing that is bugging me, which isn't really a problem but I'm making it one, is that I'm using Key<T>(Dynamic) when I really want to use Key<T>(Keyable<T>). I know you probably have no clue what the hell I'm talking about so I will explain it.

Dynamic is anything/everything/nothing...total wildcard. If I wrote a class (let's call it Keyable) and used T to represent an unknown type that gets solidified upon use I could maintain better dead code elimination.

Key<T>(Dynamic) basically says I want to make a Key of an unknown type and no matter what that type ends up being treat it like Dynamic (which is an every type - BAD). This means garbage collection just ignores the type because it has no way to determine if something is no longer necessary.

I need garbage collection to pay attention. The thing is, all json gets parsed to Dynamic so, all this time garbage collection has been ignoring external objects. That being said, for me to force type away from Dynamic and instigate the attention of garbage collection would essentially obsolete Dynamic altogether. I like the idea of making Haxe truly better and not just in a "try my thing" way but a "you are stupid if you don't use my thing" way.

I'm stuck in a new catch 22 though. I have numerous private static functions. If I move those to Keyable, Key can't mess with them. If I keep them in Key, Keyable can't use them. If I change the access to public static functions I lose all encap and expose the "engine" of the type to everything. That's not necessarily a big deal it's just not good OOP. This abstract is one of the hardest puzzles I have ever created for myself. At every major feature or desired design there is a catch 22. I have never met a problem in code that I could not overcome til this fucking abstract. I've also never had a real catch 22 til this abstract. I've encountered catch 22's before but they were always fake... a catch 22 by current perception. This time seems to really be a "no matter what you are screwed" situation.

Another reason I need Keyable<T> is for my BytesKey. I'm not going to extend an abstract. I need a class to extend. Keyable<T> should be a core class for all Keyable types and the classes that extend it should simply override functions in Keyable, where necessary. While I'm at it an IKeyable would probably be a good idea, too. I'll staple this shit down with railroad spikes to be so concrete that garbage collection will throw me a damn party.

----

I'm going to try something. I'm going to turn my entire abstract into a class and write a new abstract that does almost nothing but metadata stuff. In other words, only @:arrayAccess and @p functions will be abstracted. This should solve my private static function problem as technically the only thing the abstract will do is allow [keys] and mathematical operators for copy/delete... Yup, that's going to work.

[MadGypsy]

Shazaam, mother fuckers ... lol . I'm almost there. Now I am at Key<T>(Keyable<Dynamic>). Now if I can just change that dynamic to a T #problemSolved. My abstract went from almost 400 lines to about 40 but all those initial lines were just moved to a class that is sitting under the abstract.

[MadGypsy]

I seriously never give up and... I give up. I can't spend the rest of my life on this. I have a class to work with for BytesKey so, that's great and everything but, as for my other problems they are real catch22's that run in a vicious circle. It's like I'm fighting my way into a fight instead of out of one.

None of this is to imply that this was all some big waste of time, though. I created a pretty powerful type that does a lot of shit. It just doesn't do everything that I wish it did. The current way I am doing everything is the best this has ever been and I fixed all my oversights (really there was just one oversight). Also, I don't think it matters that Key uses Keyable<Dynamic> cause I instantiate Keyable with new Keyable<T>(). It's like I'm saying "Allow a Keyable that can be anything but MAKE a Keyable that is of type T" I need to make a little script that can check if garbage collection gives a fuck.

It also might be notable that I learned a whole friggin lot about what is and isn't acceptable regarding abstracts. I also learned a lot about the various nuances of an abstract. What also may be notable is there is still a whole friggin lot to learn about abstracts. I'm actually having some trouble wrapping my head around the difference between

to SomeType from SomeOtherType

and

@:to someFunc():SomeType
@:from someOtherFunc():SomeOtherType

You would think it is as simple as one is direct and the other is a method but, that is not the case. That to-from/@:[email protected]:from stuff is seriously confusing. I THINK @:to/@:from is regarding = assignments. Like a cast. Unfortunately I can't get the shit to even compile (cause I'm doing something wrong) so, I can't really test it.

[MadGypsy]

I finally got an @:from to work, and I was right it is an implicit cast. The hilighted code on the right is the from. The hilighted code on the left is the implementation and the console proves it works.

The reason why I could never get it to work before is because of all the V stuff. In this case V equals Entity_t. Before I was doing it more like

@:from static public function fromDynamic(cynamic)

The V way is better anyway because I can maintain the real type



All my confusion came from an error very similar to this

Entity_t expects Key<Entity_t>

Which is a dumb error. Of course the Key is looking for a "new Key<Entity_t>()". The error tells me nothing about how to allow it to accept a direct assignment, though. The V trick works perfect. By the way, I can use any damn letter I want for all of this T, V stuff. It just has to be a capital one and all that letter means is "I have no idea what type I might put in this" and after I put something in it that letter represents the actual type.

oddly...
@:from static public function fromDynamic(c:T)

does not work. It throws an error saying T is not defined even though T should be defined when I...
var receiverEnt:Key<Entity_t>

I think it's because the @:from is a static function. T must be scoped to non-static data.

[MadGypsy]

@enderandrew

I noticed you are in here a good bit tonight. Sorry I don't have things more interesting than a bunch of Haxe programming to talk about. I promise you this is all going somewhere more related to games... directly related to games.

I just want to have better stuff to use for building my engine and I want to bulk up my skills before I go programming a bunch of stuff that I will just end up reprogramming.

I become more informed and experienced by the hour. I'm not fucking around. I'm going to get so good at Haxe and programming in general that not even spike will know what the hell I'm talking about ( lol ).

There will come a point where all this stuff that is confusing me will cease to do so and the knowledge of them will relieve confusion elsewhere. It's exponential. I am going to master haxe...and I assume we all pray that I don't become suddenly bored with all the knowledge and find something harder to do. I also assume that the day will eventually come where I am programming in some language that is nothing but a series of dots and spaces simply because it is a huge pain in the ass. I love a challenge... addicted to them. Everything I have ever learned is because I wasn't sure if I could and everything I have ever quit is because there is no doubt that I could. My line of thinking is an entire video game engine and a super complicated language combined will keep me challenged long enough to finish.

[MadGypsy]

woo hoo! I'm off for the next 39 hours. It's time for like a 10+ hour session of BytesKey. This script is going to be a total mfer to write. There are sooo many possibilities to generalize. I'm thinking it might be smart to add byes to Key as a possible base type and build up from there.

My girl asked me what I care more about: writing code or her...I think I'm about to get dumped . Y'all know what my answer was. :shrugs: She can't perceive the truth. I care more about playing with my brain than playing with hers. My brain has more features.