Dev question about scripting system

[Graywolf]

Hello everyone, I'm back, and nice to meet you.
(I was a pretty regular user 2-3 years or so back)

I was wondering: Is anyone currently doing heavy development on the simkin system?

I've gotten a knack for using Simkin(as in embedding it, not just scripting it) while learning C++(<<which is why I disappeared.)... I've got some ideas for the scripting system, and I was wondering who to get together with to work on it. (Or should I just take up the torch?)

On another note, I've managed to implement loading scripts from vfs files. I'll post the code sometime in the next few days, when I've applied it to all scripts, and integrated it with the resource pre-loading.

All feedback is appreciated.

P.S. - I've also managed to fixed the script runtime error reporting...

[bernie]

Welcome back Graywolf. Just go for it, all enhancements are welcome particularly in the scripting department.

[Jay]

Welcome back.
Personally, I'd prefer working together. I do some coding in the scripting department of RF too (in c++, like you). I noticed that now that we have CommunityRelease, PhysicsRelease and RF075C it becomes a pain to merge those releases (I am merging Physics and CommunityRelease at the moment). I am also working on scripted projectiles, a feature that allows a projectile to be totally scripted to allow cool thinghs like targetting rockets and spells, and it is coming good (that means the release will be VERY soon). The main problem i see at RFs development at the moment is that there are a few people working on different releases, which causes extra work if we want to merge the features.

I don't want to think what happens when RF076 comes out. All my work will be obsolete.

What ideas do you have?

[Graywolf]

Ack... I didn't realize that RF was suffering from branching. I'm sure I can pitch in for integration, it's more "grunt" work than anything else. So, is there an actual "Dev Team" anymore? (Forgive me, but as I said, it's been awhile...)

As for ideas(plans, WIPs, etc... What I'm pursuing):

1. Scripting system clean-up overhaul. The scripting system is now, as it was then, pretty messy. This isn't anyone's fault, it's just the result of too much growth in a restrictive environment(It's gotten too big for it's britches.) There's quite a bit of redundant code between low and high level, some things which should be in both but aren't, some things which aren't even needed(e.g. = (Integer() == (Simkin internal)toInt())), and many things that shouldn't be a part of "pawns" at all.

So, we re-structure it. Some things, like the math functions, could easily be placed into global library objects(e.g. Math.DegToRad(float) in a script.) Level independent pawn commands can be in a sort of MidMethod set.

Also, IMHO, we should support internal object types, like such(pure pseudo-code):

Code: Select all

{
  DoSomething(GetLocationX("SomePawn"), GetLocationY("SomePawn"), GetLocationZ("SomePawn"));
}

Would become:

Code: Select all

  DoSomething(GetLocation("SomePawn"));

Where GetLocation returns a simkin wrapped vector with fields x, y, and z, and a set of basic vector math methods. And much more than just that can be done.

Also... I read about your weapon actor system. It is quite possible, without any channels, to devise an object that can be attached directly to a pawn(at option even), that can manage this. Ummm, let me demonstratewhat this would be like in pseucode.

Code: Select all

{

// New is an interpreter global we develop, to provide special objects at runtime.
  Attachs = New.Attachments();
  //Attachs.Add("fieldName", "actorDefName", "TypeName", etc...);
  Attachs.Add("right_hand", "longsword", "weapon", etc...)
  Attachs.Add("left_hand", "shield", "armor", etc...)
  Attachs.Add("body", "shirt", "armor", etc...)

  
  Animation("SheathWeapon");
  Attachs.right_hand.Render(false);  // no longer drawing longsword

for each thing in Attachs
{
  thing.Render(true); // show all
}

for each armor thing in Attachs
{
  thing.Remove(); // Armor types no longer attached.
}
  

That's just an example interface, although it's similar to the way I've been going about implementing an attachment system. There are many other things that could be done in such a fashion, such as sub-motion or channel-based animation(My next project...)

But, I digress...

[Jay]

Hm. Well that's a nice idea, but by dividing the methods to different groups, what's the big improvement, besides of readability?

As i see it, one of the thinghs that would really improve speed for the scripting system is to use a hash table for ALL high level, conversation and skydome methods, because right now only lowlevel methods (and scripted projectiles) use hash tables. There is big computation for nothing. As it is done now we need n/2 comparisons (n is the number of methods) instead of just 1(!) for all of them with a hash table. This is the main reason why low level is faster than high level. It does not suffer from the amount of methods available. I would let it be as it is now, because of 1) backwards compatibility and 2) you would not gain much in speed. A hash table already is the fastest method possible to compare two strings. Well, you would gain SOME speed, but that's because the switch() call we use is still bound to the n/2 rule, but the comparison of the strings itself isn't.

(the fastest way would be to use function pointers and have a seperate function for each of the scripting commands, which would result in truly just one comparison, the hash table comparison. But that would be a whole lot of work and then the scripting language itself could become the bottleneck maybe.)

There also is this problem that when you call

X=GetEntityX(target);
Y=GetEntityY(target);
Z=GetEntityZ(target);
SetEntityPosition(target,X+1,Y+2,Z-5);

RF scans a whole 4(!) times through the whole ActorInstanceList to look for the very same actor (4*n/2 comparisons instead of at least n/2). I partly solved this by remembering the name of the actor in the ActorManager each time an actor is searched. A hash table, again, would be better.

It's the same with EVERY entity in RF. Every time you search for an entity, the whole list of entities of this kind is searched, instead of using a hash table, which would be much faster.

And while we're at it, i must mention the way RF handles 'zones'. Everthing is packed into one big 'zone', everything is done at the same time even when the entity is miles away, making it impossible to create large worlds without a huge slowdown. (I tried to solve this problem by creating the EntityAreaSystem, but it did not work, it always caused a crash at the end, when the level was shut down)

So, in short, when i look at the code of RF, then it's a desaster when it comes to speed, even if you take away the R´rendering performance, which could be better.

Back to the topic:
The built-in-types idea is a nice one. One call of VECTOR=GetPosition(target); instead of three calls of X=GetEntityX(target); Y=GetEntityY(target); Z=GetEntityZ(target); Nice.

For the 'dev team', well there's Quest, but else... federico made the physics release and i made the CommunityRelease (wxb1 has vanished?) but they don't count as 'official' releases. So i guess we don't count as 'official' developers too. After a release, QoD then looks if he implements the features we provide in the official releases (RFXXX instead of RealtiyFactoryCR or 'release candidate') as i understand it.

[Graywolf]

I'm definitely in agreement on the function pointers... I've done that once, but I've lost the source somewhere along the way... It's not hard, just takes a lot of typing.

Hm. Well that's a nice idea, but by dividing the methods to different groups, what's the big improvement, besides of readability?

Well, readability and reducing code bloat are good things, but also... With the global library types, they would be accessible to all scripts, by default. Thus, no need to duplicate the code into other object types.

And while we're at it, i must mention the way RF handles 'zones'. Everthing is packed into one big 'zone', everything is done at the same time even when the entity is miles away, making it impossible to create large worlds without a huge slowdown. (I tried to solve this problem by creating the EntityAreaSystem, but it did not work, it always caused a crash at the end, when the level was shut down)

About that... Well, I've gotten side-tracked into working on a solution(that's a pretty serious issue, IMHO): Loading multiple BSP worlds. I've managed to get multiple worlds to render properly, but the entity data is another question...

So, I'm working an "Engine" script system, to help me work out the kinks... A script of this nature will be helpful, and perhaps necessary, for managing multiple worlds anyways. Anyone know anything about multi-threading? (For a background loading system, of course...)

P.S.: Do you still have the core code for the EntityAreaSystem?

[paradoxnj]

Anyone know anything about multi-threading? (For a background loading system, of course...)

What do you need to know?

[Graywolf]

What do you need to know?

Hehe... Everything. It's something I haven't gotten around to trying yet. I'll probably just find some ref material and take a shot.

[paradoxnj]

Look up the following topics:

CreateThread() function
Critical Sections
SetEvent()
Synchronizing threads

[Graywolf]

Thank you, and done.

Of course, actually doing it will have to wait until I get multiple BSPs working porperly in the first place...