WorldSpawn official WIP thread

[MadGypsy]

I took a hammer in the face today. It was awesome...ly painful. I think I broke my cheek or maybe a fracture... summin ain't right. I just shook it off and kept working but, now that I'm not preoccupied I can feel that this isn't just an oops. I can feel a line in my cheekbone under the skin right where I got myself but, it seems awfully pronounced for a quick hammer in the face. I mean, if my cheek is THAT broken, I would think it would be a lot more obvious. Meh, I'll do nothing about it for a day or 2 and see what happens. It doesn't really hurt. It just feels "not right".

advice:

don't slip and smack yourself in the face with a hammer when you are using a whole lot of force...it don't feel good. It hurts even more when it's the claw end.

other advice

don't stick your face anywhere near my hammer. Especially if you like your face and don't intend to ever need a new one.

[MadGypsy]

creating a language from scratch is hard, confusing and requires a lot of consideration. I'm completely unsure of how to handle functions. Functions are actually my kryptonite. I could spin variables upside-down inside-out all day but performing a function on them has me a bit baffled. I'll figure it out...always do.

I carefully crafted my types to where the type can be derived from the name or the value. Technically there are possible values that arent listed here but I intend to suppress them. Like UnsignedBool - that's not a thing in any language that I'm aware of. Untyped Arrays and Vectors are also possible but, I don't want them to be. I'm thinking this way is pretty good so far (I hope). When I go to convert a script written in my language to bytes I will be able to store any type as an UnsignedShort (2 bytes) and I wont have to store the names at all.

[MadGypsy]

Let's pretend you were making some mod in Qc. Let's also pretend that you had to write a long list of flags. Isn't the below much simpler than manually writing every power of 2?



all you have to do, this way, is follow this pattern [01,02,04,08,10,20,40,80] and every time you loop back to the beginning of that pattern, left shift (<<) by 8 more than the last time you left shifted.

If you can't use hex, use this pattern
[1,2,4,8,16,32,64,128]

if you cant left shift substitute 8 with 128 and multiply.

note: all those vars are old and not how I'm doing my thing. The image is solely a focus on an alternate way to concoct flags.

edit: I just realized that substituting 8 with 128 is wrong in every way. I meant substitute the incremented 8s with the result of its powering of 2.

[Spike]

enumflags float
{
a,
b,
c,
d,
e,
f,
g
};
much easier, at least with fteqcc.

that said, floats are limited to about 24 bits, if you want to avoid precision loss.
change the 'float' in there to an 'int' and you get more, but also become dependant on fteqw.

without fteqcc's enumflags feature, I personally prefer:
int foo=1<<X; where X starts at 0 and just increases by 1 for each flag.

your specific array types make me paranoid about how you plan to handle structs/objects/tables/whatever else you might call them.

[Mugwump]

So now you're not only creating a game engine but a new language? How's your face?

[MadGypsy]

@my face - It was a nothing. I guess it was just "sore" or something when I was worried that I broke it. I have a dot on my cheek. I have a pretty hard head (in every way). If it would have been anywhere other than my cheek (ie regular big bones) I wouldn't have paid this a second glance of attention. Well, now we know I can take a hammer in the face and walk away from it. I mean obviously if someone else was swinging a hammer into my face it would have been far more terrible but, I got myself pretty damn good.

@So now you're not only creating a game engine but a new language?

Well, it was going to happen eventually. This is my starter-kit attempt.

@Spike ~ make me paranoid about how you plan to handle structs/objects/tables/whatever else you might call them. ~

I can't even explain how I intend to do this. All I can say is, I have this big blob in my head that makes some kind of sense to me and I'm handling this on a per-function level til I get enough functions to start putting it all together. The vars I intend to use are in the image in post #317. I'm going so hardcore with types because the more specific I am the more efficiently I can store the variables in bytes BUT I am considering putting that on the other end, where you can use Int/UInt/Float and my compiler will determine how many bytes are necessary to most efficiently store the data. It's all dynamic, brother. I'm sure lots of things will change before this is all done. I just follow the concrescence of thoughts and ideas wherever they lead and then determine the next step based on the results.

On a side note:

I'm loving this switch over to Haxe. After all the different things that I rewrote I am super comfortable in Haxe and it's business as usual. Yesterday was an example of my comfortability in Haxe. I kept writing code that gave me strange errors on one or more platforms and every single time I fixed those errors in a matter of 10's of seconds. I've got a pretty good dictionary in my head of problem/solution regarding platform specific errors in the Haxe paradigm. Actually all of it can be based on one rule. If flash is the only language on earth that doesn't do X you will have to do X for every platform but flash. Here is an example.

flash

Bytes.readString(16) = "Michael"

not flash

Bytes.readString(16) ="Michael\0\0\0\0\0\0\0\0\0"

Flash is the only platform that auto-removes null. So, to make it easy, use this rule "If not flash and dealing with bytes consider everything"

or how about

"If not flash and using RegEx there is no forgiveness and standard RegEx rules apply"

so flash (?<=[a-z]+) - look behind without a fixed length

everything else (?<=[a-z]{fixedLengthNum})

There is tons of this stuff and I'm almost to the point where I'm programming it in properly in the first place instead of waiting for an error to remind me.

[Mugwump]

Good to know you're OK.

[MadGypsy]

For anyone that cares, here is an early and incomplete mock-up of where my language is going (right side)



# = include
-> = extends
get_, set_, local_ = accessors
local_ = private
local_get_, local_set_ = protected
no local_ = public except within a function body.
<SomeType> = type syntax for creating types
:SomeType = type syntax for using an existing type
T<> = indicates a typedef
A<> = will indicate an abstract
C<> = will indicate a concrete - ie a "filled out" abstract - or an implementation of A

other ideas

consider
offsets = [//array of offsets]
positions = [//array of positions]

//n does not need to be declared, its existence is an implied declaration
for (n...offsets, positions)
{ somethingToDo(offsets[n], positions[n]);
}

Right now my language is a combination of a number of languages. Some things have invented themself by design. For instance, I completely strip whitespace from the initial class so something like for(n in thing) will not work cause that will become for(ninthing) and there is no way to parse that. So, "in" gets replaced with "..." syntactically. There are other things. Like: Main extends Secondary...can't do that so, Main->Secondary. I could simply not strip whitespace first but then creating regexs would be a nightmare because it would constantly be doing look ahead and look behinds to determine the context of the space. Really, my substitutions result in you typing less most of the time. That's one of the reasons why everything that is not local_ or local_get/set is public. By determining what is not public...everything else is public. Also, equal signs are allowed but not necessary for block variables.

ie

var dat{some block}

This is because Objects/Structs/Dynamics/Whatever are the only block elements where programming languages use equals. No equals for functions/classes/arrays/more. All of this stuff is just blocks with a potential interface for modifiers/arguments. That being said interface or not, block elements don't need equals. My system works by virtually collapsing and uncollapsing blocks as they are processed so, an equals sign would never be read for a block in the first place. What I'm saying is, my system does not work on an "equals" system. It works on an address system and the names you give vars are completely arbitrary. The only reason non-block variables need an equals is so I have something to split them on. Technically, beyond actual math, equals is completely irrelevant.

[MadGypsy]

I'm about to get popping on some more code but I am fairly lost-in-space. I realized long ago that when I am lost the best thing I can do is explain it. Here is as good a spot as any.

Let's review some facts

1) I need to convert a text script to bytes
2) I need an engine that can read those bytes and produce the results the script described

Let's tackle the first thing.

A class is the most "parent" object of a script but it isn't the only parent object on it's layer. Typedefs are also a parent. Kick it off by collapsing top layer parents. This will leave me with something like

#com.gypsy.Secondary;
T<SomeType>{PARENT0}
Main->Secondary{PARENT1}

split on semicolon and handle all resulting array indexes as imports except the last one. This is because the only semicolons will be after imports so the last index of the split is going to be the entire rest of the script.

Uncollapse all typedef instances and process them. This is pretty simple cause typedefs only hold name:Type csv's

OK so at this point everything has been imported and custom types are available.

Uncollapse class. Apparently this will be what we just did all over again but, in this case semicolon split will be for variables and the "parents" that get collapsed will mostly be functions....

Hmmm I see a problem with this though. Doing this for imports is fine because imports always come first but variables can be written anywhere. So...

var;
func(){}
var;

becomes

[var, func(){}var]

OK...no semicolon split on class members I will ... hmm IDK. I'll be back when I get this far.

EDIT: I am going to try something. I am going to completely back up for a minute and create typedefs in Haxe that describe a class, function, loop, etc etc. This will give me a structure to work towards and from. I will probably end up reusing a bunch of the script I already wrote...especially collapse cause it is totally bad-ass for text parsing. I can pinpoint any parent type [](){}<> and say "go away". It's a lot easier to parse stuff when you don't have a bunch of crap you don't want to parse sitting around. I can then pinpoint an exact parent to come back. It's one of the nicest parse features I have ever written and also a testament to how really-fucking-good I am at reg ex. I don't toot my own horn often (enough) but when I do I'm doing it right now...(silly) Anyway, yeah - Time to start this off by typing out my language first.

[MadGypsy]

Well, it doesn't look like much but, a whole shit load of possibilities reside in these few lines. I'm sure this is jacked up in some way. I need to start parsing things based on these structures so I can start finding my design flaws. Really Type_t is the only one I feel is probably correct.



ASIDE - some of you may want to know this stuff or find it interesting

First off, I'm calling this language TypeCast. I was gonna cal it Gyp C (lmao) but, that's as douchey as it comes. Also there is a legit reason for calling it TypeCast. Let me back up a hair.

I made a math expression parser...we all know this. I wanted one more feature - the ability to drop external vars into the expression... Don't ask me how or why but, that gave me the idea that I could create a language that is one big typedef (maybe leaning a little towards an abstract) and the sole purpose would be to write a "typedef" that completely describes any given file type. So, for instance, I could write a typedef for BSP, load it in tandem with the bsp and instead of getting bytes to parse back I would get completely parsed lumps. I mean structurally. In other words it wouldn't give me back fully constructed faces and all that, just a struct full of parsed lumps. I want to be able to do this for any imaginable file type. If I was just sticking to that this would not be a big deal. To create some system of instructions for properly parsing bytes would be almost a nothing BUT some kind of way this turned into me going full blast and doing an entire language. I'm actually very tempted to do the parsing idea and then build the rest of the language on top of it. I'm worried if I do that I'll end up realizing that whatever I started with was not a good foundation for an entire language....and I go on vacation to re(write/consider) city. If I go the other way, build the language as a language from jump, I believe adding on my filetype casting idea will go pretty smooth.

All of this would go smooth if I had any fuckin clue on earth what I am even doing. I'm basically taking years and years of parsing and programming and attempting to pretend that means I qualify to invent my own full-featured language. That does not mean that. Just cause you watch Bob Vila every Sunday for your whole life it doesn't mean you can build a house. However, if this stuff wasn't an extremely complicated puzzle I would lose interest really fast. It's the whole experience of racking my brain that keeps me driven. Some of you may not realize that a number of my projects died the second I said "Oh, I get it". That's why this mega project has endured...I don't get it. I basically took everything I don't have a clue about and decided those were the only things I'm gonna do. When I was parsing wads it started as Ho-Hum-Tippity-Tap-Knock-This-Bullshit-Out - that was until I realized that the wad2 specs are almost completely garbage and virtually useless. Then I went from Ho-Hum-Snooooooore to "Ohhhh all you little bytes are hiding and I have no way, beyond guessing, to find you." COFFEE - METAL "Run little bytsies! I'm comin for ya!" I found shit that wasn't in the specs at all.

[MadGypsy]

Over the last 2 days I have been trying to wrap my mind around Abstracts in Haxe. Abstracts in Haxe are complicated. I don't think I've ever had to try so hard to understand a language feature. However, today I finally wrote a useful abstract that doesn't have a million problems. I worked so hard on nailing this feature because I believe it is key to making various things possible in the language I am attempting to invent. For clarity, any time you have caught me speaking about abstracts (before this post), I was not at all referring to what Haxe calls an abstract.

The abstracts I was referring to could be understood like this. It may not be actually true but it COULD be true that all math operations are described in a Number abstract... and Float, Int, UInt, Double, etc are concrete representations of that abstract. That is a decent example of the Abstracts that I am used to. Haxe abstracts can totally do that but they can also do a hell of a lot more. If you are really clever you can get an Haxe Abstract to do some serious shit.... like help you completely invent a language from scratch.

I'm gonna wait til I have a working Function abstract before I post any examples. I can tell you right now, if you are used to reading the scripts I post and you understand them. You can give up that confidence right now (regarding my Func abstract). They break so many "rules" - in is not always in and out is not always out...it's so contextual it's ridiculous. That's why it took me 2 days to figure it out and honestly I still have mild confusion about a thing or two. The confusion will be short lived.

[MadGypsy]

Woops, I missed an entire paragraph.

Beyond the syntax flip-flops for abstracts making things complicated, the rules never fucking end. If you're doing X it has to be inline, if you use Y metaTag it has to be static. If you are overriding an underlying type (like Int) and rewire comparison operators, the new type has to always be to the left of the comparison, unless you use a specific metaTag then it always has to be on the right. If you want it to work on both sides you have to make it static....unless you can't due to some other rule. rules, rules, rules....abstracts are a mother fucker.

It's really a big pain in the ass but, it's a super powerful and useful pain in the ass, so...

for funsies here is an abstract header. Note a couple of things
1) K and V do not actually exist
2) The argument interface has no vars
3) since when does a *class have an argument interface to begin with
4) since when does a *class need <type, constraints> - a class is a Type
5) why are the type constraints values that do not even exist

*abstracts are classes - and these questions are rhetorical. I already know the answers and they aren't very obvious.

abstract Map<K,V>( IMap<K,V> ) {

[MadGypsy]

I decided to explore the Haxe documentation (not to be confused with the language reference). I honestly have never bothered to look at either with the one exception of reading about abstracts for the last 2 days. I learned Haxe by looking at code snippets. I mostly found those snippets in the source. I may have read a tutorial or 2 but mostly I just read the source. That's how I learn every language, mostly. I digress, I decided to read the docs. I'm about 2/3 the way through them. Haxe does a bunch of stuff that isn't really a feature in any other languages I know. Looks like I'm gonna need to bring my skills to the shop for a bit. I mean, I could probably do nothing and it wouldn't matter. I just ported 10's of thousands of lines to Haxe and I haven't used or needed any of these extra features but, need or not, I want to be amazing at Haxe programming. The only way I can be positive that I am a beast is if there isn't anything that I don't know. I'm maybe 50 pages or so from finishing the docs and then I'm gonna read them 2 more times. It's a lot to process. Luckily, the grand majority of the language is no different than any other OOP language with Class based inheritance. A func is a func, an array is an array...blah blah blah, etc, etc. with very little deviation. It's like everything I already know plus.

I want to write a program that has an example of every single Haxe language feature and construct in one class. And ya know, making that wont be that hard. What will be hard is trying to figure out something for the class to do which would make all that necessary. It would be nice for it all to tie together into a cohesive result. As it stands right now, I have no clue where to even begin with this. Mostly because I don't currently have any ideas that would require every feature of the language.

By "every feature" I mean the below. I'm not referring to every imaginable Type and/or how to utilize it

///copy/paste from docs
Class instance: an object of a given class or interface
Enum instance: a value of a Haxe enumeration
Structure: an anonymous structure, i.e. a collection of named fields
Function: a compound type of several arguments and one return
Dynamic: a wildcard type which is compatible with any type
Abstract: a compile-time type which is represented by a different type at runtime
Monomorph: an unknown type which may later become a different type

There are (let's call them) sub features to all of these types and that's what I would really like to express all in one script. Do any of you know of something similar that was done for some other language? If so, could you point me to it? I just want to see what the result of that script is because, maybe it would be a good result for me to aim for. In other words I can take the "what should my script even do" out of the equation and focus on how I could use everything to do it.

[MadGypsy]

This is pretty cool...up til now my ContentManager was entirely focused on local files. By copy/pasting my load function, renaming it loadRss and changing 1 line of code in it I was able to load the quakeone rssfeed with zero issue. It puts it in the libaray and everything just like any other file. With some tricky syntax I could probably even delete the copy/paste function and make it a part of regular load. The part that needed to be changed was the filename/extension parsing part. Obviously the rss url does not have a filename or extension. I could probably write an exception that can figure that out based on URLVariables or something. The problem is, one part of me would like all loading to go through one function but, another part of me doesn't want to junk up my load function with a bunch of string check garbage for just one possible filetype.

Oh wait, I have an idea. I don't have to make string check garbage in my main load function. I can simply add loadRss to the default case in my load function switch block and then add the string check garbage in loadRss. That's what I'm gonna do. This way regular load can stay basically cherry and super clean...and I don't give a crap how ugly loadRss is. The only thing I don't like about that is then my code essentially becomes

load()
switch(ext)
//cases for recognized file types
default:
loadRss(path)

then

loadRss()
//check if an rss
else "Error(Unrecognized File Type")

It's kind of weird to start a file check in one function, have insatisfaction try a different function and ultimately fail in the second function if nothing worked out. Sigh, I'm so picky about every damn dot of my code - especially since I just rewrote all of it into possibly the best code I have ever written.

[MadGypsy]

This is completely off-topic but I'm not creating a thread just to share this

Look at my answers for the linkedIn profile I'm creating . I know the point of LinkedIn but I'm just signing up cause some friends have sent me requests.



I'm not hella serious about my LinkedIn profile BUT it would be cool if I had some endorsements. A bunch of you know that I really do know the stuff I listed as my skills (and then some). If any of you have a LinkedIn it would be awesome if you threw me an endorsement. I'll return the endorsement, as well. You can also feel free to add me as a contact if you wish.

https://www.linkedin.com/in/michael-guidry-108271134