Client progress


#241

That’s a feature of GS1 that I find really cool, glad your implementing it.

So I could do something like:
enum levelsand;
enum levelsnow;

setstring(leveltype,partstr(currlevel,9,-1));

level#s(leveltype) = thisorthat;
?

edit:
I can’t figure out any practical uses right now though?
Apart from like
setimg boomerang_#s(boomlevel).png;


#242

Dynamic names are a very internally inefficient way to not have to use arrays, basically.

var_cat = 1; var_dog = 2; var_bird = 3; animalName = "cat"; player.chat = %("var_" @ animalName);

The result would be 1, of course. Having no support for this kind of thing in C++ and knowing how to code without it, I honestly don’t know where it would ever be that much easier than an array that it would be worthwhile. The above, for example, could just as easily be:

varArray = {var_cat,var_dog,var_bird}; player.chat = varArray[0];

or

varArray = { "cat": var_cat, "dog": var_dog, "bird": var_bird }; player.chat = varArray["cat"];
The direct array access with the 0 is the most efficient, but less competent scripters will try to use strings everywhere. So ultimately it’s a convenience feature. Also, these are terrible examples, but they’re all valid code for this scripting engine.


#243

Still working on it. Just not much to note. I’ll probably slow down a bit, because I’ve been skipping out on exercising to work on it, which is a problem. As for the project, I had to go back to the compiler briefly to redo variable handling yet again. (Those changes are already done, nothing significant.) I wasn’t happy with the options for integrating built-in variables with the way it was designed. The new plan seems great so far.

I’ll post as noteworthy changes are made, but it may not be daily. If I decide to stop again for whatever reason, I’ll post that as well.


#244

dont bother with dynamic variables if you are gonna have decent datastructures. you gonna give us anything fancy to use?


#245

Classes were intended, but not necessary, so I decided to delay adding them. You can basically simulate classes anyway. Any variable can have new subvariables added at any time. That combined with arrays being as flexible as they are should be more than adequate, I’d say.


#246

Ok, I got the new variable shit mostly done. I should be able to finish tomorrow. It’ll definitely allow a good method of accessing built-in variables. (Things like “script”, “params” (for function call parameters), or any built-in function like math functions or client-related functions.)


#247

Work has been really stressful the past week or so. I’ve been coming home and not wanting to think about anything, so there’s been no progress, unfortunately. I want to get back to it again soon.


#248

Im willing to wait a year for the next round of motivation

Sent from my SM-N920R7 using Tapatalk


#249

I don’t blame you for thinking that.


#250

Well surprise, bitch. I worked on it for a while today. I think the variable updates are complete, after running into some not-so-insignificant issues. Lots of updates had to be made throughout the code. Everything is now in place to start implementing the built-in functions/variables. I’m starting on that tonight, and don’t expect any issues with it.


#251

Would’ve thought the built-in-functions and variables require the client to be partially built unless you mean math utility functions and the like?


#252

Correct! But in doing those, it also provides the framework for the game engine itself.


#253

Life said “Nope.” Plus WoW: Legion is releasing soon, so I wouldn’t expect anything to get done on this project for several months now. Sorry.


#254

np, you’re still awesome


#255

Don’t worry, man. Everyone probably forgot about this anyway.


#256

I’ll try to avoid killing myself over this possibility.


#257

I tried WoW not too long ago and it wasn’t fun at all


#258

I rather like playing UMS Desert Strike on Starcraft 1 than play WoW.


#259

You guys are no fun.


#260

Can confirm, Legion is fun. You nerds need to play it.