Client progress

#181

Let’s get this ridiculous thread back on the first page. As before, I’ll keep the first post updated.

#182

How many engines have there been, and how many more need to die on these forums before we get to use one? Lol good luck codr. Progress looks good.

#183

I agree, it’s ridiculous. What do you expect, though? They take a great deal of time to complete.

#184

This weekend has been really productive. I know, there’s nothing to actually show for it, which sucks. Just keep an eye on the first post if you’re interested in the progress. Note the edited date/time and you’ll see that I’m still working on things.

The script engine as a whole is feeling more and more like an actual language at this point. (One that actually functions, and does everything it’s documented to do.) I’ve mentioned it before, but once the script engine is done, that’s when there’ll actually be screenshots to show. Everything from then on is graphical, or more directly graphical, at least.

Edit: I’ve decided to remove classes from the script language for now. Their benefit wasn’t really that significant compared to alternatives, whereas the amount of work required to code them into the language was rather extensive. With this change, the script engine is almost done.

#185

jeez nearly two years in the making. Go go go!

#186

While traditional classes aren’t too important for graal scripting, I still feel there needs to be a mechanism in place to prevent the need for code duplication, I for one would accept the cheap hack that’s already in place with the ‘join’ function where the code in the given text file is appended to the end of the current script.

#187

:rolleyes: It’s not as if it’s been consistent work the entire time. There are large gaps of no activity at all.

There’s the ability to make variables and functions accessible outside of each individual script, so that’s one way to share code. But yeah, things can be added as the need presents itself. I had actually forgotten about anything like “join”.

#188

It’s easy given it’s not actually implemented in the client, but rather the gserver itself leading to a rather dodgy implementation where regular expressions should’ve been used but instead it’s some dodgy scan method resulting in not being allowed to use the word join in any say2 dialogue because it’ll be interpreted as the actual join function… Regardless there needs to be an inheritance mechanism of sorts alongside whatever global functions/variables may be present, even if it’s via weak code insertion.

There should be no immediate urgency for this feature request of course, but somewhere down the line, it’d be convenient addition at least for the sake of maintaining scripts.

#189

Are you looking for something that would “paste” two scripts together? Or more specific than that? Also… rofl… just having the text “join” in a sign would attempt to call the function? I guess that’s what happens when you don’t have real strings. (Or maybe it was somehow intentional?)

#190

Yes the gserver’s implementation was unintentional and is the result of not having ‘real’ strings(I guess)although a few regular expressions such as [^;]join \\w+;$ could easily enforce it.
That’s irrelevant however, and yes, all I’m looking for is a function would “paste” two scripts together. Of course, if it could be more powerful than that and support proper inheritance that’d be even better but if not I don’t consider this a tall ask and I’m sure many would settle for it, after all, despite its simplicity it helps maintain code a whole lot better than if it weren’t there at all.

#191

What do you mean by inheritance? I’m not seeing how that applies when referring to combining scripts.

#192

I’ll use an example, in phoenix all shop merchants use a base shop ‘class’ supplied using the join function. From there, functions are overridden specific to the merchant.

Using inheritance(Script: oh! I know who you are, your father was a shop so… you’re a shop too, ok! let’s do this!)
Using join(Script:I see you have this variable, I guess I can assume you’re a shop I suppose…, ok, let’s just go for it anyway!)

In this instance, inheritance or joining of two scripts is about supplying consistent base functionality to avoid code duplication while allowing for customisation of higher up scripts(sub classes).

While both ultimately end up achieving the same thing at the end of the day, if we have the ability to avoid tacky tricks, we should do so leading to more robust designs and less problems for developers trying to work out what the heck’s going on.

#193

This is something you could do with my language:

Script 1 (“base”):

function display() {} function global.Base(var) { var.DisplayShop = display; }

Script 2 (“derived”):

function newDisplay() {} function onLoad() { global.Base(&shop); //Referencing "shop" so that Base() can modify it. shop.DisplayShop = newDisplay; }

Yeah, it’s not quite as convenient as classes, but it’s only a minor difference, really. More importantly for now, it prevents further delays on progress.

That little example did, however, bring to light two problems:

  • Typing “global.” before every variable to keep accessing the global one? That is not what I’m looking for at all. I’ll have to think of something more elegant.
  • A global function pointer to a local function… I don’t see a problem with the actual functionality of that, but what if the script the local function resides in is unloaded?
#194

This is quite neat and could work well for quite a few instances. However a few things,

Is the scope in which these global functions defined instanced? so let’s say I define a global set of functions for monsters and have a variable ‘health’, if I were to use such functions for each monster, would they then all share the same health(hit one, hit them all)? If not, could we then reference the instance itself and pass it to a local variable to which from there, overload any methods. Of course… this is practically a class and as you said, you wouldn’t be implementing this, therefore the scheme you’ve put forward is then rather flawed outside the example given.

This’d be fine I suppose, unfortunately I’m unable to answer that question as I’m not sure of the best scheme myself.

#195

I’m having trouble understanding the scenario you’re referring to. Could you maybe make some pseudocode to represent it? There’s no difference between the functionality of classes that I was going to implement and the script I gave. So maybe the original class concept wasn’t even going to fulfill what you were looking for. Then again, maybe there’s some miscommunication going on here.

#196

Monster Base:

var health;
function global.onHurt(amt)
{
  health -= amt;
}

Crab:

function onHit()
{
  this.chat = "*ting* it didn't hurt that much..";
  global.onHurt(0.1);
}

Cow:

function onHit()
{
  this.chat = "!!!";
  global.onHurt(1);
}

What will happen in this situation is what I’m trying to determine.

#197

You’re thinking about this way differently than I have been. You’re looking at the NPCs themselves as objects. (Which, they are, but I’ve been referencing everything as stand-alone scripts, as classes and that type of functionality isn’t specific to NPCs in particular.)

So, to fit what you were describing, I would be thinking more along the lines of:

Base

function global.Hurt(value) {
    npc.health -= value;
}

NPC 1

npc.health = 10;
function Hit() {
    global.Hurt(0.1);
}

NPC 2

npc.health = 20;
function Hit() {
    global.Hurt(1);
}

Keep in mind that there’s no predefined anything. There won’t be automatic detection of “hits” or even the notion of “hits” to begin with. All systems will need to be scripted for each server. I’ll probably make something Graal-like available for use, though.

Also, that code above feels very gross. The “global.” and “npc.” is mostly what I think is bothering me.

#198

Your view is absolutely correct. I’d agree, the code you’ve given isn’t ideal at all. This only way you’ll get around this is with the introduction of classes or resorting to functions like ‘join’. I would say not to worry about trying to rectify this scenario via the use of global functions and instead stick to being to delivering what might be a more simple product, but one that’s obtainable and works at the end of the day.

#199

I’m curious to know what you would think WOULD be ideal. Just make up whatever is necessary in pseudocode to illustrate what you’d prefer to use.

Here’s an example of why classes aren’t a necessity right now, at least not the way I had planned to make them function:
Classes:

class Animal {
    health = 10;
    Hurt(value) {
        health -= value;
    }
}

Cow
----------------------------------
class Cow : Animal { //Cow inherits Animal's defined values and functions.
    health = 5;
    Attacked() {
        Hurt(0.1);
    }
}

Elephant
----------------------------------
class Elephant : Animal {
    health = 50;
    Attacked() {
        Hurt(5);
    }
}

cowTest = new Cow;
elephantTest = new Elephant;

No classes

[code]
function Hurt(obj,value) {
obj.health -= value;
}
function Animal() {
var.health = 10;
var.Hurt = Hurt;
return var;
}

Cow

function Attacked(obj) {
obj.Hurt(0.1);
}
function Cow() {
var = Animal();
var.health = 5;
var.Attacked = Attacked;
return var;
}

Elephant

function Attacked(obj) {
obj.Hurt(5);
}
function Elephant() {
var = Animal();
var.health = 50;
var.Attacked = Attacked;
return var;
}

cowTest = Cow();
elephantTest = Elephant();[/code]

The two methods are identical in functionality, with the exception of some redundancy. Classes just feel a little cleaner.

Also, I’m not saying I’m abandoning classes entirely. I just don’t think they’re necessary right now. I would rather get the script stuff done and be able to move on to make things more interesting. If there’s something I’m missing in terms of what can (and should) be done, I’d like to know for when I do get back and add them.

#200

Required overtime at work got extended until (likely) the end of this month, so that’s bullshit and leaving me with no time. Plus people drama, as always. I’ll try to get to this on the weekends.